Monthly Archives: November 2017

Uploading files to RDP when that is restricted

The short version:

  • A tool which works in Kali Linux which will “upload” a file to an RDP session.
  • Most of the time RDP allows one of “drag and drop”, “copy and paste”, or “mounting of your local hard drive”. So 99% of the time you do not need to do this at all!
  • When all other options are unavailable to you then you can always simply type the contents of any file you want. Then use built in tools on the target’s side to decode and then execute your uploaded file.

Get the tool here:

https://github.com/cornerpirate/rdpupload

With an example usage embedded below:

Details

This is a very old technique. All I have done is have a stab at making my own tool for doing this. I meet aspiring hackers who say they want to jump into coding, but don’t have any “ideas”. They seem unimpressed when I say write a port scanner.

If that is you then I say to you: re-invent the damn wheel!

Sometimes the wheel needs upgrading you know? Many of the tools we have now as the “goto” for something are about 17th in newness of technique. Any tool can be toppled by a better successor.

But world domination is not the goal. Implementing your own versions of old ideas is actually just for getting your skills in for the day you invent an entirely new wheel. It also teaches you how a thing works which is brilliant. At a job interview you will stand out if you actually know what the top tool does under the hood.

What I learned on this one

To make rdpupload I have learned:

  • argparse better (I have used this before)
  • how to simulate key presses in python
  • how to do a progress bar in a CLI
  • how to zip a file using python
  • how to play an mp3 in python

But most importantly I learned how a file upload may work by typing it, along with how to decode that on the server side easily.

Technique Used

The following summarises the techniques used:

Kali Side:

  1. Zip the file you want to upload (might save some characters depending on the file).
  2. Base64 encode that file (so every character we are going to use is available on a standard English Keyboard).
  3. Split the encoded file into chunks of size 256 characters (arbitrary length choice here).
  4. Spoof a keyboard typing each block of 256 characters until it is completed.
  5. Display a progress bar and optionally play the sound of a typewriter hammering away while the “upload” happens.

Victim Side:

  1. Place the cursor into “Notepad” within an RDP session.
  2. When the “upload” is complete save that as a “.txt” file.
  3. Open a command prompt and use “certutil.exe” to decode the base64 encoded file. The syntax for that is shown below.
  4. Use the zip feature of Windows to unpack the zip file.
  5. Profit.

The decoder on the server side relies on “certutil.exe”. Unless I am wrong this is available from Server 2003 upwards so is pretty useful for most use cases.


Syntax: certutil -decode <inputfile> <outputfile>

Example: certutil -decode nc.txt nc.zip

The decode command is also spat out on the Kali side for convenience once the upload is complete.

Using Eclipse + PyDev as an IDE for Python in Kali

I have been making more and more Python scripts in the last 4 years. I have always had sub-optimal environments for doing so. With no interest in a debate on the best text editor. What I really wanted was an IDE. One that I can understand is ideal. As it happened I have some experience of Eclipse and tonight I found “PyDev”.

PyDev is free, easy to install, and gives me code auto-completion which I have rarely had in my Pythonic adventures to date. I love me code auto-completion. I have had it in various editors. However, I trash my Kali VMs with such regularity that I’d rather have something with an easier install than things to backup.

I am installing into a fresh install of Kali 2017.1 here. Anything else and you may have a different experience.

Prerequisites

All we need is eclipse and java 8. Install them as shown below:


apt-get install eclipse

apt-get install openjdk-8-jdk

When I did this Kali installed eclipse 3.8.1. This is not the latest. The newest PyDev works for later versions of eclipse. We need to install from the PyDev 4.X release stream. If you use the wrong release stream then PyDev will not show up in the GUI after installation.

Installing PyDev

Goto “Help” -> “Install New Software”

This will show you a screen where you can add a repository as shown:

add-repo

Do the things in the number order above. To save you precious typing the Location is:

https://dl.bintray.com/fabioz/pydev/4.5.5/

You now have to select your install as shown:

select-install

Follow the numbered steps again. Then click “Next” on the subsequent screen with the title “Install”.

At this point you will get the security warning prompts. This is because the package is self-signed:

accept-risky-thing

It is risky. There is no doubt here that taking something with an insecure certificate is a risk. When I followed the official guide I got the same error but that was using a repository over plain-text HTTP. Neither of those cases is really up to snuff when it comes to security.

But this is an opensource project which is being made free of charge for the love of the community. So is the entire stack you are sitting on!

I rolled my risk o-meter and said my VM isn’t having customer data in it.

After the installation is complete Eclipse will restart. Then you can check that the installation worked by going to: “Window” -> “Preferences” -> PyDev.

If you have that PyDev menu there then you are all setup. Congratulations and now enjoy your Python Dev with code completion and everything you would want.

Debugging

If you do not see the PyDev option under “Window” -> “Preferences”, then:

  1. You didn’t install java 8; or
  2. You didn’t install from the 4.X release stream of PyDev if you are using Eclipse 3.8.X

