What Is Your Browser Leaking?

Today in my tweet stream, someone pointed out this site and I wanted to blog about it. The site is called stayinvisible.com and offers a quick view of some of the data that is available to a web site or an attacker who can lure someone to a website. 

The site displays a dump of a variety of common data that you might not be aware of that is leaking from your browser. There are also tips for hardening your browser settings and operating system against some of the methods used to dump the data. 

If nothing else, it might just provide an “ah ha” moment for folks not used to the information security space. Give it a try and let us know what you think of it. 

We have no association with the site, its content or the folks who run it. We just thought it was interesting. Your paranoia may vary. 🙂

Port 9100/TCP Probes

We have been seeing probes to port 9100/TCP in the HITME for a while and decided to check out some of the activity and post about it, so others could know what is going on there.

The connections come from a few sources, often universities, and don’t seem to be anything more than misconfigurations of devices in their environment. The connections that come in on port 9100 often contain the “@PJL INFO PRODINFO” strings, which are apparently tied to the HP Printer Job Language (PJL). Basically, the command is supposed to dump out identifying data from the printer and return it to the user. This data includes a variety of configuration data and other details about the device. You can find an example here

The port 9100 connections usually coincide with a connection to port 80/TCP on the same host. This port 80 connection looks something like this (with IP address info in the x.x.x.x string): 

“GET / HTTP/1.1\nAccept-Encoding: identity\nHost: x.x.x.x\nConnection: close\nUser-Agent: Python-urllib/2.7\n\n”

Now this is a little interesting. It is likely meant to be a validation probe that the printer device’s embedded web server is online and that the device is operational. BUT, the “Python-urllib/2.7” made us suspicious. Perhaps this isn’t a usual printer request?

A little Google searching pretty quickly shows that HP’s implementation of CUPS, that is the unix printing mechanism, strongly leverages this Python library.  So, that might not make it suspicious as most folks might think. 

So, we did the next thing in our bag of tricks, and returned valid connections from HoneyPoint on those ports. Our waiting finally came to fruition and lo and behold, we got more connections of the same nature. This time though, we also got a print job for the “printer” to print. What did we get? Spam, of course. Printer spam. An ad to buy some stuff, that needless to say, we don’t really need. 🙂

So, what are those port 9100 probes? What is the basis behind that “@PJL INFO PRODINFO” in your logs? Nothing more than spam attempts to waste your paper, ink/toner and time. Hey, it could have been worse, right? 🙂

Obviously, turning off port 9100/TCP from the Internet will help prevent this stuff from coming into your organization. It looks like a few malware folks have added this capability to their spyware/adware routines as well, so if you have 9100 blocked from the Internet and see printer spam coming in, track the print jobs back to a workstation if possible and do the turn and burn routine. Let us know if you have any questions or issues, and we will keep our ears and eyes open on port 9100 traffic and drop some more info if we see anything that looks wormy or the like. 

MSI ongoing assessment customers will note that port 9100 signatures are routinely tested and you would be notified of any illicit behaviors found during your assessments.

PS – There have been some “worm” like behaviors on port 9100 in the past, including a couple of pieces of printer malware. We didn’t see it in this case, but we know it’s out there…Here is an example of some of what may be lurking in your printer… 

Oracle CSO Online Interview

My interview with CSO Online became available over the weekend. It discusses vendor trust and information security implications of the issues with password security in the Oracle database. You can read more about it here. Thanks to CSO Online for thinking of us and including us in the article.

Terminal Services Attack Reductions Redux

Last week, we published a post about the high frequency of probes, scans and attacks against exposed Windows Terminal Services from the Internet. Many folks commented on Twitter to me about some of the things that can be done to minimize the risk of these exposures. As we indicated in the previous post, the best suggestions are to eliminate them altogether by placing Terminal Services exposures behind VPN connections or through the implementation of tokens/multi-factor authentication. 

Another idea is to implement specific firewall rules that block access to all but a specific set of IP addresses (such as the home IP address range of your admins or that of a specific jump host, etc.) This can go a long way to minimizing the frequency of interaction with the attack surfaces by random attacker tools, probes and scans. It also raises the bar slightly for more focused attackers by forcing them to target specific systems (where you can deploy increased monitoring).

In addition, a new tool for auditing the configuration of Terminal Services implementations came to our attention. This tool, called “rdp-sec-check”, was written by Portcullis Security and is available to the public. Our testing of the tool showed it to be quite useful in determining the configuration of exposed Terminal Services and in creating a path for hardening them wherever deployed. (Keep in mind, it is likely useful to harden the Terminal Services implementations internally to critical systems as well…)

