Cenzic 232 Patent
Paid Advertising
web application security lab

Archive for the 'Wireless Security' Category

AT&T UTMS JS Injection

Monday, April 12th, 2010

This isn’t exactly an exploit, but I’m sure after reading it, some people will feel like it is, or at minimum it might make people feel uncomfortable. It appears when users connect through AT&T UTMS wireless cards, the system man-in-the-middle’s the connection, and not only does it downgrade the image quality for performance reasons but it also injects a piece of JavaScript located at http://2.2.3.4/bmi-int-js/bmi.js (not live on the Internet). If you’re anything like me and you see a piece of JS installed in your website that you know doesn’t have any JS on it at all, you’re thinking you’re owned at this point. Alas, you probably are owned, but it’s in an effort to save your bandwidth. You can download a zipped copy of this JavaScript file here.

The real questions are when and how this page gets cached, and who owns 2.2.3.4 when it’s not being MITM’d (when you switch from UTMS to another network), and on and on. Incidentally, I tried to do directory transversal and go to http://2.2.3.4/ to see what else might be on that page and it banned me from going there and to the JavaScript file for the rest of the session. Why? Probably to stop guys like me from hacking whatever server that is and MITMing everyone on AT&T’s UTMS network. Clearly reducing the size of the page, is good for them, and is good for some percentage of users who don’t care about the potential issues here. And for the rest of us, we’ll continue to tunnel our traffic so we can avoid AT&T’s MITM craziness.

Update: a few people have sent me a link that this also is happening on other networks as well.

Moto Q9 DoS and Fingerprinting

Saturday, January 12th, 2008

So I got a new smart phone, which has been highly entertaining when I’m stuck in airports, or waiting for meetings or whatever. It’s a Moto-Q9. Boy is it sexy - lots of features, fairly fast. It kinda reminds me of what Windows95 used to be - usable but not fast. It has the new version of Microsoft’s mobile operating system on there with direct push on there (similar to Blackberry which saves battery life, I’m sure, for real time email), a 2mega pixel camera, etc… etc… Fun little toy. So id and I were driving around town and I was messing with my phone as he drove and it suddenly occurred to me, I had never really toyed with the browser. So I start messing around with the settings, and of course turn off JavaScript. But then I realized, I had never tested it with JavaScript turned on. That’s when I went to Mr. T. What did Mr. T do to the Moto Q9 (which is running Opera, by the way)? It crashed it immediately.

So then I start messing around with it, and I narrow it down to one of the things that’s more legacy than anything, the now fixed, MS mhtml bug. Uh oh. Yup, the mhtml bug appears to crash mobile Opera instantly. So back to keeping JS turned off, I guess (I haven’t tested if there is another way to cause the crash using a redirection or an iframe, but it takes a long time to test, so I’ll leave that to another day).

Then I start messing with the other options, like the “Identify as” function. With it turned to “handheld device” the user agent reads, “MOT-Q9/01.04.35R Mozilla/4.0 (compatible; MSIE 6.0; Windows CE; Smartphone; 320×240) Opera 8.65 UP.Link/6.3.1.17.0″. Eesh! It gives my actual device type! So then I turn the setting to “desktop computer” it turns to “Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0″. Okay, fair enough, that appears to be the more secure setting as at least it doesn’t say the revision and model number of the phone.

That is, of course, until you look at the rest of the headers:

