Reverse proxy to a NAT'ed machines

Problem:

I am running some webapps that I need to demonstrate to other people without giving them my home IP address.

My setup:

I have a virtual machine running the webapps, behind NAT at home.

Requirements:

• I do not want to send my IP address to people I’m demonstrating the application to.
• I do not want to open a port then do port forwarding.

Solutions:

The three solutions I thought of are Reverse SSH tunneling, VPN, and tor hidden services.

I love tor hidden services and I do use it but I will not be covering that in this blog post. I do not want the people I’m demoing the project to go download Tor. I also don’t want to set up Tor socks proxy for them.

Reverse SSH solution:

CLIENT is behind a NAT with a webapp running on port 8000. SERVER (SSH server & reverse proxy server) has a public IP address that client can SSH into.

You can read more information about reverse SSH tunneling here: http://www.thegeekstuff.com/2013/11/reverse-ssh-tunnel and https://www.howtoforge.com/reverse-ssh-tunneling

Tools: Just an SSH server and a client.

Setup:

CLIENT:

ssh -R 8001:localhost:8000 user@SERVER

8001 is the port that’s opened on the SERVER

8000 is the port open on CLIENT, running a webapp

SERVER:

Server can now access localhost:8001 in order to access webapp on CLIENT, running on port 8000.

Note: You can also do the following:

ssh -R 8001:10.0.0.1:80 user@SERVER

In this case, when SERVER visits localhost:8001, the SERVER is able to access webapp running on 10.0.0.1:80 on the CLIENT network.

Diagram:

VPN solution:

In this solution, SERVER is an OpenVPN server and is running reverse proxy. CLIENT has a webapp running on port 8000.

In this case, the CLIENT will VPN into the SERVER. Reverse proxy running on the server will be able to access any ports open on the CLIENT.

Read more about VPN here: https://openvpn.net/index.php/open-source/documentation/howto.html and https://www.digitalocean.com/community/tutorials/how-to-set-up-an-openvpn-server-on-ubuntu-16-04

Tools:

OpenVPN 2.4 and OpenVPN-install script

Setup:

On CLIENT and SERVER, add OpenVPN repositories as described here: https://community.openvpn.net/openvpn/wiki/OpenvpnSoftwareRepos#UsingOpenVPNaptrepositories

I was using Ubuntu 14.04, so I ran the following commands on my SERVER and CLIENT:

sudo -s

wget -O - https://swupdate.openvpn.net/repos/repo-public.gpg|apt-key add -

echo "deb http://build.openvpn.net/debian/openvpn/release/2.4 trusty main" > /etc/apt/sources.list.d/openvpn-aptrepo.list

To install OpenVPN run the following commands:

apt-get update && apt-get install openvpn

We will now have openvpn on CLIENT and SERVER.

On the server, we will be using OpenVPN-install script from here: https://github.com/Angristan/OpenVPN-install

Simply following the steps here: https://github.com/Angristan/OpenVPN-install#usage

I ran the following on the server:

wget https://raw.githubusercontent.com/Angristan/OpenVPN-install/master/openvpn-install.sh

chmod +x openvpn-install.sh

./openvpn-install.sh

Please select whatever options meet your requirements.

At the end, you’ll have a client.ovpn file in ~/.

Transfer the file to your CLIENT machine.

I do not want CLIENT traffic to leave through SERVER. I did that by changing the OpenVPN server configuration file.

You will need to edit /etc/openvpn/server.conf

Comment out the following lines by adding # at the start of the line:

push "dhcp-option DNS X.X.X.X”

push "dhcp-option DNS X.X.X.X”

push "redirect-gateway def1 bypass-dhcp"

It should look like these afterwards:

#push "dhcp-option DNS X.X.X.X"

#push "dhcp-option DNS X.X.X.X"

#push "redirect-gateway def1 bypass-dhcp"

Run the following commands on the SERVER to make sure openVPN server is up and running:

service openvpn restart

service openvpn status

We need to change an iptables rule to allow traffic from SERVER to CLIENT.

If you run ‘iptables -t nat -L’, you’ll see the following:

