Advanced Traceroute: Firewalk

The module for class this week describes using IP packet time to live, TTL, values to map out a route across the network that you are sending data to reach your destination. Modern operating systems come default with tools do perform this sort of diagnostic, with Windows utilizing ICMP Echo Request packets while UNIX and Linux using high port UDP. (UMUC, 2012)

Sending a packet with a TTL of one to have the first hop in the route respond with an ICMP error of type 11, Time Exceeded, and code 0, time to live exceeded in transit. (Postel, 1981) Next, send successively higher TTL values until the destination responds. By recording the sender information from the ICMP error messages, you make a list of nodes where the sender for TTL N is N hops away. As long as network gateways allow in your tracer packets and allow out the ICMP errors, that is.

Firewall devices may drop tracer packets because they only allow specific traffic services through. An advanced traceroute technique accounts for this and uses the firewall distance plus one TTL to map the allowed services on that firewall, a technique known as firewalking. (Irby, 2000) It works because the traceroute operates at the IP level and therefore leaves the encapsulated protocol up for spoofing. TCP, UDP, ICMP or any transport layer protocol can be tested. If a Windows traceroute times out at a hop but a UDP port 53, DNS, gets responded to then that device is dropping ICMP Echo Requests but allows DNS traffic. (Irby, 2000)

---

Irby, D. (2000). Firewalk: Can Attackers See Through Your Firewall. SANS

Postel, J. (1981). RFC 792: Internet control message protocol. InterNet Network Working Group.

UMUC. (2012) Advanced TCP/IP, CSEC-640 – Module 1. Retrieved from: https://leoprdws.umuc.edu/CSEC640/1206/csec640_01/assets/csec640_01.pdf

TCP Discussion

A vital aspect of TCP which is conveniently abstracted away from normal use is the TCP window size. Because endpoints of various levels of speed, capability, and memory operate across networks, reliability can only be achieved efficiently if endpoints have “a means for the receiver to govern the amount of data sent by the sender”, as is described in RFC 793 (Postel, 2003). Windows are the size of buffers maintained by network TCP stacks and fill with incoming data and empty as that data is consumed by the networking application.

TCP Flow control lessons learned from programming network tools:
If you are watching a TCP session, such as in Wireshark, and the TCP window suddenly starts shrinking then it means that the endpoint has stopped calling recv. This is a likely sign that the receiving application is blocking on the thread processing inbound data, and probably blocking inappropriately. Check for waits or even premature thread termination. This problem will occur also if the inbound data thread has exited without triggering a closure of the socket.

Man, I hate it when comedians tell jokes about TCP. They just keep repeating it until you laugh! This is because, as a protocol, TCP guarantees reliability through Positive Acknowledgement with Retransmission. (Vacca, 2009, pg 298) Data packets are retransmitted until they are acknowledged.

---

---

Postel, J. (2003). RFC 793: Transmission control protocol, September 1981.Status: Standard, 88.

UMUC. (2012) Advanced TCP/IP, CSEC-640 – Module 1. Retrieved from: https://leoprdws.umuc.edu/CSEC640/1206/csec640_01/assets/csec640_01.pdf

Vacca, J. R. (2009). Computer and Information Security Handbook. Burlington, MA: Morgan Kaufman

Why bug bounties?

"Rule #1 of bug bounties: No matter how much money you're offering, assume that someone evil found the bug first and didn't report it" - Colin Percival of tarsnap

This! This is why locating and fixing possibly exploitable bugs is so important and why bug bounties help.

If a black hat finds an exploit then they will make money. So there is a direct monetary reward for black hats finding vulnerabilities. Bugs = $.

If a developer ships software then they will make money. There is no money in creating perfect vaporware, only in completed software.
Shipped software = $.
Shipped software has bugs. Therefore your developers will be just as likely to innocently introduce bugs as prevent exploits. Not a good line of defense.

A fixed set of QA engineers will only ever find the bugs that they find. And they are on salary.
Time = $.
They will not find the bugs that are outside of the processes and skills of that fixed team.

So at this point, only one of our three groups have a direct financial reward for finding exploitable bugs in shipped software... and they won't be telling you about it. They have had a reason to be pounding on your software to the very best of their abilities and a reason to succeed. Their livelihood is dependent on being the first to that bug. So they probably were. How many 0 days were exposed by Stuxnet? Hacking Team?

Those that benefit most could have spent the most resources on finding the bugs. So you have to assume that they already did.

Tips and tricks: Debugging on Android

I searched all over for this information and want to save it for the future.

Situation: Code running on an android emulator, hosted on a Windows 8 box. GDB is available in an Ubuntu emulator running in VMware on the same Windows 8 box.

Goal: To connect the GDB in Ubuntu to a gdbserver on the android device.

