I just got back from the IT Security World Conference & Expo 2008.  This was the first time I’ve attended this conference. The speaker line up looked good. I wasn’t there to see the speakers though; I was an exhibitor working a phishme booth.

I’ve spoken at DefCon, BlackHat, Shmoocon, etc…. but at this conference, I wore my exhibitor badge, which might as well have read “leper”.  Hah, not that I can blame the attendees for treating me like a leper, after all, I was just another exhibitor in the gauntlet they had to run in order to get to the drinks and snacks. 

When you brave the booth gauntlet, you’re bombarded by shiny people. Appliance after appliance, magic boxes that make all your IT security problems go away.

My booth was at the end of the gauntlet. It was entertaining to watch attendees pickup my swag without missing a step, only to read the banner that says “Phish your employees” pause, double back, and curiously ask me  “what is this?”  Most would chuckle after figuring out exactly what phishme.com does. Eyes popped out of heads of the ones that actually saw the demo.

There was something about the conference and expo that REALLY bothered me……

The sad thing was these Internet terminals were in heavy use throughout the conference. Every time I walked by them people were in their email. 

-higB

Authenticating to a web application is a mutual process. Before a user enters credentials into the application, they validate the web applications credentials: its hostname, content, and SSL certificate (assuming it uses SSL).

Essentially, you validate the web site against what you know to be true (hostname and expected content). The browser validates that a trusted third party signed the web sites public key, and together they vouch for the sites identity by showing you a visual cue.

If the web site passes your personal validation and you decide to provide them, the application will take your credentials and validate them against what it knows to be true: a directory or other repository with user information. If it validates your credentials, it lets you in.

Dan Kaminsky’s DNS flaw makes it possible for attackers to spoof one of the three credentials web servers use to authenticate against users: the host name. The look and feel of a particular web site is already easy to spoof: phishers have been doing this for years. The only remaining credential the web server has that can’t easily be compromised is its SSL certificate, and the signature of a trusted third party (one of the commercial certifcate authorities).

Now that two of the three credentials could be spoofed, I started wondering how hard it would be to spoof the third. If you can get a valid SSL certificate, you can completely steal the identify of a web site. Unfortunately, it is not too dificult, and it is through no technical fault of the SSL protocol.

For me, it required no social engineering, no illicit hacking or ninja skills. In fact, it was kinda scary in its simplicity, and the real fault is in the process of the certificate authority (a big one). Is it that bad? I attempted to get certs for three HUGE Internet sites, and I was successful with one. An interesting application logic problem prevented me from getting another, and the certificate authority basically told me no (over the phone) for the third. The one I did get, however, is a biggie.

I’ll drop the details at the beginning of my SSL VPN talk at BlackHat next week. I won’t divulge them sooner. Not even if Matasano kidnaps me, sends me overseas, and water boards me.

-Schmoilito

We’ve all seen it now. Some lawyer at some company decided it would be a good idea to append legal disclaimers and notices at the end of each email. Now everybody is doing it. They usually read something like this:

Privileged and Confidential
Blah blah blah
Disclosure to 3rd parties other then the recipient is strictly prohibited
Blah blah blah
You may not forward, redistribute, or make public the contents of the email.
Blah blah blah
If you received this email by mistake you must immediately delete it
Blah blah blah

Whatever happened to the email in YOUR inbox being YOUR property?
Thanks to some legislatures and the Internet Mail Consortium, operators of mail gateways, can give notice to spammers that their mail server cannot be used for delivering spam.  But I see a better use for the SMTP banner:


220-xxx.xxxxx.xxx.x ESMTP Exim x.xx xx Thu, 19 Jun 2008 12:48:30 -xxxx
220-NO UCE. You are hearby notified that ANY email sent here becomes
220 the property of the recipient and CAN be redistributed
220 publicly to ANYONE without consent or notice. This notice supercedes
220 any legal claim appended to the body of emails delivered here.

-higB

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 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

I just got back from The Credit Union Information Security Professionals Association 3rd annual National event in Austin Texas where Rohyt and I were talking to the folks about www.PhishMe.com.
I have never attended a CUISPA event before and welcomed the opportunity. It was refreshing to see this industry work together. Credit unions don’t have the budgets larger institutions do and many of their technologists wear multiple hats. Security is a group effort. (as it should be)

Two major takeaways I had from the conference:

1.) Credit Union security professionals have a can-do attitude and value networking with their peers to solve their security woes
2.) Don’t show up to a Credit Union event dressed in New York-Financial attire (unless you enjoy looking like that creepy sales guy)

On the heels of the CUISPA event is a good white paper I saw on BankInfoSecurity.com titled The State of Information Security 2008 – Survey Executive Overview (Free signup)

Tom Field (Editorial Director) did a good job putting the overview together. The top security issues I heard the Credit Union folks discuss are the same ones captured in this survey. (It’s good to see that this paralleled what I saw in person at CUISPA … too often these days a whitepaper is just a synonym for marketing fluff.)

Of course the #3 issue “3) Training – Employees, Customers Need More.” grabs our attention as our http://www.phishme.com/ moves from beta and inches towards launch.
I’m beyond excited.
-higB

p.s. If you happen to attend my ShmooCon 2008 presentation please be kind with the Shmooballs.

