Those who have worked with me, or at least had a beer with me, know my feelings on web based SSL VPNs. They are very useful, very complicated, and can be very insecure. Useful because they allow a mobile work force to connect to the enterprise from any computer with a web browser; complicated because they need to do so with minimal inconvenience to both users and network managers; and insecure because this convenience is achieved through automation.

The automation starts with the browser based installation of client side components (ActiveX/Java applets). Network teams, management, and help desk personnel alike, love the fact that users can get the required client side software simply by visiting a web site. Once the components are installed, they can even maintain themselves by automatically download and installing updates and patches! Hallelujah!

Unfortunately, this type of behavior can be easily abused as Haroon from Sensepost has revealed. He disclosed a vulnerability in a Juniper SSL VPN ActiveX control that allows an attacker to execute code on a victim machine by getting them to view a malicious web site. The vulnerability is simple to exploit; the malicious web page invokes the ActiveX, calls one of its functions, and the ActiveX sends an HTTP request to the web server asking for commands to execute on the client machine. No stack smashing required!

Funnily enough, I reported an almost identical vulnerability to another large SSL VPN/firewall vendor. This other company makes it even easier. Instead of requesting a string of commands, their ActiveX will request, download, and execute an attacker supplied .EXE file. No signature checking or anything. Altogether, I have knowledge of these types of vulnerabilities in 4 of the leading SSL VPNs. Details will be discussed pending responsible disclosure.

We all know that SSL VPNs have similar features – you can spend days comparing vendor product descriptions. What I find interesting, and have spent much time researching, is that while SSL VPNs from different vendors share the same features, they also share the same vulnerabilities in their application logic. This research has provided most of the material for my upcoming talk at BlackHat 2008, “Leveraging the Edge: Abusing SSL VPNs”.

My talk is in the network track, but a lot of what I’ll be talking about is purely application security. This is funny to me, because during my time at Whale Communications (a Microsoft subsidiary) supporting Whale’s SSL VPN, the device was usually managed by network people who were not versed in application security at all. The “networking” (and security) in SSL VPNs terminates with the SSL connection. Beyond that, abusing gaps in access control, and other areas of application logic, can provide an attacker with all he needs to compromise clients and the networks they connect to.

-Schmoilito

A few weeks ago I was looking into writing an application for my iPhone. At some point, I felt compelled to actually give it a shot, and I headed over to Apple’s web site to download XCode and whatever other tools I needed. Of course, I couldn’t remember my Apple developer center password, so I went through their “Forgot Your Password” routine on my Dell laptop.

A few seconds later, an email popped up on my Mac containing their magic link to pull up my change password form. I clicked it and went through the reset process, which ultimately asked me to authenticate with my new password.

Finally, I was redirected to the URL I originally requested . . . on my Dell. Hmm. How did my Mac get to where my Dell originally was?

Turns out Apple was maintaining a session for me on the server which retained my original URL. When you requested a URL that required authentication, Apple 302′d you to the login page with your desired URL contained in a query-string parameter. Once on the login page, you could tamper with the URL before it was stored in the session. You could also then enter your username (or, even better, someone elses’) and initiate the change password process.

When you chose to have Apple send you a link to change your password, the session you started with your original URL persisted via the data contained in the link. After you went through the process of changing your password and you finally authenticated, Apple sent down a small HTML file with a META-REFRESH tag that actually sent you where you originally wanted to go.

It is in this HTML where the badness happened. The original URL Apple stored in the session was being written here without being HTML encoded or properly validated. Apple did prevent you from specifying http://attackersite.com, but they did not validate against iphone.html”><SCRIPT>…</SCRIPT>.

The attack would have been as follows:
1. Tamper with the original URL and inject an XSS attack.
2. Enter someone elses’ username in the logon form, and click “Forgot Your Password”
3. Have Apple send the victim the password reset email.
4. Here is the kinda far fetched part: you need to hope/pray/socially engineer/somehow get the victim to go through the password change process, and authenticate.
5. Once they authenticate, you own their browser.

This attack is interesting to me for a number of reasons. First, it is a persistent XSS attack in a credential management system (ouch!). Second, the injection point is pre-auth, while the payload executes in the victims browser post-auth. Third, it is very easy to target individual users using legitimate emails from Apple: no spoofing required!

Apple was very quick to fix the problem, and even gave us credit here.

Good job Apple!

-Schmoilito

A few weeks ago I was grabbing a couple of beers in town with my buddy, John. We had a couple of rounds before John noticed what he thought was a Nintendo Wii sitting at the back of the bar, next to a cash register/point-of-sale terminal. It definitely was a Wii, but even more interesting to me, was a wireless access point right next to it in plain site.

John was probably excited at the possibility of playing Guitar Hero. I, on the other hand, wondered if the Wii and the cash register terminal were all on the same network, along with the WAP.

After a few more drinks, I developed the following equation:
Wireless Access Point + POS terminal = free beer

I pulled up the list of the available wireless networks on my Iphone, and sure enough there was one with the name of the bar. Unfortunately, it was encrypted. Time to break out the social engineering skills.

Me (to the bartender): “Hey, I’m trying to show my buddy my blog on the Inter-”
Bartender: “Oh! You need the password! Hold on one sec, let me ask the manager.”
…1 minute later…
Bartender: “Try clubbarroom”
Me: “That worked. Thanks.”

I didn’t go any further at that point, since that would be unethical. My buddy was also already impressed that I got the password without even directly asking for it.

However, I couldn’t help but wonder what kind of data is actually at risk. They obviously swipe credit cards on those point-of-sale terminals. I’m also sure that the bar doesn’t have a security budget or staff, other than the human firewall who was checking ID’s at the door. If credit cards could be stolen from T.J. Maxx, why not a rinky-dink bar in Hoboken?

I don’t need to wonder so much any more. On Monday, news agencies started reporting that three men were charged with installing packet sniffing software at a number of Dave & Busters locations here in the U.S. From one location near me in New York, they were able to obtain 5,000 credit/debit card numbers.

Obviously, companies that do business on the Internet need to be aware of security issues surrounding credit card transactions, and many are well aware that they need to be PCI compliant. But what about small brick and mortar shops, bars, restaurants, etc? They think they are immune from all this hacking/identity theft non-sense because they don’t take credit cards via a web site.

Hacking one large online retailer like Amazon may prove lucrative, but could be difficult and dangerous to pull off AND get away with. Small businesses on the other hand, lack the technological expertise to protect themselves. While each target individually may not contain the wealth of sensitive data that an Amazon or eBay has, these soft-targets, collectively, could be just as lucrative.

-Schmoilito

Most vulnerability scanners will allow you to configure an exception list. If an organization has an internal vulnerability scanning program in place they are probably aware of a few troublesome systems that don’t respond well to poking and prodding.  (That ancient VAX, those Dell DRACs, that crazy plotter, etc…)

It’s not uncommon to be asked by a client to “Avoid this list of systems during the Pentest…” But what if you have some nice custom tools that don’t have the ability to honor an exception list?  What if you have some tools that you point to an NT Domain and not an IP list?

On the surface the simplest solution would be to “just configure the firewall to block outbound to x.x.x.y….”  The problem is windows personal firewalls don’t make it easy to do that. In fact, most of these firewalls will break the scanning tools you’re trying to use. 

I’ve found that Peer Guardian 2 does an awesome job at fixing this problem.  Peer Guardian is mostly used by peer-to-peer users but you can easily make a custom “block list” that will prevent your computer from hitting IPs on your client’s exclusion list.  You can run Peer Guardian and not worry about it mucking up those funky packets that youre trying to send.

-higB