Island Hopping the SpiderLabs Way

More and more, I find myself having to fight with highly segmented networks and ACL’s.  As a pentester, I long for the old days of flat networks. When you only REALLY needed one broadcast domain,

and they made /8’s for a reason.  You fancy kids with your switches and your subnetting; Chopping up your networks into a million segments chock full of ACL’s. You are making me work, and work is hard!

Of course, I kid. Segmentation should be a large part of network design. Its refreshing to see a nicely partitioned network, piled high with an extra helping of ACL's and filtering.

Segmentation was the name of the game with BananaStand, who sells bananas from various outlets. They needed a Penetration Test, and I was happy to oblige. In this particular test, I was after card holder data.  That data lived

in the production network in a far-away datacenter. In-between myself and the goods were no less than 4 different security zones, all VLAN'd up. Each network had access control lists (ACL) to the network before it, requiring me to hop through every security

zone in order to make it to my final destination. The path looks something like this:

Internal Windows Domain > Internal Linux network > Internet (OMG Clouds!) > SSH Jump Boxes > Production network

 I plugged into the Internal Windows LAN and got to work. After some quick scans of the local network, I noticed a juicy-looking, neglected Windows 2000 box:

10.10.3.50:445 is running Windows 2000 Service Pack 0 - 4 (name:PBX01) (domain:BANANASTAND)

Looks like someone forgot to run Windows Update. I loaded up Metasploit and used ms08_067_netapi:

Once that old Win2k system was compromised, I dumped its local password hashes:

The first thing I noticed was that the hashes were stored in LanMan (LM) format. With my LM All-Space Rainbow Tables in hand, I fed in the hashes:

So now we know the local user account is the unchanged 'Administrator' and its password, at least on this system, is 'VeeL@nsRul3'. Then I fired up a password-guessing tool to see where else this account was valid:

With a few clicks, I found that this local administrator account was valid on a ton of other systems. This makes life easier, as I can just pop each system using the local admin account, and then check to see what domain users

are logged in. Eventually, I stumbled across the RECEPTION04 system:

Once I had a session on that system, I fired up Incognito and checked to see what user tokens were available. This showed me any interactive (logged-in users) sessions that I could steal.

Someone from the 'Domain Admins' (and amazingly enough, the 'Enterprise Admins') group was logged into this box. Next, I grabbed his password hash using gsecdump:

Looks like BANANASTAND\backupadmin was our big winner here. Next, I queried a domain controller (DC) for some more information:

Just what I wanted - BANANASTAND\backupadmin was a member of the Domain Admins group. Just like before, I loaded up my LM Rainbow Tables to recover the plaintext password for BANANASTAND\backupadmin:

At this point, I was Domain Admin on the BANANASTAND domain. My next stop was an adjacent network full of Linux machines - the 172 network. I used my admin-level access to the Windows domain to speed things up a bit. Any mixed

Linux / Windows shop will eventually have to use Windows tools to administer Linux systems. Tools such as Putty and WinSCP are common. I found all the BANANASTAND systems that had them installed by dumping the Windows registry uninstall keys via the REG QUERY

command:

Great – I found two systems with WinSCP installed. You can manually check the registry to see if the user is using the 'save credentials' feature of WinSCP by dumping the appropriate keys:

It looks like this user was saving passwords in WinSCP. By default, the way WinSCP stores its password hashes in the registry is very weak. It uses a known string and XOR value to obfuscate the password. Knowing the method, it

possible to obtain the cleartext passwords using a little voodoo. I cheated and just used the Metasploit post module:

Once I had the cleartext passwords for the jbob account, I tried to login to the corresponding systems:

Fantastic, the accounts were still valid. I poked around the system for a bit and noticed that jbob was in the sudoers group:

I ran a quick password test to see what other Linux systems shared jbob’s creds:

So at this point, I’ve managed to root just about everything at this location. I popped the Windows domain, and then I hopped into the adjacent Linux network. From here - I had to find my way across the Internet and into a pair

of SSH jump boxes at BananaStand’s colo environment, and then into the production network behind them. I got back to work. 

