Posts Tagged ‘scapy’

By now everyone has probably heard of Quantum Insert NSA style, if you haven’t then I’d recommend to check out some articles at the end of this post. For those who have been around for a while the technique is not new of course and there have been multiple tools in the past that implemented this type of attack. The tools enabled you to for example fully hijack a telnet connection to insert your own commands, terminate existing connections or just generally mess around with the connection. Most of the tools relied on the fact that they could intercept traffic on the local network and then forge the TCP/IP sequence numbers (long gone are the days that you could just predict them).

So it seems this type of attack, in which knowing the sequences numbers aids in forging a spoofed packet, has been used in two very specific manners:

  • Old Skool on local networks to inject into TCP streams
  • NSA style by globally monitoring connections and injecting packets

There is a third option however that hasn’t been explored yet as far as i know, which is using this technique to bypass IP filters for bi-directional communication. You might wonder when this might come in handy right? After all most of the attackers are used to either directly exfiltrate through HTTPS or in a worst case scenario fall back to good old DNS. These methods however don’t cover some of the more isolated hosts that you sometimes encounter during an assignment.

During a couple of assignments I encountered multiple hosts which were shielded by a network firewall only allowing certain IP addresses to or from the box. The following diagram depicts the situation:

As you can see in the above diagram, for some reason the owner of the box had decided that communication with internet was needed, but only to certain IP addresses. This got me thinking on how I could exfiltrate information. The easiest way was of course to exfiltrate the information in the same way that I had obtained access to the box, which was through SSH and password reuse. I didn’t identify any other methods of exfiltration during the assignment. This was of course not the most ideal way out, since it required passing the information through multiple infected hops in the network which could attract some attention from the people in charge of defending the network.

A more elegant way in my opinion would have been to directly exfiltrate from the machine itself and avoid having a continuous connection to the machine from within the network. In this post we are going to explore the solution I found for this challenge, which is to repurpose the well known quantum insert technique to attempt and build a bi-directional communication channel with spoofed IP addresses to be able to exfiltrate from these type of isolated hosts. If you are thinking ‘this only works if IP filtering or anti address spoofing is not enforced’ then you are right. So besides the on going DDOS attacks, this is yet another reason to block outgoing spoofed packets.

If you are already familiar with IP spoofing, forging packets and quantum insert you can also skip the rest of this post and jump directly to QIBA – A quantum insert backdoor POC. Please be aware that I only tested this in a lab setup, no guarantees on real world usage :)

Lastly as you are probably used to by now, the code illustrates the concept and proofs it works, but it’s nowhere near ready for production usage.

(more…)

Quick POC to mitm RDP ssl

Posted: April 21, 2014 in general, security
Tags: , , ,

So the other day I stumbled upon this great article from Portcullis Labs. The article explains how you can man-in-the-middle an RDP SSL connection. This can be helpful in obtaining the user’s password, like Portcullis explains in their article. As far as I could tell they didn’t release their tool, so I decided to see if I could whip up a quick POC script with a twist of saving the entire decrypted stream to a pcap file. This would put you in the position to maybe retrieve more sensitive data then just the password. Turns out the only modification from regular SSL intercepting code is more or less the following:

    #read client rdp data
    serversock.sendall(clientsock.recv(19))
    #read server rdp data and check if ssl
    temp = serversock.recv(19)
    clientsock.sendall(temp)
    if(temp[15] == '\x01'):

Like you can see we just pass through the initial packet and then just check the response packet for the ‘SSL’ byte before we start intercepting. The output is pretty boring, since everything is saved to the file ‘output.pcap’:

sudo ./rdps2rdp_pcap.py 
waiting for connection...
('...connected from:', ('10.50.0.123', 1044))
waiting for connection...
Intercepting rdp session from 10.50.0.123
some error happend
some error happend

You can ignore the errors, that’s just me being lazy for this POC. The output is saved in ‘output.pcap’ which you can then open with wireshark or further process to extract all the key strokes. If you want to play around with the POC you can find it on my github as usual. If you plan on extracting the key strokes make sure you look for the key scan codes and not for the hex representation of the character that the victim typed. In case you are wondering, yes , extracting the key strokes is left as an excersise for the user :)

 

Verifying Nmap scans

Posted: May 7, 2013 in general, security
Tags: , , , ,

So the other day while talking with Slurpgeit the following issue came up:

During a scan nmap reported 1000 ports filtered for the host, but wireshark told us otherwise a RST was received for a few ports but with a delay of ~18 seconds

Hmm that’s interesting, so that means that if wireshark hadn’t been monitored during the scan, the closed ports would have been missed or even worse what if open ports had been missed? The RTT to the host however were within normal ranges, also a simple ping worked fine without any delay whatsoever. Which brings us to an ancient saying about hacking:

