Threat analysis: Fast-Flux Service Networks

Ever wonder how phishing and malware sites manage to stay online? Through their analysis of botnets and infected hosts, the HoneyNet Project has documented an increasingly widespread technique used by online criminals: "Fast-Flux Service Networks". It's an admittedly clever and approach that makes it much harder to shut down malicious operations.

The premise behind fast-flux service networks is simple: attackers register a fully qualified domain name, and then rotate hundreds or thousands of IP addresses that are assigned to it. A DNS name may only be mapped to a particular IP for a few minutes. Each IP is an infected member of a botnet - but they are not the source of content, such as a virus or a scam web-site. Instead, they simply act as proxies, redirecting to one or more "mothership" servers that actually host the content. A more complex variation, "double-flux" service networks, implement additional misdirection by also rotating the authoritative name servers.

Like most of the HoneyNet Project's work, the whitepaper is very well-written and includes a case study with real-world examples. Definitely worth checking out if you're interested in how the more sinister side of the Internet underground operates.

Stating the obvious - VNC is insecure

If you need to provide remote desktop access to your organization's Windows machines, and care even a little bit about IT security, do NOT use VNC. The Windows built-in Remote Assistance / Remote Desktop tools are a far better choice. This may seem obvious, but I still find organizations running VNC servers all over the place, usually for the helpdesk to provide users with remote troubleshooting. This can leave an environment ripe for compromise.

VNC has a few fundamental weaknesses:

• Most implementations do not require a username for authentication, and the password is stored in the registry using a trivial hashing mechanism. VNCcrack or Cain will instantly crack these hashes.
• There is typically no client-side confirmation or acknowledgment required for a VNC session to be established between a server and viewer, which can leave a user unaware that their activity is being monitored.
• Most significantly, because there's no simple way to centrally manage VNC servers, administrators will typically use the same VNC password for every host to facilitate configuration and deployment. So if you compromise one Windows box through local vulnerabilities and gain access to its registry, you can obtain a VNC password that will work on every other machine in the environment. Not good.

For a pen-tester's perspective, let's throw a few other variables into the mix. Several Windows tools will scan a set of systems via NetBIOS and tell you which users are logged on to each. And if the domain controllers are configured to allow certain anonymous NetBIOS queries, you can enumerate all the members of key groups like "Domain Administrators". Analyze your scan results and combine the data to produce a list of workstations used by privileged domain accounts. VNC into each system and look for an opportunity to take control of the keyboard and mouse. (Yet another reason to lock your desktop when away from the keyboard!)

It takes less than 15 seconds to open the command shell, execute your "net user /add /domain", and close the window. Bam - you now have a domain account. Not exactly an elegant attack, but it gets the job done.

VNC is an excellent tool that can serve a number of purposes in both home and enterprise environments. However, it is not an ideal solution for remote access across a large number of Windows hosts. It often takes a good penetration test to drive that point home.

Reverse tunneling with Zebedee to compromise trusted networks

During a recent external pen-test, my teammate and I were able to gain root access to a Unix web server through a few serious application vulnerabilities. Once we had a reverse-shell going, we used wget to download Nmap, compiled it, and set off some scans to map out the DMZ and any reachable internal servers. Pretty straightforward so far.

Turned out that there really was no DMZ - everything was in one cloud behind their perimeter firewall. We quickly found a Class C containing lots of Windows hosts, including domain controllers and database servers, with all the expected ports open and exposed - jackpot! But we had a problem: the majority of our pen-testing tools for attacking Windows hosts only run on Windows, especially those related to MS SQL server. We couldn't run them on our compromised Unix server, and we didn't have the time to hunt down and test any equivalent tools that might exist for *nix platforms.

What we needed was a way to securely tunnel a connection from our pen-test system, through the Internet to the compromised Unix web server, and then ultimately to the Windows hosts behind the firewall. Something like stunnel first came to mind, but their firewall would block our inbound connection attempt.

Enter Zebedee...

This wonderful tool, available for both *nix and Windows, lets you set up an encrypted two-way tunnel for TCP or UDP connections. But the real beauty is that you can initialize a "reverse tunnel", much in the same way you'd use netcat to set up a reverse shell and bypass firewalls that strictly filter inbound connections. We configured our pen-test system to be the client and listen for connections from the Zebedee server. We then installed and ran Zebedee's server component on the compromised Unix host, and set up an outgoing reverse tunnel to our listener. The outbound connection got through their firewall, and we were able to directly attack the internal Windows servers from our own machine. You just point your testing tools to localhost as the destination IP, and to the port on which Zebedee client has established the tunnel. (As you might imagine, explaining how this worked to non-technical folks at our client was rather difficult).

Needless to say we were extremely happy to get this working, especially because it took quite a long time to configure and set up properly. Some of the documentation was confusing, and we kept having silly compilation issues because dependencies were in the wrong path. One noteworthy problem we ran into is that we could only get the server to tunnel to one endpoint at a time. In other words, our client listener could stay open, but we had to re-initialize the server with a different tunneling endpoint specified on the command line each time we wanted to test a new Windows host.

Ultimately, that limitation wasn't a huge deal - we still were able to eventually compromise a key Windows server - it just took some extra time to do the testing. The documentation indicates that you can set up a tunnel to any number of endpoints, so we'll have to figure that out for our next pen-test.

Despite these minor quibbles, Zebedee is a great tool that is invaluable for external pen-tests, particularly when your system compromises have spilled over into protected networks.