Note that we particularly loved that the tool could be used REMOTELY. This makes it useful to audit multiple customer implementations, as well as to check RDP exposures during penetration testing engagements. 

Thanks to Portcullis for making this tool available. Hopefully between this tool to harden your deployments and our advice to minimize the exposures, we can all drive down some of the compromises and breaches that result from poor RDP implementations.

If you would like to create some threat metrics for what port 3389 Terminal Services exposures might look like for your organization, get in touch and we can discuss either metrics from the HITME or how to use HoneyPoint to gather such metrics for yourself

PS – Special thanks to @SecRunner for pointing out that many cloud hosting providers make Terminal Server available with default configurations when provisioning cloud systems in an ad-hoc manner. This is likely a HUGE cause for concern and may be what is keeping scans and probes for 3389/TCP so active, particularly amongst cloud-hosted HITME end points.

PSS – We also thought you might enjoy seeing a sample of the videos that show entry level attackers exactly how to crack weak passwords via Terminal Services using tools easily available on the Internet. These kinds of videos are common for low hanging fruit attack vectors. This video was randomly pulled from the Twitter stream with a search. We did not make it and are not responsible for its content. It may not be safe for work (NSFW), depending on your organization’s policies. 

 

Yandex.ru Indexing Crawler Issues

The yandex.ru crawler is an indexing application that spiders hosts and puts the results into the yandex.ru search engine. Like Google, Bing and other search engines, the system searches out new contents on the web continually and adds the content to the search engine database. Usually, these types of activities cause little issues for those whose sites are being indexed, and in fact, over the years an etiquette system based on rules placed in the robots.txt file of a web site has emerged.

Robots.txt files provide a rule set for search engine behaviors. They indicate what areas of a site a crawler may index and what sections of the site are to be avoided. Usually this is used to protect overly dynamic areas of the site where a crawler could encounter a variety of problems or inputs that can have either bandwidth or application issues for either the crawler, the web host or both. 

Sadly, many web crawlers and index bots do not honor the rules of robots.txt. Nor do attackers who are indexing your site for a variety of attack reasons. Given the impacts that some of these indexing tools can have on bandwidth, CPU use or database connectivity, other options for blocking them are sometimes sought. In particular, there are a lot of complaints about yandex.ru and their aggressive parsing, application interaction and deep site inspection techniques. They clearly have been identified as a search engine that does not seem to respect the honor system of robots.txt. A Google search for “yandex.ru ignores robots.txt” will show you a wide variety of complaints.

In our monitoring of the HITME traffic, we have observed many deep crawls by yandex.ru from a variety of IP ranges. In the majority of them, they either never requested the robots.txt file at all, or they simply ignored the contents of the file altogether. In fact, some of our HITME web applications have experienced the same high traffic cost concerns that other parts of the web community have been complaining about. In a couple of cases, the cost for supporting the scans of yandex.ru represent some 30+% of the total web traffic observed by the HITME end point. From our standpoint, that’s a pain in the pocketbook and in our attention span, to continually parse their alert traffic out of our metrics.

Techniques for blocking yandex.ru more forcibly than robots.txt have emerged. You can learn about some of them by searching “blocking yandex.ru”. The easiest and what has proven to be an effective way, is to use .htaccess rules. We’ve also had some more modest success with forcibly returning redirects to requests with known url parameters associated with yandex.ru, along with some level of success by blocking specific IPs associated with them via an ignore rule in HoneyPoint.

If you are battling yandex.ru crawling and want to get some additional help, drop us a comment or get in touch via Twitter (@lbhuston, @microsolved). You can also give an account representative a call to arrange for a more technical discussion. We hope this post helps some folks who are suffering increased bandwidth use or problems with their sites/apps due to this and other indexing crawler issues. Until next time, stay safe out there!

CSO Online Interview

Our founder & CEO, Brent Huston (@lbhuston) just had a quick interview with CSO Online about the Gauss malware. Look for discussions with Brent later today or tomorrow on the CSO site. Our thanks to CSO Online for thinking of us!

Update 1: The article has been posted on CSO Online and you can find it here

Brent would also like to point out that doing the basics of information security, and doing them well, will help reduce some of the stomach churning, hand wringing and knee-jerk reactions to hyped up threats like these. “Applying the MSI 80/20 Rule of InfoSec throughout your organization will really give folks better results than trying to manage a constant flow of patches, updates. hot fixes and signature tuning.” Huston said.

