Small companies and small divisions of larger organisations often try to provide complete business functionality—e-mail, Web presence, domain-based network—with limited resources.
As two recent engagements illustrate, attempting to do too much without sufficient resources and an awareness of some basic security practices can put an organisation’s security in jeopardy. When you come across client setups like the two I’ll describe here, encourage the client to get back to basics and eliminate vulnerabilities created when networks aren’t segmented correctly.
Sign up for the Internet Security TechMail today!
Get valuable tips, links to security resources, and much more, all delivered straight to your inbox, absolutely free.
Different organisations, same problem
A division of state government and a regional office of an internationally recognised philanthropic organisation wouldn’t seem to have much in common. However, both organisations used a single internal Windows server—one NT, the other Windows 2000—to act as a domain controller and Internet mail server, due to limited budgets. One of the organisations also used the server to host its public Web site.
This configuration violates a basic tenet of network security: appropriately segmented assets and services. Since their servers were domain controllers, the organisations placed them on their internal network and provided the servers with external IP addresses to allow mail and Internet access. Both organisations also had nonfirewalled connections to their respective parent organisations’ networks.
The state government hired our company, CQUR IT, after the Web site was defaced several times. They had also detected inappropriate access and nonauthorised security changes on the domain controller, including deletion of security logs.
The philanthropic organisation engaged us for the IT security elements of a financial audit, during which we learned that they suspected that their network-attached PBX had been hacked. Two other “unexplainable” incidents had necessitated two complete rebuilds of the domain controller in the previous three months, causing the irreparable loss of critical organisational data.
Know who is at the door before you answer
Whenever we find an organisation with a domain controller assigned external IP addresses, usually for Web or e-mail access, it raises a red flag. This configuration is often a sign that the organisation doesn’t have an overall awareness of security best practices and usually indicates more significant security concerns.
Our initial step for both organisations was to scan the mail servers using Nmap and SuperScan. We were extremely concerned by the high number of open ports, including TCP port 139 (see Figure A).
A scan of the client’s mail server
The NETBIOS standard allows a significant amount of information to be gathered via port 139, even if the domain controller doesn’t authenticate the user. (This vulnerability is well documented; a good discussion is included in the well-regarded text Hacking Exposed.)
One way the vulnerability can be easily exploited is with a tool used by security professionals and hackers alike: NBTEnum (Net Bios Enumeration). The scrubbed example of the output we gathered from one of the organisations illustrates the rich amount of information about a system, including all local groups/users, global groups/users, shares, and password policy information (including account lockout thresholds) that can be gathered.
Once a malicious external user has access to this information, it makes it significantly easier to gain inappropriate access to the network.
The password is “password”
The philanthropic organisation had all its volunteers log on via two user accounts that were aptly named volunteer1 and volunteer2. We assumed, based on the organisation’s lax security posture, that these accounts were probably protected by simple, easily remembered passwords.
We attempted to connect to a network share remotely using the Windows run command: \\xxx.xx.xx.xxx\sharedfoldername and were prompted for a username and password. Our first three attempts, using “password,” “organisation acronym1,” and “organisation acronym2” failed. On our fourth try, using “organisation acronym3,” we gained access. At this point, we were browsing shared network folders.
To make matters worse, the organisation wasn’t using an appropriate level of access control, and the volunteer accounts could browse the complete contents of the domain controller (the C: drive was inappropriately shared.)
Using our newfound access to the domain controller, we copied the registry to our machine and used LC3, better known as L0phtCrack, a password-cracking tool, to attempt to determine user passwords. Using a dictionary attack—in which we tested each encoded password against the list of often used passwords—we returned 23 out of the 61 user account passwords.
Ironically, one of the first passwords cracked was an IT vendor’s name used by the network administrator. This granted us complete administrative control of the domain controller.
Due to a series of poorly executed security measures (inviting untrusted traffic into the trusted network and onto the domain controller, null sessions enabled, poor password policy, poor access control), it took us less than an hour to take control of the client’s network.
“Bubba” is in the house
The governmental division’s assessment was strikingly similar. From previous conversations with the client, we knew their password policy specified passwords with a mix of at least six alpha and numeric characters. During a brief penetration testing session, we loaded LC3 with a list of common passwords and instructed it to append and preface all passwords with up to four random numbers.
We were quickly able to crack four of their 21 accounts; the most damaging was a test user account labeled “Bubba” that had been used to troubleshoot a problem several months before. (We have noticed that administrators for SMB networks often create temporary test accounts that share the same password as their own account.)
While the password didn’t directly provide us with administrative-level access, its construction (football team name + calendar year) did allow us to rather quickly guess the actual password for the administrator’s account (baseball team + year). The same series of poorly executed security measures used by the nonprofit organisation had left their network vulnerable.
Preach fundamentals
Here is some general advice for clients who may be cutting corners the same way:
TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.
©2001 TechRepublic, Inc.
6%
1%
