Exciting….
Archive for July, 2009
Leak-testing a firewall with hping3
July 23rd, 2009Someone asked me a question the other day about a product that was used to leak-test firewalls. This product (shall remain nameless) is da bomb; great for enterprises (and priced so). So, given this, what are your options for doing some quick and dirty firewall policy auditing other than spending your life savings or indenturing your children?
Step in – hping3
Hping3 allows me to craft packets with specific TCP flags set, specific source IP addresses, source/destination ports, UDP, ICMP, and others. Read the fine manual for all the options because this tool is extremely flexible.
So let’s say I wanted to test to see if the port for AIM chat was open out to the Internet… in other words. Can inside hosts reach internet-based hosts on TCP/5190?
hping3 –count 1 –baseport 5190 –destport 1025 –syn –spoof 10.16.22.147 172.16.20.103
The 10.16.22.147 is my Internet-based sensor. When the host responds with the reset (I am sending in syn-mode) because the port isn’t open, it will send it back to my internet sensor. If it makes it through the firewall, you know that you have an outbound port open for that particular host (at least). So, if I get back a response from 172.16.20.103 on source-port 1025 and destination-port 5190, then I know I can send traffic from the inside of the network on port 5190 out to the Internet. Of course I can manipulate the source and destination ports as well as the hosts to do this. All of this can be scripted, and again, the responses that show up on your sensor are the things that made it through the firewall.
Apparently the firewall is allowing TCP/5190 outbound since, on my sensor I received the reset:
If the firewall had been blocking outbound AIM, we would have never seen the drop.
A more comprehensive approach might be to run something like this:
hping3 –baseport 0 –destport 1025 –syn –spoof 10.16.22.147 172.16.20.103
What that will do is increment the source port by one for each request. Any requests making it through the firewall should appear on the sensor as a RST to the destination of the IP address of the sensor itself.
More on the breadly firewall…
July 20th, 2009So here’s something that confirms at least some of my suspicions raised in my last post:
Apparently Panera doesn’t want any l337 hAX0Rs reading Darknet.
Breadly Firewall?
July 19th, 2009Sitting at Panera Bread, one of my favorite weekend haunts… the coffee is decent, the food is good, and the wifi is free. Anyhow… after signing in this afternoon, I noticed that Adium wasn’t connecting to any its services.
Now, I run a slightly modded Adium config so I can use IM via a proxy at work. I run all the protocols over HTTP ports (TCP/80 and 443). So, I am not using the default ports defined in the stock IM profiles.
So, I show up here… sign into the Panera Wifi (hosted by WanderingWifi on a Nomadix platform) and voila… no IM!
My AIM profile is configured to use TCP/80 to the host login.oscar.aol.com. So I thought I would go digging to see why I can’t get to it like that while at Panera. First, can I ping it?
OK… so that works. Let’s make sure we’re actually getting the right IP back for our DNS queries.
Uh oh… the IP address changed to 205.188.251.43 (bucp-d1-vip.blue.aol.com). Still no joy tho but that is interesting. I wonder if the other IP address is cached and because I have a RoadRunner cable modem, I get a different server via a DNS view. 64.12.200.89 appears to be a load-balancer VIP from its DNS name (ibucp-vip-m.blue.aol.com). I wonder what the significance of “bucp-d1-vip” versus “ibucp-vip-m” is and why I get a different VIP when at Panera? I will have to check that when I get home, but the point is, I cannot reach the service on TCP/80 from Panera no matter which VIP I think is right.
So… what next. Let’s take a look at what wireshark says.
Ok… 57, 58, 59… standard SYN, SYN/ACK, ACK 3-way handshake sequence… looks good, I have a connection up on TCP/80 so let’s go. No firewall to 205.188.251.43 on port 80 at Panera, right… right???
Frame 60 is me logging in. After frame 60, I am retransmitting the credential packet until I finally give up by sending a FIN, ACK in frame 81, which I have to retransmit in frame 84 because I don’t get the requested ACK.
So… the conversation is allowed to be set up, I send creds to log in with, and then I hear nothing from the far-side. If I switch my Adium config back to use the default port (TCP/5190) it works perfectly. If I leave it at TCP/80, it works perfectly at home or at work. Is AOL blocking logons from anything other than the default port (5190) unless you’re on Time Warner cable (RoadRunner) service? I wonder if that’s because the password is sent in the clear and they’re not comfortable accepting in the clear passwords from non-TW nets. AIM definitely hashes the password when it is signing in using the default port. I wonder if it does the same thing when using non-default ports or does it send it in the clear since it’s not the native transport?
Well, I doubt AOL is doing this… we don’t have Time Warner at work, so is there a list of trusted versus non trusted nets for TCP/80? I doubt that too because what a mess that would be to manage.
Also… I would say “hey, it’s AOL doing this and they have their reasons and their own method to their madness” except for one thing. When I try to connect to Yahoo on port 80, MSN on port 80, and Google-Chat on port 443, all of them exhibit the same behavior and that behavior only exhibits itself when at Panera. So I don’t think it’s AOL or any of the others. I think it’s Panera. The question is; how and why? Here’s a guess (and it’s not a very qualified guess, just a big hunch until I can figure out how to prove it)… Transparent proxy anyone? The Nomadix platforms come with that kind of technology built in (check out their AG-5500 series and the AG-2100 remote-hotspot). The Nomadix is expecting port 5190 traffic to the AOL LB-VIPs and not what it thinks is HTTP traffic. That means a silent dropping of traffic (I didn’t get a filtered response back, I received NO response, once the 3-way was completed). So the connection runs up, gets pushed into the proxy because it’s on TCP/80 or 443 or something it thinks is a web-session, and the proxy doesn’t like it because it’s not behaving like a web-session, and it drops it. So, is it doing it because it’s a chat-destination, or because it’s not acting like a real HTTP conversation? My guess is because of the behavior of the supposed web session that’s really a chat session.
Note back up in the packet-captured displayed above; we have our 3-way handshake followed immediately by an http-continuation message. Hrm… what is a proxy going to think about that… “did I miss something here, where’s the get???”. The first thing a normal HTTP conversation is going to do after the TCP session is set-up is go get something. Here’s an example to cisco.com:
Note the 3-way gets going normally (just like in the previous example) but then the very next packet is an http get. So in the previous example, maybe the Nomadix is thinking “oy, I see a web conversation going on that I ought to know a lot more about… something smells rotten in Denmark and I am dropping it!”.
What does that mean? Your chat protocols are getting proxied? No… they probably aren’t and besides, who cares about that as long as you use OTR? It means that if you’re using Panera to surf, there’s an application-layer proxy and possibly an application-firewall that is, at a minimum, recording everything you do, and if you make purchases, sign into an SSL VPN, or anything else that you expect to be secure, you’d better be very very sure that the certificate presented back to you is actually the certificate you expect and that you’re not terminating your encryption on the Nomadix. Watch for browser certificate errors and popups as well. Make sure the pages you expect to be encrypted really are… be careful!