SNAT       all  --  10.8.0.0/24          anywhere             to:YOUR_SERVER_IP

We will drop that rule. Dropping this rule will also disable CLIENT traffic to go through SERVER.

We can drop the rule with the following command:

iptables -t nat -D POSTROUTING -s 10.8.0.0/24 -j SNAT --to-source YOUR_SERVER_IP

You will also need to remove iptables command from /etc/rc.local afterwards.

Now, when CLIENT is VPN’ed into SERVER, it will use its own gateway for internet traffic instead of VPN server. SERVER will also be able to access any open ports on CLIENT.

On the client:

As root, run ‘openvpn --config client.ovpn’ to connect to SERVER. You can now set up the reverse proxy to allow SERVER to access CLIENT webapp.

Diagram:

Reverse Proxy:

You can learn more about setting up reverse proxy here: https://www.nginx.com/resources/admin-guide/reverse-proxy/

https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html

http://docs.mitmproxy.org/en/stable/features/reverseproxy.html

(Just like the post here: http://boredhackerblog.blogspot.com/2016/12/setting-up-etherpad-with-basic-auth.html This post is for documenting solutions to my problems. Hope it helps out. Shout out to MSPaint. )

Passed OSCP exam

I have known about Offensive Security for a while. My first certificate was Offensive Security Wireless Professional (OSWP) (https://www.offensive-security.com/information-security-certifications/oswp-offensive-security-wireless-professional/). I got this when I was in high school (2010). I used to hang around on Freenode IRC and OSWP was recommended to me. I was familiar with Linux and I had used Backtrack so I thought I might as well get the cert. Also, I had to have a senior project presentation so I ended up talking about security and me getting OSWP cert.

I recently passed Offensive Security Certified Professional (OSCP) (https://www.offensive-security.com/information-security-certifications/oscp-offensive-security-certified-professional/) exam. This course was fun and challenging. There is a lot of focus on information gathering, enumeration, and post-exploitation. Also, you are taught to not rely on one tool too much. For example, in the exam, you can only use Metasploit on one of the targets. In course, you also learn to modify and fix existing exploits, this comes in handy during the exam.

When you register for OSCP, you receive your training materials and lab access information. Training material is for you to learn things and lab is where you can try things out. When I started doing the labs, I took the easy way out and used Metasploit a lot. Although, I did go back and do some of the labs again without using Metasploit.

If you plan to sign up for this, make sure you can dedicate time to it.
Know the basics of networking, Linux, and Linux command line.
Be strong. Some of the machines in the lab will make you cry.
Take good notes and document everything!
If you can, see if anyone on /r/netsecstudents is doing OSCP and maybe work with them. I was working alone and sometimes I lost motivation to do the labs. Maybe having a partner will keep you in line and motivated.
Read the reviews and tips posted by other blogs. I've provided links at the bottom. Other posts provide you with more information this post.

Prepare your tools and scripts before you start the exam. I recommend starting exam early in the morning. I took it twice. First time, I started at 5PM and started to get tired at around 11PM. Second time, I woke up at 4AM and started the exam.

I was able to do this thanks to BSidesIndy (http://www.bsidesindy.com/) and Offensive Security. I won the training as a prize at BSidesIndy.

If you are thinking about focusing on pentesting, I highly recommend OSCP. I would love to do OSCE (https://www.offensive-security.com/information-security-certifications/osce-offensive-security-certified-expert/) too when I get more time to dedicate to it.

Better blog posts:
https://itgeekchronicles.co.uk/2012/11/01/oscp-the-lab-report/

http://www.jasonbernier.com/oscp-review/

http://blog.knapsy.com/blog/2015/03/29/oscp-thoughts-and-tips/

https://www.wasserman.me/blog/2015/10/12/how-i-learned-to-love-enumeration-and-passed-the-oscp/

Setting up etherpad with basic auth

Problem: I need to use Etherpad but I don't want everyone on the internet to have access.

Download Etherpad: https://www.turnkeylinux.org/etherpad

After installation, you’ll need to edit nginx nodejs configuration file.

It’s located at /etc/nginx/sites-enabled/nodejs

Add the highlighted lines to your config file.

Follow “Create the Password File Using the OpenSSL Utilities” section to create your htpasswd file.

https://www.digitalocean.com/community/tutorials/how-to-set-up-password-authentication-with-nginx-on-ubuntu-14-04

Restart nginx after creating htpasswd file.

Port 443 is port forwarded from WAN to NAT. Port 80 can be disabled if needed.

(This post is for documentation purposes since I was trying to solve my problem. if it helps you out, good)

Setting up a pentesting lab for school

Introduction

I needed a pentesting lab for students. In this post, I’ll discuss several designs and pros and cons of those designs. In the next post, I’ll cover how to do the actual setup for one of the designs.

This isn’t just for pentesting. I’m sure with some modification, you can apply this to DFIR and networking related labs.

Students are taking security classes remotely/online and on-campus. If the students are on campus, they have access to lab machines. Remote students are responsible for their own set up. We can divide the lab designs into remote and local.

These are our options for local:

• Each lab machine has a pentesting environment.
• Students share target machines but run attacker VM on the lab machines

These are the options for remote:

• All the students SSH into one machine and share targets or have their own targets
• Students VNC into attacker VM and share targets or have their own targets
• Students VPN into pentest network and share targets or have their own targets

Local

1.)

Currently, we’re using a setup where each lab machine has two or more VM’s. This generally works fine.

Pros:

• No one point of failure.
• If VM’s aren’t working correctly on one workstation, the student just moves to another one.
• Easy to troubleshoot
• Generally works

Cons:

• Limited resources
• We run out of RAM quickly. The VM’s can be slow at times too.
• Less targets
• We can’t really run more than two VM’s at the same time. This limits simulation of real business environment.
• There is no pivoting since only one target VM is running.

2.)

We’ve also tried another option where we ran target VM’s on a Proxmox server connected to the lab network. This allows students to run one attacker VM then attack multiple targets on the lab network. This was very easy to setup.

Pros:

• Generally works
• Multiple different targets
• Easy to manage and troubleshoot

Cons:

• Single point of failure.
• If Proxmox machine goes down (it hasn’t happened before) they can’t do their assignments
• We did an exercise where students were learning to use nmap and OpenVAS. They also were provided a range to scan and the targets were set up on Proxmox. It slowed down the scanning since everyone was hitting the targets at the same time. (The design wasn’t very thought out by me so I didn’t see this issue coming)
• Limited resources
• Depending on how you set this up, you may have limited resources.
• For example, if you have multiple virtualization hosts, you should be fine. If you’re just relying on one, you will have to share targets.
• Issues with sharing targets
• You will have to set up scheduled reboots for the target VM’s. If a service crashes for a target VM, rest of the students won’t be able to do their assignment.

Remote

Problem with having a local pentest lab is that students have to be there during class time to do their assignment. Slow students have to either stay after or come in on some other day to do their assignment. Also, the teacher takes us much of the time lecturing. We thought it would be best to set up a remote lab for everyone. Some students may want to either hack or do their assignment at 3 AM in the morning. Obviously, they can’t be at school so remote lab was discussed.

3.)

I did SANS NetWars: Core Continuous (https://www.sans.org/netwars/continuous) few months ago. Their lab required you to SSH into a server and do your attacks through that. Of course, you had to utilize SSH tunneling as well for some of the attacks. I am pretty sure the targets were shared too.

Pros:

• Easy for students who are familiar with command line tools
• Requires low amount of resources
• One powerful machine with SSH should be fine
• Targets are shared.
• Easy to manage and troubleshoot
• Adding new tools and removing and adding users is easy.

Cons:

• Not for the students who are still struggling with command line
• Sharing targets
• You have to setup scheduled reboots for the target VM’s.
• You have to focus on keeping the shared SSH server secure.
• You don’t want students to pwn the machine they’re sharing with other students.
• Although, you can give them extra credit if they are able to do that. They probably deserve it.
• Single point of failure
• If SSH server goes down, your students can do hacking or assignment.

4.)

VNC access is another way you can do a pentesting lab. In this design, the students VNC into their VM. They can conduct whatever attacks from the VM. Also, the VM does not run a VNC server. The VNC server is on the host machine. QEMU/KVM allows you to do this.

Pros:

• Isolated
• Depending on how you set this up.
• Easy to manage and troubleshoot
• Depending on how your scripts are written, this should easy to manage and troubleshoot.
• You can run VM’s so any changes that are made are not saved to disk.
• You can also utilize linked QCOW images to make it easier to manage changes
• Multiple targets
• You can assign VM’s to each student and have multiple shared targets
• High customizability
• You can customize VM’s before you let students access them
• Low resource usage (not exactly)
• If you’re using QEMU/KVM, you can enable KSM (https://en.wikipedia.org/wiki/Kernel_same-page_merging)
• With QEMU/KVM, you can use one qcow image and deploy multiple VM’s

Cons:

• Resource intensive
• You’re running VM’s for each student
• Depending on the amount of VM’s and students, you will use high bandwidth, RAM, and CPU
• No copy and paste
• Students won’t be able to copy and paste stuff.
• Sharing targets
• Again, depending on the setup, you might end up sharing targets.
• You will also need to reboot the targets because they’ll probably crash at some point
• Single point of failure
• If the server goes down, you pretty much lose everything (if you’re running in a mode where no changes are saved to disk)
• If the network goes down or slows down because of VNC traffic, it causes issues for all of the students

5.)

VPN connection is another way to set up a lab. This is what Offensive Security uses. Students have their own VM’s but they can VPN into the pentesting lab and attack the machines. I had this set up with ESXi. When students VPN into the lab, they cannot access internet through the VPN. They’re limited to communicating whatever IP range they’re assigned.

Pros:

• Easy to manage and troubleshoot
• Adding and removing users should be easy
• Multiple different targets
• Low resource usage
• You don’t have to host attacker VM’s.
• Isolated
• Somewhat. Depends on how the network rules are set up.
• Customization
• Students can customize their machines. They can also download whatever new tools they need.

Cons:

• Single point of failure
• VPN server or ESXi goes down and your students can do anything.
• Sharing targets
• You’ll probably have to share targets between students.
• You’ll probably need to reboot the targets. They’ll probably crash at some point

Of course, pros and cons will change a bit depending on exactly how you set things up and what resources you have. For example, If you have bunch of high-end servers, you probably won’t be concerned with RAM and CPU usage.

In the next post, I’ll discuss how I set up pentesting lab with VPN. After that, I’ll discuss setting up lab with VNC.

If you have ideas or corrections. Leave them in the comments. This post obviously doesn’t mention all of the designs that you can have.

(The diagrams are terrible. I know.)

IoT/embedded device remote management apps and more Grandstream stuff

Since the last post was research from 2015, I didn't include the new things I learned.

Grandstream and some other embedded devices or IoT devices come with client or management applications. These applications directly communicate with the device to do things like, assign IP address or get model information, and etc.

Traffic from these applications can be useful to look at.

Here's an application to search for Grandstream camera on your network:




It sends out UDP probes and waits for the camera to respond with information.

Also notice that it lets me change the camera IP address and Wifi Configuration. The camera model I have (GXV3611IR_HD) doesn't have a Wifi module.

I know that IP modification is done via UDP and I don't care too much about that right now. I am interested in the wifi config feature.

I was running Wireshark to capture the data and I clicked Scan.



Red part is what the management application is sending to the camera. Blue is the reply.

Notice the basic auth. It's admin/admin. I know that isn't the correct combination because I changed it.
Another thing you should notice is the user agent. It's GSurf/4.0.

When I visit /goform/wireless or /Pages/wifi.html, via my browser, I'm given a login prompt.

But after changing my user-agent to GSurf/4.0, I'm a able to browse the authenticated pages freely.




But sadly, I can't really do much with it.
Below you can see that I tried to add a user and failed.




Anyways, remote management applications or client applications are some of the things you may want to examine if you're already not doing it.