Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
 ·Shaw
| First winner - El Cheapo Router Challenge
qrkx  was the first person to sneak packets past the NAT device and hence is the first winner in this challenge. What I hope to achieve in this thread is a discussion of how he did it, why they got past and what threat this method poses to people who use NAT devices, how this method can be mitigated (or if it can or needs to be) and and lastly any limitations that it has.
I'll let qrkx describe the method and what is needed to make such a method possible and then we can then discuss what the ramifications of this are (and who is buying beer).
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
qrkx
Premium
join:2003-04-26
Montreal, QC
| Well...I'll buy the beer. This way we can get this out of the way...
This exercise was conducted to prove a simple concept: things can go bump in the night...No need to worry or throw that router out the window. Unless it has no logging facilities....:)
One of the most important things in security is visibility. If the securing device offers little to no visibility into what is happening on the "wild" side then we might as well keep guessing.
Next, one should keep in mind that as long as a piece of code parses network traffic - it presents a potential entry point for "evil". Examples of such code is a TCP/IP stack. believe it or not - a closed port can present some security problems.
In our example we mapped the target IP and spoofed predictable dns responses without going into too much detail. The end result is a third party with no help from the inside passing datagrams past the fw device. No big deal. Just an insight into how things work.
The home user does not need to worry about this. Mitigating risk in a soho environment is a contradiction in terms.
rgds. |
|
willendorf
join:2000-12-29
Norwich, CT | reply to Link Logger
Could anything malicious have been done to the system with these packets that got through? Or would it have taken more to actually own the system? |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| reply to qrkx
Mitigating this attack is likely non-trivial. One would probably make more headway taking measures to reduce the chance of the attacker being able to launch the attack itself.
For instance, qrkx was able to determine the dns to use based on the IP itself. The public information available about the target network was a leverage point. Possible solution, don't use the "normal" DNS that the rest of your network is using. Had the target host been using some other random DNS, the specific attack would have been considerably more difficult.
Another possible mitigation method, like I mentioned in the other thread, might be to watch for TTL changes to your DNS servers. qrkx and I discussed this and while I agree with him that spoofing TTL is trivial, it might prove useful to detect the spoofed packets.
--
Captain of the ATU Tux Racer Clan. |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| reply to willendorf
said by willendorf :Could anything malicious have been done to the system with these packets that got through? Or would it have taken more to actually own the system? There have been at least one instance of a single udp packet worm in the past. But more so, this could have been just a jumping off point for additional attacks. For instance, had qrkx known that the host would be asking to resolve a specific domain, he could have spoofed an actual DNS response, directing the victim to an alternate destination. At that point, there's no telling really what it could lead to. Depending on the measures in place by the victim to protect the host itself (A/V, host-based firewall, etc) the alternate destination could trick the victim into all kinds of things.
This could be the case for hosts with or without a SOHO router though.
--
Captain of the ATU Tux Racer Clan. |
|
EGeezer
Go Bobcats
Premium
join:2002-08-04
Country!
 ·Callcentric
·RoadRunner Cable
·AT&T CallVantage
| reply to Link Logger
The neat part about it was that it was one of the BBR security forum members who achieved success in passing the packets.
Hats off to qkrx and linklogger for this piece of work and the even-keeled analysis and report!
--
Every Good Electrical Engineer Zeroes Each Register |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to Link Logger
qrkx method is based upon knowledge of the limitations of network protocols and in this particular case limitations of the UDP protocol, hence could it be used with TCP for example, no (well it could but you would have to spoof the packet perfectly which isn't as easy for a TCP packet). Do we need to go back and retest the Linksys BEFSR41 with this method, no, as it will work, but perhaps a better question would be what sort of firewall would you need to have in place to defend against this method (if its even possible) and how much would it cost. Does this method present a risk to users, depends on a lot of factors, but the short answer would be no (actually you couldn't stop it anyways if your software was vulnerable). If for example I knew you were listening to a audio stream via UDP and that the application listening to the stream had a particular vulnerability for a UDP packet constructed in some special way, then yes I could do whatever the application vulnerability could do. Just spoof the UDP packet (IP/Port/etc) and 'inject' it into the stream (and by inject I mean fire it at your computer so it looks like its part of the expected data stream). The firewall lets it by as it looks legit port and IP wise and your music player is now mine (if that were the exploit). Now the question has always been how does a firewall know that a UDP packet is legit for example an audio stream, what sort of packet inspection can you do? How long do you leave a UDP port open on a firewall for more UDP packets (remember UDP is stateless)?
The problem is our current network protocols are 30 years old and security wasn't considered as just making it work was the only concern. So am I going to lose any sleep over this method, hasn't bothered me before so why would it bother me now as its more just a fact of life then something I can do a lot to prevent from happening.
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
Keizer
I'M Your Huckleberry
Premium,MVM
join:2003-01-20 | reply to Link Logger
Remember, evil doers will also benefit from the info revealed in this thread.
Keizer |
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs: 
| said by Keizer :Remember, evil doers will also benefit from the info revealed in this thread. So are you proposing that we should stop? You do realize that the people who can really hurt your systems already know this stuff, right?
Openness is the answer, my friend -- not secrecy.
--
dmiessler.com -- grep understanding knowledge |
|
Keizer
I'M Your Huckleberry
Premium,MVM
join:2003-01-20
1 edit | said by Daniel :said by Keizer :Remember, evil doers will also benefit from the info revealed in this thread. So are you proposing that we should stop? You do realize that the people who can really hurt your systems already know this stuff, right? Openness is the answer, my friend -- not secrecy. So are you proposing that there is only one level of hacker? One that already knows it all?
I know on the other side of the coin, that in the security end of things, there are people that know it all, and those just starting to learn.
I am not saying to stop the thread, I am all for it. |
|
Kiwi
Premium
join:2003-05-26
USA
·Comcast
 ·Aristotle Internet