1. Forward 127.0.0.1:PORT to the android device (here PORT is 5039)...      adb forward tcp:5039 tcp:5039
2. Open a shell to the android device... adb shell
3. Begin debugging the process on the device [gdbserver :PORT --attach PID]... gdbserver :5039 --attach 1574
4. adb forward Only forwarded 127.0.0.1, which the VM can't get to. Use netsh to forward the public IP to the localhost port...  netsh interface portproxy add v4tov4 listenport=5039 listenaddress=192.168.1.2 connectport=5039 connectaddress=127.0.0.1
5. In Ubuntu, open gdb and connect to the server... target remote 192.168.1.2:5039

Bam! The Windows box forwards the connection from the VM to the device and gdb meets gdbserver.

This isn't enough, as my gdb is rejecting the connection with "warning: Architecture rejected target-supplied description", but it is a big step forward. For the next step you need an appropriately built gdb which matches the ABI (application binary interface) of the targeted device.

Acquiring an ARM-Linux tool chain for targetting Android:
Download and run the android-ndk from https://developer.android.com/tools/sdk/ndk/index.html

Once the files are present, use the instructions at https://github.com/mapbox/mapbox-gl-native/wiki/Android-debugging-with-remote-GDB to open the correct gdb

Letter to Congress: TPA 'Fast Track'

Here is a letter that I have drafted to send to my Congressional Representative concerning the currently debated Trade Promotion Authority. Please copy it and send it to your Congressional Representative.

Find your rep: http://house.gov/representatives/

Read the Constitution Article 2 section 2

--------------
<REPRESENTATIVE>,

I strongly urge you to do everything in your power to prevent the passage of the Senate's trade promotion authority bill.

As advertised, the bill is a clear violation of Article II, section II of the Constitution. Without both the ability to approve AND comment, then the Senate is unable to perform their Constitutional duties with regard to treaties.

Again, as a resident of the <DISTRICT> Congressional District of <STATE>, I encourage you to fully oppose this de facto Amendment by legislation. It is not within the power of the Congress to pass, and so it must not be.

Thank you,
<FULL NAME>
<ADDRESS>

New project - Windows crypto wrapper for python

The Win32 Crypto API is a pain to work with, as evidenced by how often OpenSSL is used instead of the operating system's built-in functions. Hard to use in C turns into absolutely impossible to interact with in Python, so I have been working to fix that.

Introducing WinCrypt.py! The result will be a clean, object-based pythonic wrapper to use the Win32 Crypto API.

Anyway, I was speaking with a guy today about certificates, SSL, and their contents. Convienient since this code was just written up yesterday...

Of course I was only able to mentally walk back structure a few rows at the time, and sort of directed the conversation onto a tangent about the NotAfter usage.

How many bits of entropy will stop a targeted attack?

Over at security.stackexchange there is currently the following question:

The OpenPGP (private) key format stores the key symmetrically encrypted ... key expansion takes about a second on my computer (GPG).
With this kind of setup, is it possible to make it hard enough to brute-force that it's sane to have the private-key publicly available?
I expect the answer depends on the passphrase complexity. E.g. if you somehow managed to have a passphrase with 256 bits of entropy, then an attacker would be better off just guessing the derived key instead of the passphrase - which in this case amounts to brute-forcing an AES key (which I'd consider hard enough to be "safe"). So the question might really be "how complex does your passphrase have to be to make this safe?".

Source Question at security.stackexchange.com

I touched on this thought in my comment over there, but would like to muse on the question a bit more.

His is talking about having his encrypted private key publicly exposed, most likely in a way that it is associated back to one of his accounts. Unless he plans on never actually using the key pair, there will be exploitable benefits to someone malicious to have the private key. Forge messages, open messages sent to him, possibly open messages sent from him. Also, just the thrill of winning may drive folks to attempt this challenge.

Folks, don't issue challenges like this. Remember Todd Davis, the LifeLock CEO that put his Social Security Number in the ads because of how confident he was in his product? He has been identified as an identity thief victim 13 times. And that is with his entire companies' mission and reputation on the line (a reputation that the federal government viewed as $12 million dollars tarnished!). Don't do it!

Once the challenge is issued, it isn't just a question of can the password be cracked. It now becomes a question of can he be hacked. Well crafted, personalized malicious emails (spear phishing) being sent to him, possibly even coming from his compromised friends. When you are a target, anyone connected to you may become a target. As a target, a large amount of personal information can typically be gathered including address, phone number, family members and more. Unfortunately this activity, doxxing, is fairly common as a type of online harassment. Challenged enough what can someone do with all this information?

Not a *likely* outcome. Source: XKCD

If a hacker gains control of your computer, they can place software to harvest your sensitive data: passwords, pseudonyms, possibly financial information.

Please, don't intentionally make yourself a target. (Says the guy that ran for Congress in 2014)