With user / sudo access to a ton of Linux machines, I wrote a quick script to run around to each one and grab /etc/shadow and any ~/.ssh/ folders. After pouring over the results, I noticed most of the systems had the same key

in /home/nagios/.ssh/authorized_keys (originating from nagmon01.bananastand.local):

I then went after the nagmon01 system to see if I could use the jbob account to get into it. I couldn’t access the nagmon01 system directly from the Windows network - so I had to hop through another Linux host in the 172 net

first:

Now that I am sourcing from the 172 network, I can hit that nagmon01 box:

Thank goodness for shared credentials! Next, I wanted to see if we had sudo access on this box as well:

Perfect. I've now got root access to the nagios monitoring box in the 172 Linux network. Next, I hopped over to the nagios user so I could use its SSH key (the private SSH key to the public counterpart we found earlier):

When I took a peek at .ssh/known_hosts on nagmon01, I saw over 500 systems listed. This Nagios install was a talker! Spot-checking a few of the hosts listed gave me very limited permissions, and the nagios user wasn’t in the

sudo group. Even if it was, I would need to know the password to this account to use it.  I found a pair of public IP addresses in the known_hosts file; The SSH jump boxes out at the colo. I tried to log in (note the lack of password input - I used the SSH

key for auth here):

So I've made my way onto one of the jump boxes at the colo, but I had super limited privileges. I started poking around in /etc looking for something I could grab - but I couldn’t read /etc/shadow to grab hashes. In a stroke

of hacker luck, I found /etc/shadow.backup set with world-read rights. I grabbed a copy and got to cracking. A couple hours of coffee chugging and GPU abuse later, I managed to recover the following accounts:

nagios:NO PASSWORD

jgrunz:i<3cats2

jaku:beta955

ptj:lilw@yne

zfas:brb.clubING

Backing up one hop, I tried each recovered account against the jumpbox01 system. All the accounts were valid - but the ptj account was the only one with sudo rights. Since we arent using a SSH key anymore, and we know the password to the ptj account, we

can login and sudo to root:

Then I used sudo to hop to root:

Your production is my production

I am now root on one of the SSH jump boxes at the colo net. I have one more hop into the production network.  A peek at /etc/hosts showed me a short list of systems in the production net. Using the same ptj account, I scanned

the prod systems and found that 3 or 4 of them shared the same ptj account credentials. Bad ptj!

Once root on a production target machine, I started to dig for credit card numbers. I stumbled across /mnt/data/outgoing_reconcile. It appeared to be temporary storage for credit card transactions on their way out to the payment

processor.  I took a peek into one of the files and found a bit over 370 lines, each with a name, address, cleartext credit card number and its CVV2 value:

Then I checked to see how many total files were in that folder:

If there’s an average of 370 entries per file, and that folder had 850+ outgoing files, that gives us more than 300,000 potential credit card numbers. Bananas are hot business!

To recap - I had to compromise the following systems in order to arrive here:

The entire Windows domain - so I could find the machines with WinSCP installed.

devbox1.bananastand.local - Located in the Linux network. I used creds found on the Windows network to access it.

nagmon01.bananastand.local - Monitoring system in the Linux network. I got here using jbob's shared credentials.

jumpbox01.bananastand.local - The SSH Jump Box located at the Colo. Monitored by the nagmon01 system via SSH keys. Also the only way to get into the production network.

web02.prod - A production webserver located inside the Colo. Found in excess of 300,000 credit card numbers stored here.

In the end, I had Domain Admin on the BANANASTAND domain, and either root or limited user access to the majority of Linux systems. I used this access to bypass ACL's and hop onto one of the SSH jump boxes at the colo. From the

jump box, I used shared credentials to log onto one of the production web servers and dump customer credit card data.

So there you have it; the story of BananaStand. They had a decent network setup with good segmentation and restrictive security zones. However, poor patching and password policies made it an easy task to hop from one network to the next, defeating ACL's

as we went. At least for hackers, theres always money in the Banana Stand.