Malware Alert: Will You Lose Your Internet Access On Monday?

We’re always keeping our eyes and ears open when it comes to malware. If you’ve not heard of this report before now, it would be good to check your computer to see if it has been infected with a nasty piece of malware whose creators were finally caught and shut down by the FBI late in 2011.

From AllThingsD:

Next week, the Internet connections of about a quarter-million people will stop working because years ago their computers became infected with malware.

The malware is called DNSChanger, and it was the centerpiece of an Internet crime spree that came to an end last November when the FBI arrested and charged seven Eastern European men with 27 counts of wire fraud and other computer crimes. At one point, the DNSChanger malware had hijacked the Internet traffic of about a half-million PCs around the world by redirecting the victims’ Web browsers to Web sites owned by the criminals. They then cashed in on ads on those sites and racked up $14 million from the scheme. When the crackdown came, it was hailed as one of the biggest computer crime busts in history.

Complete Article

The listed site for checking if you have the malware is (not surprising) getting slammed. Try to refresh the address a few times and it will show you if your system is infected or not, plus will give you a link for how to fix your site.

Here’s to seeing “green” for everyone!

Audio Blog Post: Spear Phishing

Brent Huston, CEO and Founder of MicroSolved, Inc., discusses with Chris Lay, Account Executive, the new trends with spear phishing. In this audio blog post, you’ll learn:

  • How traditional spear phishing has changed
  • The new approach attackers are now using
  • The LinkedIn password breach and how it could be used in phishing attacks
  • Some non-traditional spear phishing campaigns

Grab a drink and take a listen. As always, let us know what you think!

Click here to listen.

Audio Blog Post: How to Safeguard Your Data From Credit Card Theft

Cybercriminals continue to seek new opportunities to steal credit card data, highlighted recently in the largest credit card theft seen in two years — a 1.5 million loss from Global Payments, a third-party processor of transactions for Visa and Mastercard.

What can companies do? Also, what can you do to protect your credit card data?

I sat down with Brent Huston, CEO and Security Evangelist with MicroSolved, Inc. to discuss such questions. In this audio blog post, you’ll hear:

  1. The current state of identity theft
  2. Two primary ways credit cards get stolen
  3. Skimming as a preferred model for theft and how to prevent it
  4. Why being PCI-compliant is not a silver bullet

And more!

Click here to listen.

Take a listen to this informative 15-minute interview and learn how you can protect your organization from data theft!

Resources:

 

Threat and Vulnerability: Pay Attention to MS12-020

Microsoft today released details and a patch for the MS12-020 vulnerability. This is a remotely exploitable vulnerability in most current Windows platforms that are running Terminal Server/RDP. Many organizations use this service remotely across the Internet, via a VPN, or locally for internal tasks. It is a common, prevalent technology, and thus the target pool for attacks is likely to make this a significant issue in the near future. 

 
Please identify your exposures to this vulnerability. Exploits are likely currently being developed. We have not yet (3/13/12 – 2.15pm Eastern) seen exploitation or an increase in probes for port 3389, but both are expected to occur shortly.
 
Please let us know if you have any questions or if we may be of any assistance with this issue.
 
UPDATE: 
 
 
This article makes reference to a potential worm attack vector, which we see as increasingly likely. Our team believes the exploitation development time to be significantly less than 30 days and more like 1-3 days for resourced attackers. As such, PLEASE TREAT THIS AS A SIGNIFICANT INTERNAL VULNERABILITY as well. Certainly, IMMEDIATE consideration is needed for Internet exposed systems, but INTERNAL systems should be patched as soon as manageable as well.
 
UPDATE II:
 
 
This confirms the scope and criticality of this issue.
 
UPDATE III:
 
Just a quick note – we are seeing vast work on the MS12-020 exploit. Some evidence points to 2 working versions. Not public, yet, but PATCH NOW. Internal & protected networks too.
 
UPDATE IV:
 
MSI is proud to announce the immediate availability of a FREE version of HoneyPoint, called HPRDP2012 to help organizations monitor for ongoing scans and potential future worm activity. The application listens on port 3389/TCP and is available for OS X (Intel), Windows & Linux. This application is similar to our releases for Conficker & Morto, in that it will be operational for a set time (specifically until October 1, 2012). Simply unzip the application to where you would like to run and execute it. We hope this helps organizations manage this vulnerability and detect impacts should scans, probes or a worm emerge. Traditional HoneyPoint customers can use Agent and/or Wasp to listen for these connections and report them centrally by dilating TCP listener HoneyPoints on port 3389. Please let us know if you have any questions.