I always knew I loved SSH keys. Often, my love was for the convenience factor and that warm feeling you get from authenticating with 1024 bits of encryption goodness. But tonight I’m marveling in the simplistic setup beauty these babies can give any Unix/Linux sysadmin. Most of us have had to play the role at some point of setting up the FNG on the shared linux box. We create the account then email him/her some version of their password and hope they actually login at some point to change it. Any brute force password list worth its weight in electrons has a few versions of the famous “ChangeM3” password. I’ve also been hesitant to ever disable password authentication in my sshd_conf since I thought I’d have to flip it back on anytime there is a new user.

From this ugliness comes my new reason to love SSH keys. Lets change the policy for creating new accounts to require that your noob first sends you an SSH public key (send them off to get PuTTYgen if they don’t already have one). Remember, this is their public key so it’s totally cool to be sent over clear text, or simply posted on the internet. Now as the sysadmin, add their account and drop off their public key in their .ssh/authorized_keys file.

What does this solve? No more login passwords in clear text over email or IM. No more worrying about the FNG changing their password. No more brute force SSH concerns. And for an extra bonus, if I’m the FNG, now I have one less password I need to remember because before, I was setting a unique password on each box. Hey, you never know when your admin might decide to run john the ripper on the shadow file.

When you’re ready to take the plunge and have your own keys in place, the lines you’ll want in your sshd_conf file to require keys and disallow standard login passwords should look something like this:

…snip…
RSAAuthentication yes
PubkeyAuthentication yes
ChallengeResponseAuthentication no
PasswordAuthentication no
UsePAM no
…snip…

-b3nn

1. I would be very busy the week of Christmas, while IT security staff is probably operating at 20% normal strength. Not only is it the weakness in numbers, but also the holiday mood.  How many of you are actually working full days? IDS logs – thats probably the last thing on your mind now that you have Guitar Hero III in the breakroom.
2. I would get busy if I heard that a company was being acquired. From my experience, most companies put a freeze on all discretionary spending from the time a deal is announced untill it closes. Unfortunately, security is often thrown into that discretionary spending budget, making it easy on the bad guys for several months!
3. If I really wanted to spend Christmas with my family, I would just come back another time and phish employees…that works irrespective of season.

Wishing you all a very Happy New Year! Stay safe.

-Rohyt

Here at Intrepidus Group, we do a lot of mobile application security reviews.  Much like standard web application reviews, some clients consistently turn out very secure apps.  However some apps have a detailed finding list longer then a copy of War and Peace.  One trend can often be seen across applications regardless of the client’s understanding of security.  Mobile applications, at some point of their process, typically rely only on a phone number and short numeric pin for authentication to a remote server.

We’ve all know that weak passwords are one of the easiest way on to a system. If you let users have the option of choosing a secure or weak password, they will often take the easier to remember, less secure choice.  I would say most major web based applications now require users to choose passwords with at least 6 characters, using mixed case and at least one number or special character.  Typing in complex passwords with your standard QWERTY keyboard isn’t such a problem, but can you imagine trying to multi-tap some of your complex passwords on a 0-9 keypad? And into a stared out password field? It’s somewhat understandable that most mobile apps only require a numeric pin for authentication.

The problem of course is that most of these server side components can’t be limited to only allowing access from mobile devices (break out your old school User-Agent hacks and give some “.mobi” addresses a try). Limiting access to restricted IP address pools usually don’t help either and typically is a nightmare if client is supporting multiple providers. So in almost all cases, you have to assume an attacker can easily script a brute force attack against some part of the authentication (with mobile apps, it’s typically not just the front door login, but also a web service burried somewhere in the site that will handle authentication).

What’s a mobile vendor to do? CAPTCHAs, you say? Some of these are barely readable on a 22″ monitor. Good luck figuring out that text on your 1.5″ Nokia screen.

Account lockouts seem to be a reasonable recommendations at this point. But even with a low number of attempts (lets say 3 just for fun), I bet I could script something to get into at least 25% of your user base. What are these magic pin numbers?

1234, 5555, 1111

Yup, that’s some 13373 H@x0r shiznit right there. And if I have more login attempts, lets try the last four digits of the mobile number as the pin. Oh, that mega-hurtz now!!! For the sake of security, we need something stronger than an all numeric pin. Maybe it’s in the form of one time token over SMS, or maybe just a decent password multi-tap box for now (I saw this well done on the Blackberry Pearl recently). If you know of any other good solutions to this issue, drop us a line. I’ll be talking about this and more mobile security issues next week at the NJ/NY OWASP meeting.

-b3nn

If you’ve been noticing a little silence on the blog recently, it’s been because a lot of the ranting has been going into developing what we think is a great anti-phishing user awareness tool. Take a peek at our main site at www.PhishMe.com

Conducting ethical phishing attacks has never been easier. User awareness will be improved, enforced, and for the first time for many users, easy to measure and trend over time. You can sign up for the mailing list right now that will let you know when the full blown service is launched. We will be offering free trial accounts that will allow you to get a taste of the features and test out if a few of your users will bite.

Another key feature of PhishMe is the built in templates to make your job of crafting phishing attacks simple yet effective and modern. How do you think your employees would respond to a message about a “virus outbreak”. Will they just follow the instruction in an email without verifying any of the information? What about a message to update their HealthCare information on a new third party site? The number of people that fall victim to these types of attacks will make you wonder why hackers even bother with anything that isn’t social engineering.

There is more to come in the future but for now, check out www.PhishMe.com

-b3nn