The Dark Side Of DefCon's Wireless Network
An anonymous reader writes "While there's been a few postings on events happening at DefCon 12, one event seems to have been overlooked. A new wireless packet injection tool was quietly released (unleashed?) during DefCon: AirPwn. Here's a write-up of the tool as deployed by its author and crew at DefCon 12."
It's a hacker conference. There is probably no more tolerant place to release such a piece of code, where your talents will be respected instead of persecuted. There were also no doubt many members of the computer security community present who would want to be aware of any new vulnerabilities immediately. I think it's a great thing it was tried and released at DefCon first.
He who laughs last is stuck in a time dilation bubble.
Does this strike anyone else as dumb?
Do people still do this? Packet injections of various and sundry sorts are old news.
;)
There's a worrisome pattern, in the IT security biz, of repetition. Hacks discovered a few years ago re-appear in new clothes as "new," technologies for protecting against them resurface every few years in the same way. Computing as a whole tends to re-invent things on something like a 15 year cycle, but security seems to be on a truly frenetic clock, cycling every 2 years or so (very very approximately
Is there some connection between this and that vulnerabilties re-surface in new clothes constantly as well?
don't use wi-fi for anything that might be even close to important :D
Wireless was pushed along by a need to get it out. READ COMPANY PROFITS. I have attended lectures where this is described on and on. Little to no attention was paid to security. WEP? Yeah good luck. It is fairly easy to exploit any wireless connection. It just wasnt done right.
But this is the best part. Become the middle man.
Joe or any other operator of an access point doesn't need AirPwn, since they obviously have physically access to the upstream Internet connection and could intercept packets more efficiently there and inject ads, etc. What's unique about AirPwn is that it enables easier packet injection by those who don't control/own/operate/admin. the access points, but by almost anyone in the neighborhood (or with a sector antenna pointed in your direction).
1) does SSL prevent this attack from working?
Yes and no. If you do the packet injection after the SSL session is negotiated, yes (since you'll no longer be able to read the HTTP get or post). If you do the packet injection before the SSL session is negotiated (and setup your own SSL session with your own self-signed certificate), no.
Someone correct me if I'm wrong, but I believe the way it works is to hijack the TCP connection. If you can do that, you can take over anything (though obviously authentication schemes will still blow up and complain about wrong authentication).
My question is, is IPV6 immune to this at all?
AccountKiller
I will say that I thought twice about using telnet even with a OTP specifically because of TCP hijacking fears. (Initially I thought it would be funny for someone to see a plaintext password scroll by their sniffer window.)
So really you weren't because this wouldn't have affected you at all.
This type of attack doesn't bother people that don't request images.
Stop karma whoring.
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M
If you can't figure out how it works (and therefore how easily you could be located), you shouldn't be using it, script kiddie.
I mean, get real. You won't get any chicks because of it.
...as we all know, chicks just love haxx0rs...
You're at Joe's internet cafe, or in an airport, etc. Suddenly, your internet explorer gets a web page redirect to some random porno movie of 3 guys raping a rather unattractive asian girl, complete with audio... in full screen mode. Since your laptop's audio is on, everyone in the area, including your girlfriend hear, "No don't put it in my pussy. [scream]"... And you're joe blow who doesn't know how to use the keyboard to close the window to save your life.
Yes, it could happen, particularly, if the geek in the corner is sniffing your WiFi traffic, and singles you out.
More serious would be something which noted when you wanted a secure site, such as a bank, and proxied to a full-screen web page image complete with security icons that tricked the user into sending you their password in the clear.
There are malicious 14 year olds with laptops out there that would find this awfully amusing.
What are they going to do this time, ban WiFi cards? (Perhaps a warning sticker on products: "This is not a phone or a LAN. This is a two-way radio. Wireless means they don't need wires either.")
One line blog. I hear that they're called Twitters now.
No, read that article again. SSH2 provides an additional protection to MITM attacks for users of public key user authentication. In ssh1 only the client having the server host key prevented MITM, the opportunity to make a second check was missed. dnsiff simply provided a new implementation of an known attack, if you use password authentication it will work just as well on ssh2.
If your servers share user directories and allow public key user authentication, you should probably disable ssh1 to force your users' clients to make this second check.
For those that "secure" their dos network, this isn't going to anything unless they write the proper matching regex and haveit reply with a deauth frame. This isn't included as part of the code base, so they have to figure it out.
"Not my manner of thinking but the manner of thinking of others has been the source of my unhappiness." - M