in RedTeam

Herding Vyatta – Automating The Hack With A Blade

Intro

Recently I was involved with a Red Team / Blue Team exercise with 10 commercial and college teams. The exercise was pretty standard: public msf-able vulnerabilities, default credentials, and poor domain security to start. Each network used NAT with a core router port forwarding only certain services and there was a juicy soft domain inside ready for the picking. In these exercises, the first 5-10 hours is always easy but as the teams start to dig in on their networks, patch machines, and shutdown services, the fun really begins. I have found a key strategy: Get in quick, get as much as you can, and then pick one system that you believe will be your main box to hop from. This system, this focus point of your work, must be defended. If you can hold one access, usually you can laterally move at some point and deploy capabilities to downgrade systems or even better, force a revert of the system (www.youtube.com/watch?v=e6ozwhdn3go).

The hard part of these exercises: mass command and control of owned systems against a highly active “Incident Response” team. My 10 person red team was faced with access to 100s of systems. Things like Armitage/Cobalt Strike and Asynchronous C2 have made this part so much easier for windows targets but what happens when you want to mass control the routers?

Vyatta

Vyatta is a virtualized routing platform that used to be free to download and use. It provides many of the functionalities of expensive routers/firewalls including a custom shell with its own commands. It is frequently used in exercises due to the ease of use. On the back end, Vyatta is actually just a Linux device with a framework and services stacked on top. It allows ssh, Telnet, web, snmp… So many things to hack! No matter how you gain access (default creds is a favored method in these red team events), the core router becomes a very good pivot platform using socks or ssh tunnels. Bonus points if the blue team is unfamiliar with the device because they might not even realize how to access the Linux backend to find you.

Vyatta’s shell is the vbash shell. When you telnet or ssh in with the “vyatta” user, you are provided that shell. Unfortunately, as the root user you have to do some funny things to get Vyatta commands to run. Luckily, the root user is pretty easy to get most times… if you are the “vyatta” user, getting to a root bash shell is often as simple as “sudo su”.

Post-Ex on Vyatta

After gaining initial shell access via one of the many methods, most of the times you want to get some backdoors in place to secure access (see below). Quickly I move to dumping configs, tunneling through with ssh/socks and monitoring the device. The result of my actions: 10 ssh windows and lots of copy and paste. Another result, someone becomes the “vyatta guy” in charge of all the routers.

Story Time

On our recent red team, Vyatta was essential to our success. During the first night, the white cell shut down the VPN to prevent red team from working off hours… When the network came up in the morning, all 10 members of our remote red team had new DHCP leases and the white cell was not willing to give us static IPs on the VPN :(. Due to this huge failure, the networks of all 10 teams including domain controllers were now running persistent beacons that did not call home to the correct addresses. Our dedicated router guy (with help from the team) threw together a hack and utilized iptables to bend all traffic on the ranges back to the new addresses. It was a giant MITM that allowed us to reestablish access to our tools but was very hand jammed. It was at this point that I knew there had to be a better way!

Keeping access

I treat Vyatta as an access much like any other linux device. The common tricks like SUID shells, init.d scripts, clever custom RATs and backdoor users will usually do the trick… when the team isn’t allowed to revert. Our teams were allowed to revert VMs for a small penalty. After teams caught on to our secret, the focus was on seizing control of the devices. A fight ensued and after tons of reverting and losing the default cred race, we started to lose access. We would get lucky occasionally and catch a fresh device but often times it was random. If only we were quicker to defend across all devices and could have something watching looking for defaults.

Solution #1 – VyCon

After the exercise, I looked into the possibility of controlling the Vyatta systems using Cobalt Strike. When you use sshlogin to a Vyatta device, it provides a standard /bin/sh shell for each of the hosts. There was no vbash shell, autocomplete, or easy way to issue commands in bulk (iptables to all 10 devices). I wanted the ability to control large amounts of routers easily, quickly, and in the same interface I was already using.

Luckily, Cobalt Strike provides the cortana scripting language. This makes it possible to extend the functionality of the tool in a fairly simple manner. There are other resources and con presentations on this topic from harmj0y, Raffi, and many others so I won’t belabor, tldr; cortana is awesome (http://www.slideshare.net/harmj0y/wielding-a-cortana). Over the next week I developed a capability that can be loaded in Cobalt Strike that allows a hacker to manage many Vyattas at once. The cortana tutorial can be found here and is pretty easy to follow. It also contains a complete list of functions and events available to the user: http://www.fastandeasyhacking.com/download/cortana/cortana_tutorial.pdf.

VyCon provides a tab containing a table of all Vyatta routers. Whenever you discover a host is a Vyatta device, you simply right click on the device and “mark as vyatta”. From then on, the device can be commanded on the Vyatta tab. 1, 5, 10, or lots of devices can be highlighted and issued the same command with or without returned output. It also provides some automated things to save time such as adding a public key to the system. You can find it in the cortana repo on Github.

How does it work?

Through some google-foo, I was able to find the “cmd-wrapper” capability that allows for vbash commands to be run on a bash prompt. VyCon simply automates using a shell session and throwing together the huge cmd-wrapper commands needed to issue different commands. For example, to add a user on Vyatta, you would issue this command on the vbash shell:

configure; set system login user hacker authentication plaintext-password hacked; commit; save;

To do this on a bash prompt with command wrapper, you would have to do this command:

sudo /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper begin; sudo /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper set service login user hacker authentication plaintext-password hacked; sudo /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper commit; sudo /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper save;sudo /opt/vyatta/sbin/vyatta-cfg-cmd-wrapper end;

My plugin automates these long commands. You simply highlight the devices, click add user, insert username and password and the proper command is issued across all devices with the shell session.

Current limitations:

  • Must be root user. The session opened in MSF does not seem to like the “vyatta” user doing much of anything including standard vbash. Working on this now!
  • Due to permission changes on the active config (/opt/vyatta/config/active) when root makes a command change,  the “vyatta” user will be locked out of configuration util after a reboot. Some people might consider this a feature?!

Solution #2

If you don’t care about working outside of Cobalt Strike, our router guy spent some time during the exercise and after creating a python based capability. It is really cool! Not only does it allow mass C2, but it provides a feature known as “Overwatch” which will constantly poll devices on a list looking to kill anything that matches our list of “dirty words”. This python based tool also provides a monitor mode for any devices we want constantly checked for default login opportunities. It is in beta and pending release. It will be available on Github when tested.

Conclusion

Thanks to the awesome team I was working with on this exercise. The tools above will be/are freely available. This is likely only going to be useful in exercise red team scenarios as the tool is pretty invasive. Have ideas? Know of a better tool or way to do this? Shoot me a email!

Write a Comment

Comment