Posts Tagged ‘scapy’

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
    #read server rdp data and check if ssl
    temp = serversock.recv(19)
    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 ./ 
waiting for connection...
('...connected from:', ('', 1044))
waiting for connection...
Intercepting rdp session from
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:

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:

#   –
#   –
#   –

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: “”. 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:

[*] = 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).


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.