Since we reported about the new attacks against Internet Explorer exploiting a vulnerability in a DirectShow ActiveX object, we have released DATs/coverage updates for many of our products and technologies.

Current status for each of the content areas:

• Malware: Coverage is provided for exploit code in the 5668 DATs, released on July 6
• HIPS: Generic buffer overflow should provide coverage
• McAfee Network Security Platform: Coverage was provided on July 6
• McAfee Vulnerability Manager: Coverage was provided on July 6
• MNAC: Coverage will be provided in the next release
• VirusScan Enterprise: Buffer overflow protection should provide coverage
• McAfee Web Gateway, Anti-Malware Edition: Behavior analysis provides coverage against currently known exploits

Other Internet users and website administrators can also download the free Stinger tool to scan computers and web pages for known malware relating to this attack:

• http://download.nai.com/products/mcafee-avert/stinger.exe

We will continue to monitor the situation to provide comprehensive coverage.

RSA is pretty much over now and it has been a blurry several days. Some real good sessions, some real good panels. Lots of meetings and interviews and many old friends on hand (shoutouts to Dave Perry, Larry Bridwell, and Lysa Myers), but I digress. …

For me the best event was the “Hacking Exposed” session, by Stuart McClure and George Kurtz. OK, I cop to being biased because I know and work with both these gents/slackers at McAfee, but they did show a really wild hack–they pwned a primary domain controller from an iPhone! Yep, you read that correctly. They hacked a Windows server FROM an iPhone.

For those who were not among the annointed and attended, I have uploaded the slide deck here. Stu and George recorded the hack as well:

When I wrote a scanner plug-in this week for an old directory traversal vulnerability–CVE-2008-4419–I wondered whether there are vulnerable HP LaserJet printers online that can be controlled from the Internet. To find out, I used Google. The search listed almost 50 results, and I found that almost all of these printers are not patched, even though HP has provided firmware updates to resolve this vulnerability. An attacker could leverage this unicode-encoded directory traversal vulnerability to read configuration files or cached documents, and gain read access from the Internet to important internal information.

Usually administrators ignore the security of printer devices. They may think there is no harm even if the printer can be controlled remotely by an attacker.

The administration web interface of these LaserJets can be accessed without passwords. The attacker can use these LaserJets to print any documents from anywhere. Although attackers may not be able to reach the printouts, at least they can waste a lot of paper. Spammers can also post free advertising to companies if they connect to these printers.

So please harden your network gateway or firewall to restrict access to these devices. Don’t give everyone on the Internet a chance to use your printer, and patch the vulnerable LaserJets to prevent the potential information disclosure.

To download the HP firmware updates and upgrade instructions, click here.

Due to the MS08-067 out-of-cycle release from Microsoft today we are in the process of releasing emergency DATs/coverage updates for many of our products and technologies. We are also working on an emergency Security Advisory as well.

Current state for each of the content areas is as follows:

Malware – Emergency DAT cut and testing in progress. ETA of 2 – 3 hours.

HIPS – Generic buffer overflow should provide coverage.

Intrushield – Partial existing coverage. Additional emergency sigset releasing today.

Foundstone – Emergency signatures being released today.

V-Flash – Emergency signatures being released today.

MNAC – Emergency signatures being released today.

VirusScan Enterprise BOP – Should provide coverage for the buffer overflow.

We will continue to monitor this critical event to provide the most comprehensive coverage we can.

I was at a friend’s house this past weekend when I asked to connect to his wireless router with my laptop. This friend was not computer savvy so I wasn’t surprised to find that security was not configured on his router.

This reminded me of an article (Secure You Wireless Router) a colleague of mine at Avert Labs had written several months ago about how more and more homes in China nowadays have wireless routers, but very few people bother to secure their routers.

I proceeded to lecture my friend about the importance of being security-aware, and the dangers of not being so – identity theft, stolen passwords, private documents, pictures, etc.

To demonstrate my point, I asked his permission to perform a penetration test which he agreed to.

I proceeded with the same steps described in my colleague’s article. I obtained an IP on the unsecured network, found the router’s IP, opened up a browser to that IP and was presented with the router’s administration login page. A quick search online easily gave up the default admin password for this router – “admin”. I tried that and sure enough, got into the admin page.

Next I checked the logs on the router and identified an active host on the network that was not my own. I then tried to open a NetBIOS NULL session with the host which worked. So far everything I tried had worked on the first attempt. Getting the NULL session opened up some opportunities for some good information gathering. For one, I determined that the host was running Windows 2000. More interestingly, I was able to get a list of user accounts. All without the need for a username and password. Only one of the accounts sounded like it was user-created. I tried to map a drive using that account with a blank password, and failed. I tried a few more times before giving up on guessing passwords.

I was using my work laptop so I had a Foundstone Enterprise install handy. I scanned the host for vulnerabilities, looking out for anything remotely exploitable. I came up with a handful, but one check jumped out at me – “Administrator Account Has No Password”. I tested this by mapping a drive with the administrator account and a blank password, half hoping that it was a mis-detection. Alas, the map succeeded and at this point the demonstration was over. I now had full access to my friend’s filesystem, and now the possibilities were endless. Having an Administrator account with a blank password on a Windows machine is such an old security hole that I didn’t even bother to test it early on.

For the home user, here are are just a couple tips to get you started with security and get you in way better shape than my friend:

1. Secure your wireless network. Look up how to do it online or have your techie friend do it for you, like I did for mine.
2. Set a strong password for your Windows Administrator account. Better yet, disable the account.
3. Disable NULL sessions. Look up how to do it online.

