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.

Many websites utilize a challenge-response mechanism know as CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) to protect against automating the creation of user accounts, content, or otherwise abusing services they provide.

Most common CAPTCHA systems work by generating distorted characters, text, or pictures that can be easily recognized by the human brain but present significant difficulty for computer OCR (optical character recognition) or other image recognition systems.

Enter Social Engineering. Although CAPTCHA may be fairly effective at verifying a reply is from a human and not a computer they do not guarantee that it is from the human for which the challenge is intended.

Example…

1. Website A hosts a service protected by CAPTCHA verification.
2. Website B is set up by a party desiring to automate usage of the services of Website A.
3. Website B offers users free access to content, but requires they defeat a CAPTCHA challenge.
4. Website B copies a CAPTCHA image from Website A that it needs defeated and presents it to a user visiting Website B.
5. The user provides the CAPTCHA response.
6. Website B provides the offered content to the user, and then uses their response to defeat the CAPTCHA test on Website A.

In this way automation residing on Website B can distribute the work of defeating CAPTCHA challenges to many people that are unknowingly providing responses to challenges from Website A. In some ways it is similar to a distributed computing model. Instead of distributing tasks out to computers however, the idea here is to distribute the CAPTCHA tasks out to humans.

This method was used by spammers 1994 to defeat a turing text-based spam protection mechanism in Microsoft’s Hotmail service. The spammers promoted a Web site containing pornography and required visitors to enter a CAPTCHA before they are were granted access. The CAPTCHA that were used to access the porn site were originally generated by the Hotmail service. The CAPTCHA solutions entered by the visitors to the porn site were then used by the spammers to solve the CAPTCHA challenges in Hotmail, allowing them to automate the creation of new accounts for sending spam.

More recently, trojans such as Captchar have been utilizing this method as well.

Although it is possible to identify the difference between a computer and a human there may yet be a challenge in verifying that a given human response is from the intended human.

Apple’s shiny new cat is out and it’s not just pretty, but also features some good security enhancements seen for the first time in the Mac OS.

One of the key security features of the Leopard OS is Sandboxing. Sandboxing restricts the sandboxed application to be only able to perform actions or access resources based on whatever they are supposed to do. For example a sandboxed application will only be allowed access to certain files or be restricted to whether they can access the network or not.

By default, however, only a few Leopard applications are sandboxed, like the Helper applications which is used for enabling Spotlight or Bonjour. Surprisingly applications like iChat and the Safari browser, which are generally the first target of attackers, are not sandboxed. Apple, however, might have plans to add them in a future Leopard 10.5.x update.

Lack of API documentation for third-party developers to sandbox their own applications limits the usefulness of this feature right now. However, this may get resolved in the near future as well.

Overall, it’s a big step in the right direction.

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. =]

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?

I just read another story that talks about the overreaction to the new Mac OS Trojan, the threat first reported by Intego the other day. Generally the arguments make these points:

• There are far fewer threats for Mac OS compared with Windows
  [my response: True, but it takes only one to get infected.]

• You’re at risk only if you’re surfing porn
  [my response: False. Although the initial report stated porn sites were driving people to the malware, McAfee Avert Labs has found dozens of domains serving the malware, none of which was explicitly related to pornography. They are related to installing a video codec for the purpose of viewing movies in general.]

• A user must take extraordinary actions to get infected: download a file, open it, run the installer, enter in the admin password
  [my response: Yeah, so? Bagle was one of the most successful pieces of malware targeting Windows users. Many variants came as a password-protected ZIP archive attached to an e-mail message. The password was sent as an image attached to the message. Before getting infected, a user would have to open the suspicious email message, open the suspicious ZIP attachment, manually enter the password provided in the other email attachment, and then run the virus. Result: many many thousands of users getting infected. Password-protected archives are an anomaly for most users, on Mac or Windows. I contend that the social engineering around installing a software package to watch a video is greater than that of having to enter a password provided in an email message simply to access what’s supposed to be a photo.]