HTTP_ACCEPT = application/xhtml+xml, application/vnd.wap.xhtml+xml, text/html, text/vnd.wap.wml, application/vnd.wap.wmlc, */*,text/x-hdml,image/mng,image/x-mng,video/mng,video/x-mng,image/bmp,text/html
HTTP_ACCEPT_CHARSET = iso-8859-1, utf-8, utf-16, *;q=0.1,*
HTTP_ACCEPT_ENCODING = deflate, gzip
HTTP_ACCEPT_LANGUAGE = en
HTTP_CACHE_CONTROL = no-cache
HTTP_USER_AGENT = Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Opera 8.65 [en] UP.Link/6.3.1.17.0
HTTP_VIA = 1.1 alnmagr1fe09WAP2-mbl
HTTP_X_UP_DEVCAP_ACCEPT_LANGUAGE = en
HTTP_X_UP_DEVCAP_CHARSET = utf-8,ISO-8859-1,US-ASCII,UTF-16,GB2312,BIG5
HTTP_X_UP_DEVCAP_ISCOLOR = 1
HTTP_X_UP_DEVCAP_NUMSOFTKEYS = 2
HTTP_X_UP_DEVCAP_SCREENDEPTH = 16
HTTP_X_UP_DEVCAP_SCREENPIXELS = 320,240
HTTP_X_UP_DEVCAP_SMARTDIALING = 1
HTTP_X_UP_SUBNO = ppu_105cb54061e_vmag.mycingular.net
HTTP_X_WAP_PROFILE = “http://uaprof.motorola.com/phoneconfig/q-umts/Profile/mot-q9.rdf

Okay, so now we know my provider how big my screen is, that it’s a mobile device of course (the reference to wap), but more importantly we get the actual profile of the phone in the RDF file with all the settings, so you know exactly what may or may not work against the phone! Geez! Talk about giving up too much info! I hardly consider myself a cell phone hacker (for that you’ll need to talk with the Flexilis guys) but in 5 minutes I found all that - that’s not a good start. Whelp, so much for surfing from my phone!

Google Desktop 0day

Thursday, May 31st, 2007

Well fast on the heels of the Firefox plugin MITM vulnerabilities I’ve been working on some other stuff that I think is interesting and of the same genre. This time I came up with a MITM exploit against Google Desktop that would allow an attacker to trick a user into running any program they have installed and that was indexed by Google Desktop. Nasty. I have a pretty thorough writup and a sample video (please read the text before you launch the video or it won’t make much sense).

Using something like Airpwn an attacker can sit in a wireless hotspot and wait for someone who has Google desktop installed (since we can detect for that) and run the exploit against them. It could be done as a prank or something malicious. The point being these types of deep integration between the web and client side applications is really dangerous and breaks the security models put in place by the browsers.

Remote Firefox Vulnerabilities

Wednesday, May 30th, 2007

Brian Krebs at the Washington Post had a story about a post by Chris Soghoian who found that you can use a MITM attack to overwrite addons in Firefox. Actually, believe it or not, I was planning on releasing the exact same issue, but alas, that’s what I get for waiting. More than one person heard me say this, and I even sent Jeremiah a power point deck on this exact thing last night, and even mentioned it in passing during my OWASP talk yesterday, so I’m not just blowing smoke, but alas, Chris disclosed it first so he wins, and good for him. Chris did a good job of explaining it in gory detail too. While most addons are put on addons.mozilla.org there are quite a few that are pulled straight from http connections. There’s a great idea - let’s run arbitrary code from untrusted resources!

The offenders range from big companies like Google, Yahoo, and Facebook, to security software like Netcraft’s toolbar and the Phishtank’s toolbar down to little addons like Bugmenot, and Localrodeo. If you use Firefox, it’s time to either uninstall those addons if you are at all concerned about man in the middle attacks over wireless connections. If you use a laptop and have those addons installed you are taking a big risk of complete compromise. Yes, this is nasty. Daniel Veditz said they would have expected people would have known better. This is sort of one of those things that if you don’t warn people at a minimum they won’t know to think twice. Mozilla may “block” all unsecured content. While I don’t think that’s a great idea, at least they could warn people about what they are doing. Good work by Chris - I just wish I had disclosed it first!

MySpace 0-Day Again (Again)

Sunday, December 24th, 2006

I laughed out loud when I read this. Kuza55 found another issue in MySpace again today using the exact same exploit that we have been trying to get them to close FOUR separate times now. Click here to read about the XSS hole last time if you don’t recall what I’m talking about.

Anyway, this is the exact same non-alpha-non-digit issue that they have faced numerous times before. Only this time they got exploited through a different issue they caused for themselves. Remember how I’ve said a number of times don’t strip content unless you really know what you’re doing? Well they don’t really know what they are doing (if you aren’t using a while loop you are already in trouble). In this case, they stripped out moz-binding (the Firefox CSS issue) and replaced it with “..”. Wellll if you make your vector look like onloadmoz-binding= and it gets replaced with “..” you get onload..= which still works in Firefox.

Kuza55 said it best… you really have to wonder what these MySpace developers are thinking right about now. Anyway, this is why you should never ever strip or change HTML input unless you know how HTML works in different browsers, lest you get hit with the same issue 4 times. Nice job Kuza55!

Long Weekend Roundup

Sunday, November 12th, 2006

It was a long weekend and sorry for not posting, but id and I were able to get a lot done this weekend. We got 1 1/2 of the machines up and running out of the three that I had hoped to get running. One machine is having some issues but at least it’s turned on where it was pretty much non-functional as of yesterday. One of my stupid laptops needs to be sold at auction so that I can get another one (that’s the last time I buy a cheap Dell laptop). Anyway, the lab is doing quite a bit better than it was before. Once we get all the software up and running we should see better performance, and less downtime in general.

Speaking of downtime we experienced about 45 minutes of downtime on Saturday morning. A few people posted about it on the forum or emailed us about it so I thought I should mention it. No we weren’t hacked, it was just a runaway process that wasn’t behaving nicely and on top of that it wasn’t giving off any of the obvious signals to help us diagnose the issue. id came to the rescue and we got that one resolved in just a few minutes. From the time I noticed until the time it was back up was only about 15 minutes, cuz he rocks. Hopefully with the new server we’ll notice issues like this faster with some monitoring that I’ve been meaning to build. I’ve built that kind of software before, but those machines and that code is long gone, so I need to do it from scratch.

In web app sec news, we were able to ban in excess of 700 IPs programmatically from attempting to do bad things to the site. The firewall is being updated in somewhat-real-time of things I find particularly annoying. Sort of a self defending network (not to get myself sued). It’s not that they have any hope of getting in, but I hate seeing that crap in my logs. It’s an ongoing process so the site should experience less load from the morons and as a result you might see a small increase in page load time until our traffic load grows again to compensate for any good we may have done to reduce it.

Lastly, id found a rather annoying and very reproducible bug in my Netgear WGT624 wireless router, which caused it to stop routing packets every time he did it. I’ve seen it do this sort of thing in the past but could never consistently reproduce it. I’d tell you how to do it, but it wouldn’t help you because we could only reproduce it over SSH (requiring his keys and the exact server in question to be communicating with one another), and we didn’t have enough time to dump the packets and see what was causing it. Needless to say there definitely is some sort of error on those wireless routers and maybe the next time he’s over we’ll try to figure out exactly what it is. Until then I’ll just put up with it crashing on me every once in a while - as annoying as I find that.

So anyway, it was a productive weekend even if I don’t have a lot to say about it. Hopefully in the next few days or so after we get the bugs ironed out of the servers I can get back to the testing.

SSL Can Hurt Security

Tuesday, July 11th, 2006

SSL can actually harm web application security auditing and intrusion detection.  In fact, SSL can actually make it next to impossible for you to do forensics in the aftermath of a successful penetration, or brute force.

Once upon a time, man in the middle (MITM) attacks were rampant on the net, or so security experts would have loved for you to think.  Then public key cryptography (PKI) and digial certificates in the form of x509 website certificates came along.  The world rejoiced and there was much merry.  But what happened to those MITM attacks?  Have they gone out of existance?  Hardly!  Much to the glee of every blackhat out there, more and more people are tunnelling what should be secured information over insecure protocols (how many times have you recieved your recovery password over mail for instance)?

But let’s take a step back for a second.  SSL was once upon a time a great idea.  Most of the hosting community was comprised of small mom and pop ISPs with little more than a T1 into their offices.  At that time, your peer was probably just as small and insecure as you.  And besides that, the net was a very small place, made of only a few thousand websites.  Along came PKI and the sudden boom of the net taking the few of us who were already online at that time, by storm.

Now the net looks very different, being seperated by huge nodes of private companies who take network security very seriously - and besides, network security is so 2 years ago (okay, I know I’m going to get shot over that one).  No, but seriously, these major ISPs have got their act together a lot more than the mom and pop’s of yesteryear.  Sure, you can still ARP-spoof a switch, or exploit a router here and there, but in large part you are far more secure using the net then you were a few years ago.  But why?  Well, think about how many hops it takes to you to get from your house to the bank of your choice.

Unless you are in some ultra rural location with very dodgy connections to the web via modem, you are probably on a high speed DSL, connected directly to your provider.  That company has peering aggreements with major telcos.  Those telcos have aggreements with other telcos, and those telcos host your bank.  Where exactly would a bad guy have to be to steal your information?  Well these days, it’s really no different than it was 10 years ago.  It’s still your first hop that’s the least secure.  Me connecting through my wireless connection at home is far more likely to get my information stolen by a MITM than me connecting through the next 6 hops.

Okay, so back to SSL.  Where is it useful?  The first hop, sure.  But it’s also helpful for the bank, right?  They know your information is safe, so they are less likely to pay out, if your information gets stolen, right?  Well, sure, but are they going to be able to capture that information?  That’s only vaguely useful to the consumer since MITM attacks are far less used than they used to (which may have had something to do with SSL - I admit).  Let’s take another example.

What if I am joe-small-website with a mechant account, and a I sell snowboards through my site?  I may have an IDS sitting out in front of my website, but that’s probably all I can afford.  Now, I’ve got SSL sitting on 443 and port 80 serving the normal site traffic.  Once the user goes to check-out, they are off the radar for my IDS.

So what if I’m a bad guy?  Well in that case, that’s even better.  I can now evade some security by actually using a security mechanism to do so.  Unless they have an SSL accelerator in front of an IDS, I’ll walk right through their security.  Ultimately, they are now more vulnerable because of their SSL than they were before without it, while only providing a small amount of protection to their users in doing so.

That said, do I use SSL?  Of course!  You’d be an idiot not to.  Duh!

Laptops aren’t firewalls

Friday, June 23rd, 2006

As if you needed another reason to visit Blackhat this summer, two researchers just found a way to hack into wireless cards remotely and take over laptops. David Maynor and Jon Ellch will demonstrate it in August, at the convention.

This is really the problem with how companies treat laptops.  People are given laptops to be more mobile, which is great, but they are protected by the systems that no one in thier right mind would put on an unprotected network.  Then they are allowed to go out into the world and log into whatever network they choose.  Obviously this is a perfect time for viruses, trojans, keystroke loggers and malware of all variety to infect the machines.

The problem is peoople treat laptops like corporate firewalls.  If there is an access to entry, the bad guys will take it.  It’s really not that hard either.  Keeping a system dormant or sending out one packet once in a while until you find it omitting packets from an interesting network, is pretty trivial.  Treating corporate laptops as the front line security, but then not adding additional protection on top of them seems like asking for disaster to strike.

Of course, the wireless protocols that exist today are all prone to insane problems.  If you read the article on the six dumbest ways to secure a wireless LAN you know that there are a half dozen obvious problems with configuration, and probably an equal amount of tricks to get access, like spoofing access points, attacking the access point directly, cracking WEP, etc…  And that’s without even doing anything to the laptop itself.  Now, you add on the ability to hack the basic fundamental peice of hardware that can secure the transmission of data to your network, and you have a clear path to gaining access to that network.

Of course there’s more to it - there are way more protocols than just 802.11b that are at risk here. People have AIM/YIM/IRC sessions, email, NNTP, HTTP, and god knows what else.  All of which are viable transport mechanisms for malicious users to gain access to the laptop, which sits well behind the DMZ.

I had lunch with the CSO of a big bank at one point and he said the best advice he ever got to securing a large scale network was from a guy at Gartner who told him to “not let the local admin rights genie out of the bottle.”  I think that’s the right first step, but taking it further, allowing the user to have any access to the network beyond what is “safe” and secured seems like a bad idea.  Not to mention that 70% of successful hacks attempts are from employees anyway.

So anyway, go to Blackhat, and listen to Jeremiah Grossman’s talk as well as David Maynor and Jon Ellch’s talk if you get a chance.  I bet it’ll be interesting.