We had a customer a while back report a false detection on one of our Foundstone checks. The purpose of the check wasn’t even to detect malware, it was to detect the presence of a certain legitimate remote administration tool. The customer insisted they were not running that administration server on the host. From the diagnostic packet captures they sent in, however, there was no denying that the tool was running on that host whether they knew it or not. And that tool happens to be commonly dropped by malware to serve as its backdoor. No doubt, some damage had already been done by the time they reported this to us, but how much more damage was prevented when this security breach was discovered because of our check?

Malware detection is not one of the most prominent functions of a remote vulnerability scanner. But most major scanners do offer this capability. Don’t expect to replace your traditional AV with vulnerability scanners any time in the future, though.

Although vulnerability scanners can open and read files, they are mostly agentless; so they are reduced to making RPC calls to perform these operations. If you were to mimic the signature scanning of traditional AV, performance would be unacceptably poor. And so malware checks have to resort to detecting only the presence of malware. That is, detecting its traces. This can be the existence of certain files (no opening or reading), registry keys, or a running service. In most cases, having two out of three of these traces is a unique enough combination for a strong detection.

Another way to detect the presence of malware with a vulnerability scanner is to detect the network activity of the malware. If it opens a backdoor on a particular port and listens for commands, which is the majority of malware today, most likely we can detect it remotely. In this respect, the vulnerability scanner actually has an advantage over traditional host-based AV. Take the case of a rootkit that can hide its files, registry entries, running process, service, etc.–it’s virtually invisible on the host. It might even hide its network activity, but it can hide it only from programs running on the local machine. Sophisticated as the rootkit may be, it cannot hide its network activity from the vulnerability scanner working remotely.

In the end, detecting malware with a vulnerability scanner is purely reactive, that is, you are raising a flag after the malware has already installed itself–whereas traditional AV has the noble goal of preventing it from even getting onto the host.

Some might consider the malware detection offering of vulnerability scanners as superfluous because of the limited capability and its reactive nature. But I’m sure that the customer with the hidden remote administration tool isn’t one of them.

In March I blogged about a round of mass Web site compromises. Since then there have been several other instances discovered, as well as a couple of smoking guns. The net net is that the bad guys are using automated tools to find and attack Web applications that are vulnerable to SQL-injection attacks. Many of these applications are homegrown and thus there is no patch or hotfix for administrators to install. This means that simply removing the injected malicious code won’t last long.

Just now I was reviewing the latest batch of hacked sites, and I noticed pages that were previously compromised and “repaired,” only to be compromised again. The entry point for these attacks must be closed in order to thwart future attacks. This means that underlying code must be audited and improper input validation must be corrected. And given that many Web administrators install out-of-support freeware and shareware applications, we can expect many sites to remain vulnerable for a very long time.

McAfee’s Foundstone Hackme Shipping Tool can be a useful resource for those in need of a better understanding of how common Web application attacks occur and how to properly code against them.

PCI Requirement #6.6 has been in the news for quite some time, primarily because complying with it is not trivial. PCI Security Council published a press release on April 22, 2008, hoping to clarify some of the requirements and help merchants comply before the upcoming deadline of June 30, 2008. Some of the clarifications are confusing, since they seem to go against basic application security concepts, as well as the principle of compensating controls already laid out by the PCI standard.

Requirement #6.6 aims to secure web sites against attacks, by requiring either of the following for all web-facing applications:

1. Manual code review by experts
2. Application Layer Firewall

Now this press release effectively says that the intent of code review requirement is met by:

• Manual web application security vulnerability assessments
• Proper use of automated web application security vulnerability assessment (scanning) tools

The million dollar question is: Can a vulnerability assessment or penetration test really deliver the same findings that a code review does? Is it OK to think that a code review can be replaced by a vulnerability assessment or a penetration test?

I don’t think so. Code review is a white box exercise, where as vulnerability assessment is a black box exercise. Code review allows a security expert to look under the hood and see the guts of the application, where as a vulnerability assessment looks at the application from outside and can only see the few security flaws that have actually manifested themselves into full blown exploitable vulnerabilities. Therefore a vulnerability assessment will leave out many other complex, subtle, yet serious flaws that only a code review could have discovered.

So I wonder why the council thinks that it meets the intent of the code review requirement.

Now here’s some background before you read about the next confusion.

The PCI standard clearly states that a compensating control must be in addition to controls required in the PCI DSS. Sounds complicated but it’s really simple. Let me explain with an example: Let’s take Requirement #3.3 which requires the PAN to be masked when displayed. If this requirement cannot be met then the merchant will have to propose a compensating control. However a compensating control which says that “this data is only accessible to a limited set of employees who need to work with this data” will not be acceptable, because this control is already covered under PCI Requirement #7 which says that data should be accessible only to those employees which have a business need.

Going by this logic, Requirement #11.2 and 11.3 already cover manual web application security vulnerability assessment as well as automated web application security vulnerability assessment (scanning) tools. So how can these be considered acceptable as a compensating control for Requirement #6.6?

I am surprised that such a proposal is made by none other than the Council, which is the champion of the PCI standard. I really hope the Council corrects this mistake.

- Vivek

Note: Vulnerability assessments and penetration tests can be interpreted differently by different audiences. So I should clarify that I am interpreting them as per PCI guidelines, which closely match how Foundstone interprets these services too.

Last night I shared about how Ryan and I went through most of the challenges in Applied Security’s HackIT 2.0 contest at ShmooCon 2008 with the group at AHA! I spoke about how we approached and solved most of the challenges, and I thought I would share the process with whoever else was interested. I posted an informal report describing the methodologies and how to run/use the tools that we employed during the contest. The report is located on AHA!’s wiki, so if you’re interested, it’s located here on the meeting page. There is also a link to a PDF report if you want to take it off line. Also, if you are in Austin, Texas, (or the surrounding area) you should check out AHA! We get together and present as many short DefCon-style talks as we can before we get kicked out of Mangia Pizza. We share a lot of interesting/fun/useful ideas and information with each other. Plus, if you are a remote worker, it’s nice opportunity to get out and meet other “hackers” and shoot the breeze. We are a very welcoming bunch, but if you do come, be prepared to present.