Having said all this, these points are not what make this threat significant. What sets this threat apart from other proof-of-concept Mac threats and low-scale attacks is the entity behind it. Puper (a.k.a. Zlob) is one of the most widely reported pieces of malware for Windows. McAfee VirusScan Online users reported more than 4 million detections during the past two years. Microsoft’s latest security threat report states Zlob was the most frequently disinfected piece of malware. Unlike earlier Windows malware, this Mac Trojan is authored by professionals who likely pull in thousands of dollars a month through click fraud, hijacked affiliate sales, and other illegal activity.

I have to admit that when I first heard rumors of some new Mac Trojan being reported from a vendor I hadn’t heard of, I figured it was likely hype. But when I learned who was behind the threat, I knew this was real.

Now after all of this doom and gloom, I should say that we were able to contact two universities that have rather large Mac user bases to see if they showed traces of infected systems. Thus far their log files show no sign of infection. Thus far.

It took a long time for the Windows threat landscape to evolve to where it is now. Yes, the Mac threat landscape is far behind and will be for a long time, but what OSX/Puper represents is not something to take lightly.

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.

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.

People will sell you almost anything for your mobile on eBay, headsets, cases, replacement power adapters. Recently while looking for a data cable for a phone I ran across mobile “spying” software for sale.

We’ve run across relatively expensive commercial mobile spyware before. This was being offered at a tenth of the price with a lot of similar features. The software claims to allow:

• call monitoring
• reading text messages
• copying phonebook entries

Fig 1 - Capabilities claimed by the software

Other claims of compatibility with and control of a wide range of phones may just be hype on the part of the seller. Some of the sellers suggest that buyers install the software on phones and offer them as gifts or for sale to the unsuspecting. It’s interesting that dozens of sellers were offering nearly identical software. This is usually an indication that the item being auctioned comes from a common source. Buyers should be wary of such auctions.

eBay will take down auctions with objectionable or malicious content if requested. Some auctions may not actually break the rules or just come very close to the line.

Sellers will sometimes repackage publicly available information or open source software and set up an auction with terms like “Brand New” or “latest Pro version” in order to convince buyers that they’re getting a good value. There are also sellers offering CDs full of J2ME games. The prices for those collections imply that the included games are either freely available or pirated.

The cost of the software might be attractive, but none of the sellers offer any support. If it won’t run on your phone, there are no refunds. Even when the software is delivered on CD, no replacements are offered if its damaged in the mail. Occasionally pirated software is also sold in this manner. A number of the spying software auctions are actually selling links to download the software.

Rumors circulate periodically about the approaching of a cyber jihad against Western websites. In October 2001, hackers in Pakistan declared such a battle against the US and Britain, and as early as 1995 a strategic exercise simulated an information attack on the US and its allies ( Time Magazine, August 21, 1995 Volume 146, N°. 8 ).

More recently, the controversial alerts of August 2004 and November 2006 caused us to handle such information with an enormous amount of caution.  It is why, up until recently, we did not relay the last information given by an Israeli intelligence magazine reporting that such attack was announced for November 11, 2007.

However, yesterday we received a sample of a program that some have connected with this attack, and as many comments circulate today on the Web, I decided to blog on this matter.

The program is pompously named “the electronic program of Jihad” and is quoted as version 3.00. Its icon matches the one DEBKAfile presented in his November 7 article: the symbol of all Qaeda’s Cyber Warriors.
http://www.debka.com/headline.php?hid=4723

Once installed, the program asks for a username/password to join the attack network and attempts to connect to a cyber jihadist coordinating web site. Today this site is unreachable.

Another window seems related to some bonus program: you can win 24 points by referring a newcomer.

As for now the pilot website is down and I was unable to continue the analysis, but the following screenshot is available on the Anthropologist blog.

Like previous versions, it seems the program can only initiate basic DDoS attacks and as written by the Register, some are skeptical of this attack.

Attacks against websites happen every day for criminal, political, and/or hacktivist reasons and this one, if it occurs, will be added to that long list.

I wrote this blog entry to demonstrate that at least one terrorist ring is interested in malware. But it seems to me, they have not reached the technical level of some criminal groups, for now. In this case, no fast-flux network was involved; no complex Command & Control protocol was committed, no worldwide botnet was created. They are years behind! Shutting down the distribution website stopped the attack before it starts.

It is why I’ll say good and quiet November 11 to you.