If you are like me, then you remember seeing the word “linux” in the hallowed directory listings of ftp.cdrom.com circa 1994 and thinking… hey what’s this new word? A few hours/days later, after borrowing a laptop from the school A/V department, getting comfy trashing the existing operating system fdisk style and loading slackware from a lot of floppy disks, you were greeted by a fully-bootable operating system that measured its speed in BogoMips and could do most of the things the computers in the Sun lab could do  except that you were root (legitimately).

So now we’ve had Linux for a while, its used all over the place and is a system that people seem to have gotten pretty comfortable with.  This level of ease and comfort is now available in the form of “the device you take with you everywhere” …your cellphone is now just a little linux box.  Why is this cool?  Because now I can talk to my friends, and ssh into my server from my cell phone (or vice versa).  Oh yeah, and do all that other stuff that Linux does, like run Apache, FTP, NFS, torrent, or scan your systems with Nessus (theoretically).

The OpenMoko project has already suffered/gained from the normal Linux way of things and there are a few different distributions available.  Developers being the way they are have splintered off from the official OpenMoko distribution and created their own distros already.  One in particular, an “Underground” distro has even gone so far as to scrap X11 for windowing and use the framebuffer directly.  The wheel gets reinvented once again.  Hopefully this time with built-in battery powered spinners.

There are numerous ways this little toy could be used for security testers. Since it has both WiFi and can use the GSM networks (AT&T and T-Mobile work ok in the states), this would make a nice little remote access device.  All you need to do is leave it in the proximity of a location with WiFi then dial in (pppd) from across the world or anywhere cellular data connections can go (if you don’t like the idea of being in physical proximity of your targets or aren’t good at talking to beefy security guards who wonder why your laptop is beeping.) Alternatively, since it has USB, plug into a corporate computer, then dial in from the cellular side and route through newly-befriended corporate system. The possibilities here are numerous. GPS-activated, bluetooth aware, motiondetecting wifi gprs connection machine…

All in all, a cool device.  Stay tuned for fun stuff to do with it.

- theOtherAaron

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

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

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

That’s what you get when you work in this industry. I had it coming I suppose. The EEE PC is just too damn cute. How could anybody forcibly overflow its cute tiny little heap! That’s just cold hearted pwnage.

A series of updates were released for the Asus EEE PC today, pdf reader, messenger, firefox, openoffice, the samba daemon of course, and some other tweaks.

Recognize! My EEE PC is patched like a mug now! Leave my lil’ EEE PC alone!

-higB

What is http://port139online.com:139/ ?

• Port139online.com:139/ IS a website
• Port139online.com:139/ IS a protocol
• Port139online.com:139/ IS a service (a service that tells you if your ISP is providing a tampered, filtered, limited, and incomplete service.)

I started port139online.com:139 to annoy the tech support agents at Cox Communications. I subscribed to their business Internet service because the sales rep told me that absolutely NO port filters existed for business customers. I don’t know if the sales rep lied to me on purpose to meet a quota, or if she just didn’t have all the information.

After several phone calls to Cox support, I finally got them to admit which ports they filtered (both inbound and outbound). They offered to reduce my bill by 45 dollars a month, but they would not remove the filters. I’m now a Verizon Business FIOS customer and couldn’t be happier with my pure, unmolested Internet.

Shortly after my Shmoocon presentation, Comcast went before the FCC. An executive vice president for Comcast lied to the FCC commissioner and the rest of the panel, when he said:

“I’m going to say again, on the record in front of this Commission, Comcast does not block any Web site, application, or Web protocol, including peer to peer services. Period. Doesn’t happen.”

Oh really? Well http://port139online.com:139/ IS a website AND an application AND uses a WEB PROTOCOL… and guess what? Comcast IS blocking it.

Read more about it here:

http://arstechnica.com/news.ars/post/20080225-comcast-and-net-neutrality-advocates-clash-at-fcc-hearing.html

