The Art of System Profiling
by Thuull
Opportunity Hacking is the process of finding a neat-o new exploit that you somehow manage to get compiled... so you scan the entire Internet looking for any system at random that just happens to have the hole that you know how to get into. Lame.
System Profiling is the act of picking out one system or network and saying to yourself, "I want in that system," then researching the system or network to learn what it does and how the system works.
System Profiling is not about finding a single hole in a system, accessing the system, and considering yourself done.
System Profiling is about learning all there is to know about the system in question... maybe it has holes, maybe not... but a successful system profile does not have to result in owning the system. Hacking is all about learning, right?
This article is for a specific target audience. It is not designed to be interesting for script kiddies. If you are a script kiddie, and are only here to be a part of something bigger than you are, skip this article.
Specifically, this is targeted at system administrators, security professionals, and non-malicious curious people interested in the security of complex, heterogeneous networks.
Target
For the purposes of this article, we are going to assume that your target company, ABCorporation, is the secretive type.
They don't want you playing around on their network. They have firewalls, they have both active and passive anomaly-based IDS systems. (Note: Active IDS systems are those such as ISS RealSecure, which sit on a network and look for known "attack patterns" in real time. Passive IDS systems are those that take information passing through the network and store it in some database, for anomaly detection and/or data correlation at a later time). They have a trained staff of security professionals.
But, of course, this is what interests you about the ABCorporation...
Start your profiling simple. Use the services that they intend to make available to the public to glean whatever information you can.
Website
Surf their website.
Many companies will make available on their websites all kinds of interesting information about the people who work there, their computer systems, their business partnerships, etc., etc., etc. Use this information to your advantage.
They have email addresses on there? Those might give you the username scheme that they use... worth a try. One of my favorites... do they list the names of their sysadmins? Some do. Tell me, how do sysadmins find new jobs these days? They post their resume on the Internet!
Do a couple of web searches on the sysadmin's names. Check out www.monsterjobs.com, www.dice.com, and www.computerjobs.com, as well as a slew of similar sites. See if you can find their resumes online. Maybe someone who works there now is attempting to jump ship... If you do find one of these resumes, you can just about guarantee that you now know what kind of systems your target company is using. Is the guy(s) a Certified NetWare Engineer (CNE)? Bet they use Novell... MCSE? Well, Windows then... you get the idea.
USENET
Any names that you get of employees off of web pages or other means, go out to Deja News and do a search on the names.
You'd be surprised what you may find there. Or simply do a search at Deja News on @ABCorporation. You'll see the posts of everyone with one of those email addresses.
I once found a string that a firewall administrator at my target company had started... guy was having problems with his IPChains firewall and was looking for specific syntax advice.
He had gotten frustrated in the string because he was getting disjointed responses. So he posted his entire list of chains and the exact syntax of every rule in every chain.
WHOIS
There are other sources of info too.
Pull up a terminal. Start doing WHOIS on ABCorporation@arin.net, ABCorporation@whois.ripe.net, ABCorporation@whois.networksolutions.com, ABCorporation@whois.internic.net, you get the point.
You'll find that the different databases list different things about your company.
Most companies will have multiple blocks of IP addresses... some of these blocks will be portions of the network that used to belong to another company, perhaps a company that had been bought out, etc. But we'll get to that in a little bit.
There was a company that I targeted at one time that had seven different Class C address spaces, one of which was subleased from a local ISP. As all of the other blocks were through major Internet carriers, I checked out the Mom and Pop one.
Turns out a disgruntled division in the company, their distributed programming department, had been denied the use of ICQ through the corporate firewalls.
So, they went out to Mom and Pop ISP and got themselves their own ISDN line. But they didn't realize the need to put a firewall on it and the boxes they put on this ISDN line were all dual-NIC Windows NT machines, default install. They also didn't realize that the Mom and Pop ISP had subregistrered the IP block with ARIN, with their company name, so it showed up as one of the block's belonging to that company with a simple: whois ABCorporation@arin.net
Obviously, on the first NIC, tied to a hub which was tied to their ISDN router, were the public, routable IP addresses. Guess what was on the other NIC in those machines? Yup, that's right: 10.x.x.x IP addresses.
For any of you who don't know what I mean - they had these unprotected NT machines tied into their internal corporate network, i.e., on the company's "clean" side of the firewalls, fully accessible via routable IP addresses from the Internet. Basically, corporate security policy gone wrong.
DiG
Another way to find different "blocks" of IP addresses that belong to your target company is by utilizing the company's (or more preferably, their ISP's) domain name servers. Most will gladly hand the information right over to you.
Try this: dig @ABCorporation ns
This DiG command gives you the name servers that service the target domain, in this case ABCorporation.com. With the names of these name servers, you can attempt to conduct DNS zone transfers of your target company. Let's say that the output from this DiG command gives you three DNS servers:
Now, consider the output. You know that your target company has intrusion detection systems. So you want to attempt to gain information about the target company's network without the traffic crossing the IDS. If you try to zone transfer from the DNS server at ABCorporation.com, your request will probably travel across the firewall, and hence probably across their IDS systems. However, ABCorporation is not going to have IDS systems physically located at their ISP.
So: dig @ns1-auth.sprintlink.net ABCorporation.com axfr
If ns1-auth at Sprintlink allows zone transfers, you've just managed to get the complete zone of the machines, with IP addresses, at ABCorporation that are publicized via DNS, without irritating the IDS system at the target company.
"So?" you ask. Consider this output from the above command (IP addresses have been changed to protect the innocent):
All kinds of cool information. Let's analyze.
First, notice that there are six different routable Class C address spaces represented in just this one little <snip> of the AXFR output (which is only about 13 percent of the total output). That gives you six different entire Class Cs which you can safely assume belong to the same company.
Second, and this one is really cool, notice those 10.30.1.x addresses? Those are non-routable on the Internet. The entire 10.x.x.x Class A is non-routable - "Reserved for Internal Use." Hello.
As it turns out in this case, es1.ns and es2.ns are interfaces on the company's border routers, on the outside of their firewalls, and on the outside of their IDS. So what, can't route to 'em, right? Sorta... These are the company's border routers, i.e., the same routers that connect the company to their upstream service provider.
That being the case, the routers must also have routable IP addresses. See the line: inet 1H IN A 201.195.10.10
That's another interface on the same router that holds es1.ns. And it's Telnet-able. So, Telnet into that router.
In this case in particular, the username/password were: ABCorporation/ABCorporation
From there, Telnet to other 10.30.1.x IP addresses. What else was on the 10.30.1.x address space, you ask? Well, all of the firewalls had 10.30.1.x interfaces, as well as their CA Unicenter boxes (network discovery), as well as some of their internal routers.
All of this was on the inside of the firewalls. Of note, you are going to need to find another machine on the inside that you can telnet to from here in order to do any real investigation. Right now, on this router, you cannot compile exploits, etc., as you are on a router. In this case, that CA Unicenter box I mentioned had Telnet open with the same username/password as above. Bingo, Solaris 2.6 machine.
I found out later that they had done this because the nature of the company's remote access from home didn't allow them to access the border routers while dialed up to the internal network when they worked at home. So, they needed a way to connect to the border routers (which they could reach from the Internet), and from there into some of the internal network devices inside the firewalls.
Another case of corporate security policy gone wrong. The policy had good intentions, but internal employees who were inconvenienced by these policies created a way around them. They had no idea what this meant to the security posture of the organization.
Business Partnerships
Okay, we already said that your target is paranoid. Let's assume at this point that none of the above vulnerabilities are available directly from the Internet.
But, you do know that your target company has a close business partnership with a web-portal: XYZCompany, let's say. (You learned this from your website jaunt earlier.)
Well, typically, a company who has a tight business partnership with another company, depending on what the companies do for each other, will have special services allowed through their firewalls between them. They might even have a dedicated point to point or two between the two companies, sans firewalls.
Take a quick look at XYZCompany. Are they a Mom and Pop shop? Twenty employees? Internet presence? Bet they'll be a lot easier to get into than your final target. And, once there, you can enjoy relaxed restrictions into your target company... probably.
Corporate Acquisitions
Along these same lines, look for companies that have recently been bought/acquired by your target.
In most large organizations, the process of buying another company is a long and tedious one, but the primary reason for technology companies to merge is so that they can use each others' technology. So one of the first things to happen is usually a change in firewall rules, or the establishment of an internal network link to the "new arm of the company."
However, a corporate merger is a political beast.
Company officers will normally be very careful about stepping on toes, especially since the guy who used to be the CEO of the bought company is now a VP in your target company and probably a little touchy. So the extension of corporate policy to the "new organization" usually takes a couple of months, or even years to be fully enforced. The same thing applies to the security policy.
Normally, the company that was bought is usually a lot less established than your target, so maybe they don't have a security department. Maybe their sysadmins are lazier - who knows?
What does this mean to you? Quite simply, profile the recent acquisitions.
Perhaps you're picking up on a subtle theme here.
Sun Tzu, in The Art of War said, "Where you are weak, make your enemy think you are strong, where you are strong, make your enemy think you are weak. Attack your enemy in his weakest point with your strongest force. In this way you will be victorious." or something very similar...
In practical terms, you know they have firewalls, you know they have IDS systems, why bang your head on those protected avenues when you can probably find an avenue that's not protected at all?