Or  you have a new problem I did not encounter during this setup.

 

Using Python and Scapy to hunt for VLAN IDs

A customer asked me to check for Cisco Discovery Protocol (CDP) based VLAN hopping on their LAN. It had been reported the year before and, while they hoped that it had been addressed, they wanted me to confirm that it had.

When pentesting it can often be the case that you are basically verifying the solutions to problems that some hacker from another company got to run riot with before.

Far from a burden, it gave me a chance to brush up a little bit. It got me to play with scapy a bit and so this post is basically so I can save my python code in-case I need it again, while sharing it in case it helps someone.

The easy tool for this has been Frogger for several years. It will conduct packet sniffing on an interface looking for CDP packets. Snarffle the VLAN IDs and some other information and then ask you exactly how you want to own a network.

I ran frogger and shock! No VLAN data and no CDP packets to play with. I optimistically increased the packet capture to 3 minutes and tried again. Nope…

Well I guess last years team had much more fun than me.

False Negatives

A thing to remember about Frogger is that if you are trying to run it inside a virtual machine then you might actually be getting false negatives here. Where a false negative is the absence of the vulnerability despite you doing almost the right thing to check for it.

The Readme.md for Frogger says this:

Notes for VMware. VLAN hopping generally (not just this script) can have issues within VMware if running the VM within Windows with certain Intel drivers. The Intel drivers strip off the tags before it reaches the VM. Either use an external USB ethernet card such as a DLink USB 2.0 DUB-E100 (old model 10/100 not gigabit) or boot into Backtrack nativiely from a USB stick. Intel has published a registry fix, to work on some models: http://www.intel.com/support/network/sb/CS-005897.htm – adding “MonitorMode” 1 to the registry does resolve the issue.”

I am paranoid about false negatives so I always run around with a USB Ethernet Device. I did use this for my run of frogger and so I was pretty much certain it was not a false negative.

Checking for the VLAN IDs

Earlier in the engagement I had captured around 2 hours worth of network traffic into a pcap file. This was done from my host OS and not from within my Kali VM. This would therefore have no doubt about capturing all the layer-2 juiciness. Since it was already sitting around why not use python to parse the pcap file and tell me any VLAN ID’s it contained?

You could use a wireshark filter (and I show you the expression at the end of this post). But I am doing things pythony more an more so lets get to scapy.

Enter the VLAN ID hunting script:

from scapy.all import *
from scapy.utils import *
import sys

if len(sys.argv)!=2:
   print sys.argv[0] + " <pcap_file>"
   sys.exit(-1)

# If we get here we have a file
pcapfile = sys.argv[1]

# Loop through the file and check each packet
pkts=rdpcap(pcapfile)
for pkt in pkts:
   if pkt.haslayer(Dot1Q):
      print "VLAN ID: " + str(pkt[Dot1Q].vlan)

For full disclosure the above is heavily based on a stack overflow answer here:

https://stackoverflow.com/questions/8489960/how-to-extract-ethernet-level-data-from-pcap-file

All I did was give it a usage and command line argument for re-usability.

I ran this against my 2 hours worth of packets and found not a single VLAN ID. So absolutely on that day, on that part of the network, there was no evidence of last years vulnerability. Well done to the customer they fixed a thing!

I beg the audiences indulgence for a sidebar

There is an episode of Red Dwarf where Dave Lister gets sick with a radioactively mutated virus. He meets characters that represent both his confidence, and his paranoia. Right about now I was listening to my inner US game show host (representing my confidence). I was thinking: job done CornerPirate. Job done.

Then my paranoia spoke up. You haven’t tried the above script against a PCAP where you knew there was a VLAN id. What if it didn’t work?

Generating a PCAP with VLAN IDs

So lets make a pcap file which has some VLAN IDs in there. Back to python and scapy:

from scapy.all import *
from scapy.utils import *
import sys

def usage():
   print "\nUsage:"
   print "\t" + sys.argv[0] + " <vlan id>"
   sys.exit(-1)
if len(sys.argv)!=2:
   usage()

if sys.argv[1].isdigit() == False:
   print "Specified VLAN ID is not a number"
   usage()
# If we get here we have a vlan id to inject
vlanid = int(sys.argv[1])

# Craft a packet and send it
sendp(Ether(dst='ff:ff:ff:ff:ff:ff', src='11:22:33:44:55:66')/Dot1Q(vlan=vlanid)/IP(dst='255.255.255.255', src='192.168.0.1')/ICMP())

I ran the above with a few different numbers while using Wireshark to capture the packets. Visually I could now see there were definitely VLAN ID’s to be had as shown below:

vlan-id

Finding the VLAN ID using Wireshark Expression

The expression used was “vlan.id” which means “show packets which have a VLAN ID”. My 2 hours worth of packets resulted in zero packets for the same filter. My confidence was now building.

Rerunning my “check-vlan.py” script now showed the same results as Wireshark:

check-vlan

Listing out VLAN

So there you have it. I now know my script does what it intended to.