1 edit | reply to Link Logger
You guy's forgot the first 'Rule'!
Nothing is 100%, ask someone to challenge an IP; on the basis of a "Router" & you are asking for trouble.
If anyone is dedicated, then nothing you have will protect you, a router for "Joe" @ default settings is protective, send a signal of "Hey, here I am" with an IP address & crack me, is kinda moot!
I believe that "Joe" has protection with today's Routers, so why knock it? Nice thought Link But this proves very little, in fact. Again, anyone interested will get access, a router helps those that help themselves! Meaning a protective Router has advantages. But under certain circumstances, there are those that can defeat a NAT, based Router, for sure; along with any other Pro-Active measure.
Sorry, I missed a lot, had other issues going on.
A router is a good thing, tweaked is better. Is anything truly safe, not @ all. Although there may be checks & balances, any real cracker would make this scheme worthless 
Nice thought, but I don't think the idea measures up to reality. Will I try, probably not  Not much into a challenge, reality, oh, sure!
-I still don't think it's a good idea to turn people off, from a Router solution ~Basic as it may be, there are some great benefits to today's Routers.
A crack? Now anyone on this thread KNOWS that that's an oxymoron @ work, right?
Great idea Link Logger , don't like where this might head....
OoPs, Link, the Link
Cheers
--
2.66g/533fsb Intel CPU @ 3.48g
512meg Twinmos PC3700~466 DDR @ 2.8v -PCpower&Cooling 512. May, 2003*
ATI 9500 Pro @ 9700 Pro @1.6v
AMD ASUS A7N8X-E ~
2500+ @3200 ATI 9500 Pro, Corsair 512LL.
|
|
Daniel
Premium,MVM
join:2000-06-26
Pleasanton, CA
clubs:
| reply to Keizer
said by Keizer :said by Daniel :said by Keizer :Remember, evil doers will also benefit from the info revealed in this thread. So are you proposing that we should stop? You do realize that the people who can really hurt your systems already know this stuff, right? Openness is the answer, my friend -- not secrecy. So are you proposing that there is only one level of hacker? One that already knows it all? What I said was that dangerous crackers already know how to do what grkx did (and most everything else we're likely to come up with here) -- that's all.
In other words, it's not like we're giving away "secret hacking techniques" that nobody knows about. The goal is to educate the good guys; the bad guys are already educated.
--
dmiessler.com -- grep understanding knowledge |
|
Keizer
I'M Your Huckleberry
Premium,MVM
join:2003-01-20
| said by Daniel :said by Keizer :said by Daniel :said by Keizer :Remember, evil doers will also benefit from the info revealed in this thread. So are you proposing that we should stop? You do realize that the people who can really hurt your systems already know this stuff, right? Openness is the answer, my friend -- not secrecy. So are you proposing that there is only one level of hacker? One that already knows it all? What I said was that dangerous crackers already know how to do what grkx did (and most everything else we're likely to come up with here) -- that's all. In other words, it's not like we're giving away "secret hacking techniques" that nobody knows about. The goal is to educate the good guys; the bad guys are already educated. I understand! It's kind of like the war on drugs. The resources available for the good guys fight, pales in comparison to that of the bad guys. |
|
antiserious
The Future ain't what it used to be
Premium
join:2001-12-12
Scranton, PA
1 edit | reply to Link Logger
... nevermind ...
--
... "Do You Know Where Your Towel Is ?" ... |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to Link Logger
First off let me say that I'm still highly highly recommending use of firewalls, NAT Devices, whatever you want to call them. This method doesn't exploit a weakness in the firewall per say, it attacks a weakness in the protocol (ie UDP authentication is almost non-existent and easy to spoof).
I am so very glad that qrkx did this as frankly I was a little concerned that no one else was doing it. There was some talk about it, but no follow through until qrkx, but then again qrkx isn't your average security professional and has always said this sort of attack would work. The purpose of the challenge is to prove the validity of NAT Devices, and this has done nothing to tarnish that, it only defines a limitation of security on the internet based on existing protocols and their inherent weaknesses. There is no firewall available at any price which could stop every flavor of this attack method. This is in itself a huge advantage in knowing about these sorts of issues from both a white hat and black hat perspective. Will IPV6 address these weaknesses, somewhat, but hackers are creative folks so time will tell how secure IPV6 is going to be, when and if we ever make that jump. Security is a funny thing, if you become to dependent on a physical device for example, then common sense seems to end up on the junk pile and you are no better off then before as there is no substitute for common sense.
Now the real question is can anyone find any other vulnerabilities in our El Cheapo Routers, because this really isn't a black mark against them.
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
justin
Australian
join:1999-05-28
Brooklyn, NY
Host:
IPv6
Business Connectiv..
Home/Office setup ..
Console/Handheld g..
Console Tech
| reply to BeesTea
said by BeesTea :Had the target host been using some other random DNS, the specific attack would have been considerably more difficult. Lets go for:
(if the user was using a random DNS server) this specific attack would have been impossible. As in: impossible. If you really think it is possible, defend the statement that it is not impossible by posting how it might be done ..
Sneaking in packets where you have magical knowledge of an existing conversation (in this case: a dns query) to feed the packets in at the right time, is not much of a demonstration of NAT insecurity, neither is it a demonstration of the need for another layer of packet inspection security (that would also be fooled by these attacks).
BTW - if you are suggesting deep packet inspection could be a defense, i disagree - if the bad guy has magical knowledge, they probably also have magical knowledge of TTLs, and can make the spoof undetectable (anyway - all you gotta do is try about six different TTLs, until the packets are accepted).
Even knowing a specific DNS host is in use isn't much use: you need to trick a user into performing a DNS lookup they have not already cached the result of, and you need to know when that user does this, and you need to overwhelm the legit responses, so your bogus info gets through, and THEN you need to rely on some other vector (lurking at the bogus response IP) to actually cause an infection.
Far far FAR easier to send an email that looks plausible and gets the person to click on an attachment, or a link. |
|
Link Logger
Premium,MVM
join:2001-03-29
Calgary, AB
·Shaw
| reply to Link Logger
Lets also understand that these are not just randomly spoofed packets, but spoofed as a reply with matching IPs and Ports to a request which was sent out and the spoofed reply has to come within some time frame as the NAT Device will close the port after some period of time so there are a lot of things which need to happen. qrkx choice of DNS helped as then he knows the port 53 is likely to be the source port of the returned packet, but he also needed to know which port the request was coming from, which I told him over the phone (always happy to help prove an excellent point). Granted he could have flooded responses back using a range of ports which he suspects are going to be used, but I would have seen that in my logs like a HUGE red flag (an example where you logs can tell you about funny things going on).
Blake
--
Vendor: Firewall Logging Software »www.SonicLogger.com - SonicWall and 3Com »www.LinkLogger.com - Linksys, Netgear and Zyxel |
|
BeesTea
Network Janitor
Premium,VIP
join:2003-03-08
00000
| reply to justin
said by justin :Lets go for: (if the user was using a random DNS server) this specific attack would have been impossible. As in: impossible. If you really think it is possible, defend the statement that it is not impossible by posting how it might be done .. "Defend the statement", give me a break. If you use DNS, the chance is greater than 0%. Greater than 0 means it's possible. Impossible is a strong word. Sorry my opinion didn't use language that agreed with yours.
By the way, TTL is in the packet header, there's no need for DPI.
--
Captain of the ATU Tux Racer Clan. |
|
novaflare
The Dragon Was Here
Premium
join:2002-01-24
Barberton, OH
| reply to Daniel
said by Daniel :said by Keizer :Remember, evil doers will also benefit from the info revealed in this thread. So are you proposing that we should stop? You do realize that the people who can really hurt your systems already know this stuff, right? Openness is the answer, my friend -- not secrecy. i aggree why hide it? I mean realy theres 100s of sites out there that list this sort of thing. Likly all were doing is makeing the attacks less useful to the hackers and there for less used. Once a exploit becomes more well known patched or not it gets used less.
--
DSLR security chat at us.ausirc.net chanel #dslr_sec lets pack this channelopen source dns server for *nix and windows »powerdns.com |
|
qrkx
Premium
join:2003-04-26
Montreal, QC
| reply to justin
said by justin :......snip....Sneaking in packets where you have magical knowledge of an existing conversation (in this case: a dns query) to feed the packets in at the right time, is not much of a demonstration of NAT insecurity, neither is it a demonstration of the need for another layer of packet inspection security (that would also be fooled by these attacks)... There is no magical knowledge involved.
Perhaps the focus on forged dns responses is confusing some of our readers...
As you very well know TCP reset attacks(»kerneltrap.org/node/3072) rely on a similar concept: ease of predictability in a flawed protocol. Flawed from a security perspective - might I add.
You can argue the degree of difficulty of such attacks but you cannot possibly dismiss them. As you can see in the tcp reset story - the "magical" knowledge is close to voodoo from your perspective yet the vulnerability exists whether you like to admit its feasibility or not.
Bees' point in using TTL filtering on dns responses is valid since it increases the complexity of this particular example.
rgds.
|
|