Never trust your tools completely, always verify your results! Then verify them again and finally check that they are correct.

Since this is (assumed) something that doesn’t occur that often, you most probably want to automate the verification step. Unless you love looking at scrolling packets in your wireshark window. We can do it actively (real time sniffing) or passively (pcap) after the scans are done. I choose to implement the latter, the passive and after-the-facts verification. Reason being that all you most probably want is to check if something has gone wrong, if not just continue hacking your target. So let’s setup a lab environment to reproduce this issue and then let’s write a script for it using scapy.

I chose to just create two virtual machines within the same subnet, one being the attacker and one being the victim. To delay the traffic on the victim side I used netem since I didn’t manage to do it with iptables. I delayed one port with the following lines I found on the interwebs:

sudo tc qdisc add dev eth0 root handle 1: prio
sudo tc qdisc add dev eth0 parent 1:1 handle 2: netem delay 5s
sudo tc filter add dev eth0 parent 1: protocol ip prio 1 u32 match ip sport 22 0xffff flowid 1:1

This will effectively delay all outgoing packets from port 22 with 5 seconds, which is more then enough to make nmap think it’s a filtered port. Fun fact: while playing with netem, if you apply the delay to all packets then nmap won’t even begin to scan the host, since according to it’s arp scan the host is down. Let’s fire up nmap and take a look at the output:
(more…)

This is just some quick script I hacked up to scan TCP ports using different source ports. The aim of the script is to find badly configured firewalls that allow traffic from certain source ports. This is for instance explained in the NMAP book. I’ve done it in scapy (yeah I know python ones again) and still admire scapy, it’s a wonderful piece of software. Here are some nice references if you decide to write your own networking stuff in scapy:

#   – http://www.secdev.org/projects/scapy/doc/usage.html
#   – http://www.secdev.org/conf/scapy_pacsec05.pdf
#   – https://cs.uwindsor.ca/~rfortier/CRIPT/uploads/slides/Python_Scapy.pdf

You can find the source here.

I chose manual output analysis, this means that the script doesn’t have any logic whatsoever and you will have to decide, if it allows or doesn’t allow traffic from different source ports yourself. Example output:

Received 34 packets, got 8 answers, remaining 28 packets
srcport, dstport, flags, humanflags
20,80,18,[‘SYN’, ‘ACK’]
20,443,18,[‘SYN’, ‘ACK’]
53,80,18,[‘SYN’, ‘ACK’]
53,443,18,[‘SYN’, ‘ACK’]
67,80,18,[‘SYN’, ‘ACK’]
67,443,18,[‘SYN’, ‘ACK’]
88,80,18,[‘SYN’, ‘ACK’]
88,443,18,[‘SYN’, ‘ACK’]

Hope it’s also useful for someone out there.

I have been intrigued by nmap’s feature to scan a target using an idle zombie pc which has an incremental ip id. I have also been intrigued by scapy. Finally I have also been intrigued by metasploit. At first I combined nmap and metasploit and the end result was, that I was not able to get the IPIDSEQ module to work. So I turned to scapy and tried porting the metasploit module to python. It was fun and I finally employed python for something besides playing with it to learn.

python src

I’ve also finally learned why it’s nice to prepend your output with “[*]”, since I’ve been lazy with the verbose output I have just used the one from scapy to know if my script should output or shouldn’t output verbose messages. This means that the output gets cluttered. So by prepending “[*]” you can just grep the results to have a clear view of what the script is doing without the scapy stuff in between it.

Finally scapy is a real nice toy. I had to implement 0.0 code to support cidr notation. So when you for example want to scan a /24 range you can just go like: “microsoft.com/24”. isn’t that neat? Hope you enjoy it and find a way to use it. For me it was more fun to write it and learn a lot along the way, then the actual goal I wrote it for. oh btw the non-verbose output looks like:

[*] 74.125.45.100 = Randomized

oh a second btw I recommend putting the timeout/waittime on 5 or something like that.

In short this + python support. I’ve finally decided to build alpha POC code for the idea I already blogged about. Some of you might wonder why I choose to support python, seeing that I previously wrote about it and I hate/loved it. Well because afaik it’s the easiest language to embed inside C. Oh and the reason why I added support for a scripting language is because some things are just so much easier when done in a scripting language. So let’s see the actual code(make sure u read my previous blog post else the next stuff might sound like total gibberish).

(more…)

Python hidden love and hate

Posted: January 1, 2009 in general
Tags: , ,

This is just my little hate/love affair with python. This post will be a bit chaotic but ohwell…

Well when I first read about python my inmediate reaction was: HATE HATE HATE. This reaction was only triggered because of one reason: indentation. This kept going on for a while until I finally decided to try python out and create my opinion based on using the language instead of prejudices. I’ll explain what the word ‘hidden’ does in the title of this blog posting later on.

(more…)