And listen to the MP3 here: http://arstechnica.com/news.media/fcchearing25feb08.mp3

Reference: Comcast does block websites, ports, and protocols: http://taosecurity.blogspot.com/2005/07/what-does-your-isp-block-only-low-cost.html

http://www.dslreports.com/forum/remark,15481407

**** NOTE ****

You can only visit http://port139online.com:139/ from Internet Explorer. Firefox blocks many ports.

We might finally have some decent mobile viruses to worry about.

Why is it that McAfee’s VirusScan Mobile is only Windows Mobile 5 and 6? Simply put, it’s because that platform gives the end-user enough rope to hang themselves. Users can grab a .CAB file of the brick breaker game from only god knows where and install it themselves through Activesync.

Surely tech-savy users don’t just install any hackware from untrusted sources right? If you believe that then you haven’t spent much time on http://www.howardforums.com/ or http://www.mobile-files.com/forum/ where every day, technophiles repackage and swap DLLs and other tasty bits from one carrier’s phone to another. Users don’t care about running untrusted code. To them, it’s just an annoying split second while they click away the nag window so they can dive into Justin Timberlake-screensaver-ring-tone wallpaper bliss.

It goes beyond running untrusted code from untrusted sources. Users will replace entire operating systems through unofficial channels:
Windows Mobile 6 for the XV6700: www.downloadsquad.com

If you step outside of your tech circle for a moment you’ll notice that most of your friends and family (you know, the people that will be watching football over Thanksgiving while you’re fixing their computers) don’t have windows mobile, RIM, or palm phones. If they have a typical Verizon phone then they follow a path like this to get applications:
Developers create and sign BREW code, that code is then tested and certified via Qualcomm’s NSTL site: https://www.nstl.com/brew/ . Ultimately the wireless carrier decides on what application they put in their catalog. (Usually after they test it themselves.)

Some see this path as a way to lock the user into the carrier’s applications. Another way to look at is the carrier is certifying that code for your phone. Given that the wrong code can put your handset into a chronic state of reboot permanently ruining the device I can see why carriers like to keep tabs on what users load on the phone.

The masses are crying about an open iPhone API. I’m sure they’ll get the open API, along with everything else that comes with it.
If you look at any of the press surrounding Android, the mantra is clearly openness and convenience. Openness and convenience; security’s best friend? <borat> NOT! </borat>

-higB

While most companies do spend some time and money on log analysis, a number of web attacks can go completely undetected given common logging architectures and configurations. A very simple example of this would be POST parameters. You can check all the boxes for the IIS logging configuration, but there’s still no way to enable logging of POST parameters without some custom programming. Not logging POST parameters makes sense as they are most often used to send usernames and passwords (something you wouldn’t want sitting as plaintext in your logs); but then any SQl injection attempts to bypass login go undetected. So, some programmers take it upon themselves to add additional logging in the application itself. Items such as writing out when someone logs in, or what data they are viewing or entering. While this is recommended and can often be helpful, it can also lead to a false sense of security. Most often a vulnerability in an application occurs at a point where the developer was unaware of a security risk. Therefore, developers commonly miss logging data at the correct spots, logging the correct parameters, that are used in an attack. In a number of cases, there is often no validation or encoding of data written to these custom logs. Thus it’s rather easy for an attacker to forge entries into the logs or truncate data by appending null characters in their attacks.

Even if you do log everything properly, some attacks don’t have signatures that would stand out. Parameter manipulation attacks often take advantage of subtle changes to the information sent to the webserver.  Changing one account number to another valid account number. Flipping a zero to a one to get admin access. These attacks are going look like normal request to anyone reviewing the logs unless you already know some information about an attack that has occurred.