If you are running WPA Enterprise with PEAP, or EAP/TTLS its about time you take a serious look at your client configuration! This weekend at Shmoocon in Washington D.C, Josh Wright and I gave a presentation that demonstrated how a very common, but incorrect client supplicant configuration can lead to the compromise of certain wireless networks and in some cases, provide Windows domain access.

Our AP impersonation attack on PEAP and EAP/TTLS relies on the client failing to properly validate the authentication server’s (RADIUS) TLS certificate. By default, the Windows Zero Configuration (WZC) wireless supplicant performs this validation by putting the trust of the network in the client’s hands. WZC will prompt the client to either continue or cancel upon connecting to the wireless network (similar to the way your web browser prompts you when accessing certain websites over HTTPS). Furthermore, the client may be mislead by this message as it only contains the signing authorities’ name (i.e Verisign) rather then the actual certificate name.

The severity of this issue is further escalated when the client is configured not to validate the server certificate at all. Unfortunately, this is the most common configuration I’ve seen used within organizations. It should be noted that because this is a configuration related attack, WZC is not the only vulnerable client supplicant. OSX’s client, Juniper’s Odyssey Client, and virtually every other wireless supplicant is vulnerable as well.

In either of these scenarios, FreeRADIUS-WPE (our modified version of the open source RADIUS server) can be used to gain access to the inner authentication credentials passed in the TLS tunnel that is established between client and the authentication server. These weak inner authentication protocols (i.e. PAP, MSCHAPv1, MSCHAPv2, etc..) rely on the outer TLS tunnel for protection, so without this protection they are greatly exposed to attack. In some cases these protocols reveal the client’s username and password in clear text, while other cases require a brute force attack. Due to active directory integration, these credentials may also be those used for domain authentication.

Finally, because this is the result of a client related issue, clients may be vulnerable in areas such as coffee shops, airports and other locations outside of the vicinity of the corporate wireless network.

When using WZC and other supplicants, you’ll want to make sure that the client clearly validates the server certificate by only trusting certificates that match the signing authority, and hostname of the RADIUS server. An example of the WZC configuration is below. This is also covered in Microsoft knowledge base article KB941123. For additional information on protecting yourself from this and other attacks, please see my 802.11 attacks whitepaper on Foundstone.com!

Tis the season to be greedy –at least that’s what a couple of New York City thieves thought the other night when they stole an entire 18-wheeler FedEx truck containing somewhere around $1M in valuables. What might go overlooked is the priceless corporate data that could possibly be on that truck as well. We constantly rely on couriers such as FedEx to securely ship all of our “data at rest-in transport”, but what measures are they taking to actually ensure those assumptions? If the breach blog has taught us anything, it’s that not enough companies are encrypting their laptop hard drives, backup tapes, etc… and these types of attacks are still serious risks to our data.

As a security consultant, I repeatedly see and hear about these things going overlooked. From boxes labeled “Iron Mountain” sitting on empty loading docks, to Dell boxes waiting in the vacant hallways of shared office buildings, companies are constantly putting their data at risk at pickup and drop off areas. And I’m actually surprised we don’t see this more often, now even not-so-tech thieves can cash in on the action with these physical attacks. So what do we do? Require all couriers to upgrade to armor cars? Or maybe just spend the time and money now to upgrade your security policy and encrypt all data out of your control!

A few weeks ago, while catching up on Internet pop culture videos, I stumbled upon a few 2girls1cup-reaction videos on Ebaumsworld. Having watched the reaction videos, I was naturally curious what the actual 2girls1cup video was about. A quick Google search revealed 740,000 results for “2girls1cup”–seems everyone’s already watched it except for me.