We have also seen a number of attacks against weak encryption that can go unnoticed for a huge amount of time. This should be painfully obvious now in the wireless world after the TJX attacks. Consider your own wireless network for a moment. Even if you are logging MAC addresses for every connection, how do you know someone is not passively capturing your traffic and decrypting it? Or has sniffed a legitimate user’s MAC address and is impersonating it?

In the web application world, we have seen weak homegrown session “encryption” for persistent logins. This didn’t take millions of sessions ids to crack, but rather just a handful any normal user would be issued. Think you would detect it based on IP addresses in your logs? Fairly unlikely, because your logs probably aren’t saving the session ids. If they are, the number of false positives is so high based on legitimate mobile users, that its often impossible to use that information to realize it’s an attack. Your IPS/IDS often will miss this attack as well since there’s nothing out of the ordinary in the requests or paths through the site.

How about Session Riding attacks? In these cases, we have a legitimately logged in user, coming from their normal IP address and standard web browser. If the attacker has done a proper job, a single Session Riding attack entry in a log file will look exactly like legitimate traffic. You would need to analyze the user’s path through the site to realize something was out of order. Again, in most cases, companies to not have the tools or resources to do this.

So before the next board meeting when someone announces “we’ve never been hacked”, take a few minutes to think about if there’s anyway you could know that is true. In most cases, there should be reasonable doubt to know the jury is out on that myth.

-b3nn

Let’s talk about Cross Site Request Forgeries (XSRF) for starters. Corey Benninger explained the difference between the often confused XSS and XSRF in a previous blog post. The root cause of XSRF is the predicability of key HTTP requests that result in transactions with signifcant impacts.

E.g. If the HTTP request for transfering funds from one account to another is – http://www.hellobank.com/transfer.aspx?amt=1000&srcacct=1001829&srcaba=021000091&dstacct=9008990&dstaba=012000076

an attacker can lure a victim to visiting a web page, that in the “background” executes such a request to transfer funds from the victim’s bank account to that of the attackers. If the victim is logged in to his/her online bank then this transaction will execute successfully. The systemic issue is the predicability of the HTTP request. The way to thwart such an attack is to introduce a random element in every request to transfer funds, and more importantly verify that the random token has not been tampered with.

Now on to session fixation. The potential impact of exploitation of this vulnerability is often underestimated; for those that feel that this is a “Medium” or “Low” risk issue check out my BlackHat 2006 presentation. The fix for this issue is real simple – invalidate and re-issue user sessions after critical events like login, and  switching from non-SSL to SSL on the website. It’s not input validation though.

I started thinking about this post while teaching my class at Carnegie Mellon University. One of the students came up to me after the web hacking class and asked me “What is the ONE thing I should take away from this session”. I said –  ”If it had to be ONE thing for application security it would still be Input Validation, but hopefully you didn’t just learn ONE thing” 

There was an interesting update yesterday about last month’s story about a Swedish security researcher who released the password and login information for 100+ embassy and government workers.

(I’m going to take some liberties summarizing this)

A Swedish researcher released 100+ passwords claiming he wanted to expose that the practice of using pop3, imap, etc shows a lack of user awareness. This also shows a lack of care and regard from the government institutions that permit inbound plain text authentication.

Some called for the lynching of this “hacker” while others were more curious about how the passwords were obtained. My initial off-the-cuff guess was a web exposure or a password list carelessly left online for google to cache.

How the passwords were really obtained proved to be much more interesting. In a blog posting yesterday, Dan Egerstad, revealed that he has been operating TOR exit nodes and sniffing passwords. I’m absolutely not surprised some people think that using TOR magically fixes all clear text protocols. What did surprise me is that government and embassy workers are using TOR. Are these workers really using TOR? It’s true that Tor is effective at masking the origination IP address from the destination address.

I think the REAL story here is that 100+ accounts have been compromised for months (maybe years) and that the real attackers have been using Tor to mask their origin IP address. Without Dan Egerstad exposing this; hackers, spies, (and who knows) could have gone on accessing these government email accounts unobstructed.

-higB