I quickly found the video and like everyone else in the reaction videos, my eyes were glued to the screen. After watching some more reaction videos, I came across a blog comment that promises 2girls1finger is even better–and it links us to the site (http://us-private-[BLOCKED].blogspot.com). Awesome! Let’s check it out…

Here’s a screenshot of the linked site:

The site wants me to download this “codec”:

Looking at the download dialog, the .exe seems to be from http://powerm[BLOCKED].com. (Sounds legit, I guess.) I went ahead and downloaded the codec. (Note: Don’t try this at home, folks; I’m a professional. You should never download content from untrusted sources.)

After downloading the “codec,” I clicked the Continue button on the video screen. This action just popped up the download tab again. I don’t understand why–I had already downloaded it. Next, I clicked the Cancel button; that action threw me into a loop between the following two pop-ups (how’s that for annoying?):

It turns out this codec wasn’t so much a codec as a Trojan. Here’s a write-up from McAfee.

Don’t forget that downloading content from untrusted sources often means downloading malware. Keep this in mind while searching for the next bizarre fetish clip or its reaction videos. Here’s a similar blog entry posted last year. Same attack vector, just a different video.

There’s a lot of hype circulating around about a Jihad application meant to wage cyber war in the near future. A lot of people have speculated and while the experts are dismissive, the topic is still getting a lot of press and worrying average users. I took a bit of time to examine the binary and I don’t believe it poses a huge threat. Here are my reasons why:

1. The program is written in Visual Basic. While there’s nothing wrong with that, VB is not the preferred programming language of very many professionals. C\C++\C# would tend to be better choices for complicated and efficient programs. VB tends to be a language for quick applications or for those beginning programming.
2. There is a tracking website required to use the application. Terrrorists don’t like to be tracked. Further, the site tracks referrals – thus it would be trivial to create cliques of users, which again is something terrorists would be desperate to avoid.
3. The website variables are in English. Extremists/Islamic Jihadists tend to not speak English, remember all the stories about the few English speakers they use? These guys have some understanding of English – indicating they might not be the stereotypical terrorist.
4. The web url is hard coded and it’s to a real web server. We’re in an age of dynamic dns and fast flux. A static/real url is very amateur and easily blocked.
5. There didn’t appear to be capability to dynamically update the program remotely – this would be key for updates and avoiding being blocked. I did a VERY QUICK analysis, but didn’t see this capability.
6. The executable wasn’t encrypted and didn’t fight malware analysis – real malware writers love to do malicious things to AV guys. They weren’t in this executable.
7. The webserver had frontpage extentions – this again just seems out of place for cyber war.

All told, the little bits of analysis make the code look to be written by high school or early college kids. If their network gets large enough, maybe they could have caused harm. Right now the websever isn’t working and the app seems like a no-go. I’d suggest everyone block traffic to the server http://al-jinan.net and stop worrying.

In city office environments with residential or even non-residential buildings nearby, rogue detection can be a huge and overwhelming issue. Things get even more complicated when you think about shared office spaces where access points are just a wall away. Commercial wireless intrusion detection systems (WIDS) will allow you to place sensors in multiple locations, which allows the WIDS to perform a sort of triangulation to help identify where these APs may reside. The need for these commercial solutions is understandable when you have a wireless network within your organization, but what happens when you don’t? The threat of rogue access points is still there, and an equally serious threat is AP impersonation attacks, which may target corporate systems with wireless cards.

So what’s a guy to do? As mentioned there are two issues here: rogue access points and AP impersonation attacks. Let’s look at each one.

Rogue Access Points: With highly dense environments, the best method I’ve found for identifying rogue access points is similar to those of wireless intrusion detection systems, except it’s a more manual process. What we’ll do is use a standard wireless adapter with a low gain antenna (there is NO need for a high gain antenna, it’ll only make your life difficult) and a wireless sniffer that will display signal strength. The choice here can be either open source or commercial software. I personally use a commercial tool, AirMagnet’s Laptop analyzer, just because it gives me exactly the data that I am looking for. No matter what, don’t use NetStumbler (remember? Active vs Passive sniffing)! Using a floor map, I’ll mark down roughly 5 -10 single points within the office space and take 2 minute snapshots at each point. Once that’s completed I’ll make an Excel spreadsheet containing every BSSID (MAC address) discovered at every sample point, the capture location, and signal strength. Then I’ll sort by BSSID, and start the correlation. For example, if we have 5 sample points, we’ll look for BSSIDs that have relatively high signal strength (~30) at each sample point or at say 4 of the 5 sample points. Assuming you picked points that are around the perimeter and at least one in the middle, you should have enough information to safely assume that is in your office area. If you see particular BSSID with good signal strength along the outer wall samples, you may assume it is outside. Once you have a list of potential real rogue access points, the hunt begins!

For less dense environments or if you’ve targeted a particular suspected rogue, you can use the “walk aimlessly” technique. Use a low gain antenna so you’re not searching for something that’s 3 blocks away, lock in on the particular channel, the particular BSSID (AirMagnet’s “Find” function is really great for this) and just follow the signal. One helpful technique is to use your body to help identify in which direction the signal is originating from. Wireless signals do not propagate through water, so because the human body is made up of something like 70% water, we can place the card near our chest and turn around to see if the BSSID was originating from in front of us by watching the signal strength. Normally it’ll drop ~10 if it is. The same technique can be used for APs above our location, we can put our hand over the top of the card, or bend over. From a third party perspective, all of this may look a little strange, but remember we’re walking around aimlessly anyway, so people already think we’re weird!

In general, the major fault with rogue detection is if AP’s signal strength is turned way down. There are some cases where you may get lucky and pick it up but alot of times thats not the case. You can also take more sample points and even though it has low signal, it might tip you off that it’s somewhere nearby.

AP Impersonation: I’m writing a nice little whitepaper on WPA Enterprise AP impersonation attacks where you can compromise an EAP/TTLS or PEAP 802.11 network due to one common configuration related issue, so I think it’s time to bring more attention to these types of attacks. AP Impersonation attacks are just as they sound, an attacker will position an access point with a mimicked configuration of your wireless access points and the client will unknowingly connect to the attacker’s AP. This can be used in a number of different ways, but here will just look at one variant.

Without a wireless network in your environment, the only wireless an attacker can target is that of your clients. With the wireless network adapter enabled, the client will constantly send probe requests to see if its configured wireless network is available. By responding to these probe requests, an attacker can trick the client into connecting to the malicious access point. In should be noted that if the network in which the client is probing for is encrypted or requires some sort of authentication (assuming its configured correctly), the attack will be mitigated. However in cases such as an airport wireless network, or “Free Public Wifi”, the client may unknowingly connect to the AP exposing itself to further attacks which may ultimately allow the attacker onto the corporate internal network (assuming the client is hardwired into the internal network at the time of attack). Tools have been around for quite awhile now which display these attacks (i.e Hotspotter and Karma).

The main protection against these attacks is disabling wireless all together, disabling while it’s not in use, or disabling while the Ethernet cable is plugged in. Disabling wireless all together is an excellent idea, unfortunately it may not always be an option. You can disable it while it’s not in use, which really relies on getting your clients used to the manually disabling the adapter before and after its use. Again, may not be very feasible. I recommend the last option where you disable the adapter while the Ethernet cable is plugged in. I know most Dell laptops nowadays will do this automatically, and you can even buy wireless configuration software or client security software that will do this as well. Of course, you always want your clients running a firewall and up to date with the recent patches to further mitigate your risk. It’s also recommended to disable the client software from connecting to ad-hoc networks.

In general, rogue APs are such a widely known threat that often go overlooked. They’re usually discovered when a network engineer or security personnel accidentally connects to one or notices it from its client software. This should not be the case within your organization. Quarterly checks should be put in place to ensure these entry points do not go overlooked and that your clients are not subject to these attacks. Think about it, it’ll only take about one day’s work to protect yourself.

Often, while my students are working on a lab, I’ll take this time to search for more class demos. It seems that many of the demos we discuss in class soon get fixed. I’m not sure how or why, but this is often the case. Parameter manipulation — they’re all fixed within a few weeks of discussing them in class. The list goes on, but this is so frequent that I stopped tracking them. Regardless of the reasons, these vulnerabilities get fixed, and I’m glad they do. And I really don’t mind doing some basic research into finding more. So here’s today’s example, as it applies to password policy and authentication fun.

I’ll start off by listing some common authentication-related vulnerabilities I often see and then discuss some error messages I recently found on a popular travel site. I’ll also add some “malicious” ideas, just for fun–to get you thinking.

Common authentication-related vulnerabilities:

• Password policy is weak
• Password policy is strong, but not enforced
• No account lock out (or worse, account lockout tracked at the client side)
• Login error messages let me know whether the username is valid
• Password hints!

Related error messages from a recent find at a travel site:

• “A password must be 5-12 characters long and have no spaces.”–when registering an account.
• “The e-mail and password you have entered do not match. Please try again.”–when attempting to log in with an invalid username or password.
• “That e-mail address is not on file. Please try again.”–when attempting to display the password hint for an invalid account.
• Note: the password hint is happily displayed if you enter a valid username.

Some initial thoughts

• How easy is it to harvest emails or buy a few million email addresses?
• Could a quick script cycle through a list of email addresses and capture password hints?
• How difficult would it be to guess a few password hints based on several hundred or thousand captured password hints?
• This site allows you to save a credit card on file and use it to book travel/hotels/more without verifying anything.
• I wonder if I could book travel on someone else’s account without them knowing. All I need to do is suppress the email confirmation or point their registered email to a different one. By the time the con has been exposed, the postcards I sent from Mexico will have been received.

Do you see where this is going? The main culprit wasn’t the password policy itself. If I had to write the equation, it would look a lot like this (seriously):

Mediocre password policy + password hints + stored credit card info + having a lot of users + nongeneric error messages + not verifying anything on checkout = free trip to Mexico.

Now, let’s go cliff diving in Acapulco!

Wireless technology has slowly but surely evolved from a luxury to dependency and unless you’ve been living under a rock for just about the last century (no offense to ants, worms or other insects), you’ve started to notice it everywhere. From airports to coffee shops, even to the park across the street, wireless technology is available for your use. Sometimes you have to pay for it and sometimes you don’t, but one thing remains constant for any public use WIFI: it doesn’t care about you! I’m not saying wireless is a technology with or without feelings, I’m saying that every wireless (802.11) provider isn’t taking care of your security, so it’s about time you take the initiative!

Some providers and airports may provide the service free of charge with no questions. Others will force you to a Captive Portal which will allow you to connect, however once you try to access any URL, you’ll be redirected to a login page where you can pay or use your existing login information to ultimately obtain access to the internet via the wireless. This may be a false sense of security for some users as they may not realize that the data they are transmitting is sent in the clear across the network. Remember, authentication does not equal encryption!

If you’re traveling with an attacker in your mists, you’ll probably never notice him but be assured he’ll notice you! All “Johnny Hacksalittle” needs is a wireless card and a 802.11 sniffer (wireshark, kismet, etc..). By locking on to the channel with the most clients and applying the following filter in wireshark an attacker is provided with all of the client’s HTTP activities:

Wow, that was complicated! (can you sense the sarcasm? ) With this trivial technique, an attacker can literally recreate any of the users HTTP activities from the time they start their sniffer to when they stop it. Even more devastating is if the attacker reuses exposed session cookies which would allow him to access any websites you’ve authenticated to without even knowing your username and password! Robert Graham got a good amount of press when he recently publicized how Gmail momentary used HTTP during its login phase which exposed its users session IDs. Although, if the attacker is watching while you’re accessing a website that requires authentication, he can easily filter for HTTP POST requests using “http.request.method eq POST” and potentially sniff your usernames and passwords.

All of this is simply because the 802.11 wireless provider is not using the built in encryption with 802.11, nor are they using any additional mechanisms to ensure the security of your connection (remember they don’t care!). I’m not saying that these 802.11 wireless providers are evil people, they are giving you a service and in turn you are accepting the risks by using that service. So if you still want to use the wireless you just have to be mindful of a couple things.

1. Before entering any data into any field on a webpage, check the URL bar for “https://”. Because HTTPS encrypts all of its data, any of sites the client visits which start with “https://” will not be exposed to this attack, but there are other slightly more advanced attacks which can ultimately trick the user into exposing their sessions. SSL won’t stop the attacker from identifying the website you’re visiting, but it will definitely protect all of your data. Don’t forget what Juan Bocanegra was saying in his blog post, “On the importance of SSL”!
2. If you’re lucky enough to have VPN to your place of work, validate that split tunneling isn’t enabled. An easy test is to go to http://www.whatismyip.com before and after you connect your VPN client. If your IP changes, it’s likely that split tunneling isn’t enabled. With split tunneling enabled, only certain traffic is forced through the tunnel, so you really want to make sure split tunneling is disabled first. If it is, set up your VPN connection and use that to encrypt all of your data. The only downside to this is that you may be subject to the corporate internet filter.

HTTP is used as an example here because it is very common for users to relate to, but this is an issue with all protocols. If there is not built in encryption with the app/protocol you’re using (AIM, telnet, etc..) your activities can be easily monitored by an attacker without you even knowing it! Knowledge is protection (and so is an EVDO card), so be smart about what you’re doing.

A common security theme in corporate America is to secure the outside Internet from the safe intranet. As a penetration tester, I’ll tell you that if you have over 1000 employees there is no “outside”.

Firewalls, NAT devices, and anti-exploitation techniques have made traditional remote exploitation extremely difficult. Pure remote exploitation over a technology such as RPC, IIS, etc still occurs but it’s much less common. Instead, attackers have transitioned to user driven attacks such as phishing, malicious emails, malicious websites, or malicious documents. The basic idea is to get your users to exploit their box for the attacker. Once the user does something unwise, the workstation inside your network is owned. If you have 1000+ workstations, there is virtually no chance that one of your employees won’t eventually enable this type of attack. When you factor in USB sticks, Wifi, VPN access, and laptops that travel, no reasonably large network can assume the internal network doesn’t touch the Internet.

Now that we’ve established the Internet can get into your internal hosts, can it get out?

Brad Antoniewicz’s recent blog describes several data exfiltration techniques. I’ve had success with DNS tunneling. Almost every firewall allows outbound DNS queries and the technology is well proven. Once your local workstation has been exploited, DNS tunneling will let the data out. However, my favorite technique is simple HTTP. First, outbound HTTP access is almost as universal as outbound DNS. To me, there are several benefits of HTTP traffic over DNS Tunnels:

1. DNS tunneling is innately anomalous – the messages are larger and more frequent than normal. Similarly, you’re likely ignoring TTL values. All of these can be red flags

2. Programming an HTTP tunnel is simple. You setup a fake page, setup a trigger value for data, post/get data as needed. You simply need to use the straightforward MS InternetOpen() and similar functions.

3. Many hosts now have firewalls that prompt to allow outbound access by application. In general, it’s best to use DLL injection to hook your callback into IE to get its access and to use any proxy authentication that may be needed. This technique almost always lets me out to the Internet from a workstation.

In various penetration tests, I’ve successfully used remote access tools that utilize HTTP traffic by hooking IE. It’s been VERY effective. Do you have technology to prevent this type of remote command and control?

In closing, as you design your network security policies and deploy technologies dependent on being safe from within, I encourage you to think of both how threats get into your network and how they can get out. If an attacker can do those two things, depending on your perimeter, this is asking for a security incident.

One of the many topics I like to cover in detail when teaching Essentials of Hacking and Ultimate Hacking is password brute forcing and cracking. I usually start off by letting the students come up with what they think is a strong password policy and later, we analyze common implementations & attacks against them. Inevitably, the password policy they come up with looks a lot like this:

• At least one uppercase character
• At least one lowercase character
• At least one digit
• At least one symbol
• At least 7 characters

A quick analysis of this password policy yields the following:

• Character set is roughly 52 alpha characters + 10 digits + ~12 symbols
• Password length is >= 7
• Most people will pick a password that’s 7-8 character (we’ll compromise here)
• Password keyspace is approximately 74^9 = 66540410775079424 or ~6.7e16

This password policy is inline with what I see on most security engagements. However, the matching implementation that enforces these rules is not as common, but that’s another blog entry. Still, a password policy like this is the common case.

Here’s my password policy (just trying to prove a point here):

• All lowercase characters
• At least 15 characters
• Non dictionary words

A quick analysis of my password policy yields the following:

• Character set is 26
• Password length is >= 15
• Password keyspace is approximately 26^15 = 1677259342285725925376 or ~1.7e21

Let’s figure out which password policy is stronger by using Cain & Abel to test the time required to brute force passwords that are MD5 hashed, which is a common case for web applications.

Exhibit A:

Here’s Cain & Abel attempting to crack all possible passwords for the typical password policy.

Exhibit B:

Here’s Cain & Abel attempting to crack all possible passwords for my password policy.
The bottom line:

• In general, password length trumps password complexity. This applies to both cracking and rainbow table attacks.
• Given the opportunity, users will choose the simplest passwords, such as ‘Password1!’, , etc. If you don’t believe me, check out an analysis of the ‘hacked’ Myspace accounts.
• Make sure you account for human tendencies that include usernames in passwords, too many repeating characters, passwords based on dictionary words, capitalization of the first letter, symbols & digits at the end, etc.
• Enforce your password policy – duh. Rememer AOL’s old implementation?

Corny titles aside, you might be surprised all of the ways that your “secure” internal corporate data can become unsecured public information by one disgruntled employee. Data leakage is when your internal corporate data is released to the public or anywhere else that is not in your control. This can be performed mainly in two ways, where the number of variants of each method can be virtually limitless.

• Physical removal of the data via hardcopy or softcopy on removable media
• Transfer of the data over the internet via email, FTP, SCP, etc..

Did I say limitless variants?! Yikes! So how do we prevent this? Well it’s rather unlikely that all of your employees will go under a strip search to validate that they do not have any paper shoved down there pants, but if we don’t allow access to those documents in the first place, and if we make sure they are properly disposed of (i.e shredded) when they are printed, it might be possible to limit some of our exposure

These physical threats are tricky issues that may never be fully solved, but they are extremely important to mindful of. In this post, we’ll focus on the non-physical side of data leakage. Right off the bat, lets disable the easy stuff:

• Discontinue the use of writeable CD/DVD drives on your client systems. There’s normally no reason for the average user to burn CD/DVDs. It might be a good idea that a manager or someone with a higher privilege to first filter this data before burning the data to disk. That is of course, you trust your managers.
• Disable USB/Firewire storage and removable media. You can disable USB all together if your company is not USB keyboard/mouse dependent.

These two basic things will force our mischievous friends to look at the internet as a means of transfer. On nearly every firewall/architecture review, I have one finding that states “Inadequate Egress Filtering”. Egress filtering is controlling the traffic leaving your organization, or traversing from a trusted to untrusted zone (i.e internal network to internet).

Although most companies I work with may or may not have a proxy server to scrutinize outbound traffic, they also have a ton of additional services permitted through the firewall, thus the “Inadequate Egress Filtering” finding. An additional problem that compounds this issue is the separation between the security staff and the firewall staff. This problem makes it hard for the security staff to accurately assess the firewall policy, and thus forces them to test these things on their own. To address this issue security staff can simply set up a host which has all ports open and place it on the internet. Use nmap to portscan the host:

nmap –sT –p 0-65535 [host]

What this will do is check which ports are allowed out through the firewall. There are some online services that will let you do this as well and even some messaging programs will have all ports open on their login servers. With the information presented by nmap, we can then get an idea of the existing potential areas for data leakage.

It’s extremely important to understand that any service can run on any port, which means that even the smallest allowance can permit someone to transmit data out to the internet. Let’s look at some common methods:

SSH Tunneling: Attackers can easily tunnel anything they’d like over SSH and as we mentioned, just because the default port for SSH is TCP/22, doesn’t mean it can’t run it on any other one. SSH can also be proxied, so application filters are even more important. Bottom Line: If an attacker can get SSH outbound, they can do anything!

DNS Tunneling: OzymanDNS (http://www.doxpara.com/ozymandns_src_0.1.tgz) can tunnel SSH over DNS! Yes, over DNS. So think twice about that permit udp any any eq 53, internal users should hit an internal DNS server which is responsible for its outbound queries.

ICMP Tunneling: If all else fails, attackers my try PingTunnel (http://www.cs.uit.no/~daniels/PingTunnel/), which as the name implies, allows SSH over ICMP! This kind of thing may make you think twice about allowing ICMP outbound to any host. If your network engineering staff really needs that as a tool, consider allowing ICMP only to particular hosts.

In an ideal situation, you’d have no outbound allowances without first being forced through a proxy server with application layer filtering. Even then, you only allow HTTP/HTTPS. You can then use a variety of software that will look for certain strings in HTTP/HTTPS or instant messaging sessions then ultimately notify you or prevent them from sending the data that matches. This is an excellent solution and should be deployed everywhere, for more information, Google “Data Leakage” and those applications will present themselves to you.

This isn’t meant to be fully comprehensive, but to just show the risks associated with the smallest allowance. If you can limit traffic outbound and scrutinize it where ever possible, you should be ok. Well… that’s if you try not to think about employee EVDO cards or test DSL lines that terminate at employee cubicles. =]

Recently, I started a review of what I thought was going to be a standard web application penetration test (WAPT). I began growing a little suspicious about this app when the client mentioned that I *had* to use IE to interact with the server. I always find amusement in statements like “This website is best viewed using Internet Explorer x or above”.

As soon as I hit the website (before logging in) the server tried to push down a large bundle of files (including an executable). Playing the role of a regular user, I happily signed my system’s security away, by allowing all these files to be downloaded to my test box. As soon as the download was complete I proceeded to authenticate to the website. After authentication, the custom web browser pops up. I’m now thinking ‘Great! This WAPT just turned into a WAPT + reversing gig’.

After toying around with some basic binary analysis/reversing techniques, I learned enough about this custom browser to deduce it was written to standard Win32 and contained nothing potentially dangerous for the end user. Now, moving on to the actual testing of the application…

I started off by doing the basics: configuration management testing, authentication testing, etc. Immediately, I was faced with figuring out how to proxy these requests. Once you move away from a standard web browser and all the tools written for it (e.g. Firefox and it’s awesome extensions), I was a bit confused as to the best technique to use to MITM this app. That’s when a fellow Foundstoner pointed me to Fiddler –I can’t believe I haven’t used this proxy before! Fiddler proxied this custom browser flawlessly.

After some initial testing, I can tell you this browser is most likely an attempt at security through obscurity. I have no idea why it was created. It brings nothing to the table in terms of features or security. Here’s just one of many examples why:

Note: Certain fieldnames have been removed to protect the innocent.

Problem #1: Session ID in URL – classic. Read this OWASP page on session management for more information.
Problem #2: Sequential user IDs – also a classic.
Problem #3: This request is gladly accepted by the server. And, although you can’t see it, your password bypasses validation.
Extra credit – Problem #4: (A closer look at Problem #2) Why would this request contain a user ID? Guess what happens when you change the value of this ‘id’ parameter? Privilege escalation!!!

Bottom line:

• There are many significant issues in this application and most others.
• The custom browser seems like an attempt at getting the end user to play by certain rules. Those rules should also be enforced at the server side.
• If you haven’t played with the Fiddler proxy, you’ve got to check it out. I used to think that all proxies were mostly the same – they’re not.
• Make sure all your application developers, designers, architects, managers, etc are all familiar with OWASP and software security fundamentals.

A few security researchers are branching out into a new subject matter that is sometimes called “Passive Host Characterization” (PHC). I had the good fortune to work on one of these projects so I thought I would share a bit of that experience.

PHC is much like a passive IDS system – the two are distinct, but a passive IDS is the closest relative to PHC. The basic idea is to deploy sensors around your network to passively monitor traffic. Rather than looking for signatures, you’re going to focus on rules that collect data from the observed traffic. For example, you might grab browser User-Agent strings or OpenSSH Server strings. Additionally, it’s quite common to employ a network based OS identification system, such as P0f. The basic concept is very simple. Collect OS info, server strings, client strings, DNS info, or other simple data and data mine it. From an engineering perspective, the situation is quite difficult as you must back-haul, process, and store the data, but the fundamental task you’re performing is relatively simple.

There are two such applications that I’m aware of. The first is the TRICKLER project by the NSA. The software is unclassified, open, and available from their technology exchange office. The second is Tenable’s Passive Vulnerability System (PVS). Both have their own pros and cons, but for this post I’m only interested in the technology.

Now, what can you gain from such technology? From my experience, the answer is as varied as your imagination. Here are some examples:

1. Policy Auditing – when you know what’s on your network you can see what shouldn’t be there. Client strings, such as for XBOX 360 showing up on your corporate network or a random telnet server can easily point to problems.
2. Patch Management – inventorying IT is a nightmare. I’ve never seen an organization that hasn’t had a box (or VM) that they couldn’t find. With PHC, if the box talks on the network (ie if it’s a risk) then you can find it and know about it.
3. Penetration Testing – if you have PHC information available for a pen test, the game is almost already over. While passive OS identification is weak and client/server strings are changed, they’re usually not and combined together you have a great idea of what the network looks like. Banner grabbing is a first step in a pen test. To instantly have so much information lets you pick and choose the right targets and create very little noise. Caution though, this is a double edge sword. Good guys and bad guys alike can use this information.
4. Data Exfiltration Detection – one of the cooler data exfiltration techniques is misusing DNS. PHC can characterize typical DNS traffic (by volume, message size, whatever you choose). If you see frequent large DNS messages you might have a problem. This isn’t a theoretical attack, vendors have products that do this.

I’ve seen the 4 above examples used very effectively at very large organizations. But again, the uses aren’t limited to the above. I’ve conjectured about tracking down the Storm botnet. I’m NOT a Storm expert, but it appears that Storm uses the so called “fast-flux” techniques. Essentially, it uses DNS changes and proxies to rapidly change where A-Names point to. This enables the proxy to use a domain name, but to move from IP to IP very quickly. PHC as mentioned above, can characterize DNS traffic. Simply write a rule that detects DNS names with many expired A-Records or DNS replies with extremely short TTL values. Very quickly, you’ll likely start to see hosts that are in a fast-flux botnet…. From there, maybe you can characterize those hosts?

Every Web Application Penetration Test (WAPT) kickoff call usually starts with a brief discussion of why the client has hired us to perform this WAPT. Typical answers include:

• “Well, our application is mission critical and we want to test the security of it…”
• “We store a lot of personal information on this web application and we want to make sure ‘hackers’ cannot access the data…”
• “There was a security breach and we want to prevent other incidents from happening…”

Most of the time, clients are spot on regarding the importance of their web applications. And with their business goals in mind, we go through our comprehensive WAPT methodology and usually end up tearing their web app apart. But the part that troubles me most is when I see these apps aren’t covered by even the most basic protective mechanisms, such as SSL. If you need a review of SSL go here.

In general, SSL provides you with confidentiality, end point authentication, and message integrity. That’s a pretty big point to miss with these ‘mission critical’ apps. Just consider some vulnerabilities you’ll face if you don’t bother using SSL:

• Eavesdropping – Sure show the world your cookies, login credentials (BTW, what are the chances that your super strong username/password combo are used elsewhere?), etc.
• Man in the Middle attacks – all too easy and you can’t even verify the authenticity of the server you’re supposed to be connected to.

Anyway, the point is that adding SSL to your app is ridiculously easy and every app should be covered by it – on all pages, not just use it for authentication (which unfortunately, I’ve also seen plenty of times). Oh, and make sure your SSL cert is valid (signed by a trusted CA, not expired, and not on a CRL); use strong ciphers; and use SSLv3.

Here’s an interesting SSL related exercise for the reader – find the SSL lock icon on Myspace.

Hint #1:
From myspace (http://www.myspace.com/index.cfm?fuseaction=misc.privacy):

“Security
MySpace.com member accounts are secured by member-created passwords. MySpace.com takes precautions to insure that member account information is kept private. We use reasonable measures to protect member information that is stored within our database, and we restrict access to member information to those employees who need access to perform their job functions, such as our customer service personnel and technical staff. Please note that we cannot guarantee the security of member account information. Unauthorized entry or use, hardware or software failure, and other factors may compromise the security of member information at any time For any additional information about the security measures we use on MySpace.com, please contact us a privacy@myspace.com “

My take:
This sentence reads well and gives me warm fuzzies: “MySpace.com takes precautions to insure that member account information is kept private.” But where’s the SSL? Now, how many *millions* of users are now vulnerable to the aforementioned vulns? Don’t get me wrong, a malicious user doesn’t care about your myspace.com page. I’m sure it “teh sucks” and your profile is “teh fail” (to quote a buddy at Foundstone, Brad Antoniewicz). They’re after your credentials & betting big on password reuse. Stop for a moment and think about your own work, Ebay, email, bank, etc accounts. Are you reusing your credentials anywhere?

I bet most of you are. After all that’s just human tendency…

Its been a little bit of a wait, but I am sincerely happy to welcome everyone to the first ever posting in the Foundstone Professional Services section of the Avert Labs Blog! We’ve been working hard to continue to give back to the community that has given us all the knowledge that we’ve acquired throughout the years, and hopefully this will serve as an entertaining, yet insightful resource. Again, Welcome aboard, and keep a close eye on the page as there will be more to come!