Confidential Report

Network Security Review

Prepared by

Stephen J. Friedl, Network Consultant

4 May 2000

 

NOTE TO READER: This report was commissioned by a department not responsible for the network security, and the network department had completely ignored repeated notifications of security issues. I was asked to write the report in a way that could not be mistaken or “spun” to higher management, which explains the adversarial tone. Most of my engagements are entirely cooperative and have no such tone.

 

All IP addresses, machine names, and user names have been randomized.

1.    Summary

At the request of the Accounting Department, I conducted a review of Customer’s external network security, and my findings are that customer has enormous exposure to unwanted theft, alteration, or destruction of data.

From my home network and without any special or inside knowledge, I was able to penetrate the external NT machine used as the mail server with full Administrator privileges. This provided the information required to access the Unix machine “finance” as the system administrator, where a great deal of financial and personnel information seemed to be stored, and from there I could “see” what appeared to be the entire internal network. These internal machines were probably drastically less secured on the presumption that the external network would keep intruders out. It is clear that this is an improper assumption.

I have the impression that there is very little data in the computer networks that would be unavailable to me, and this is largely due to what can only be considered grossly negligent network design. I have heard that customer has a PIX device, which is an outstanding firewall from Cisco Systems, but these external machines have been set up to essentially bypass it, rendering it nearly useless.

The network is massively exposed, providing a moderately skilled intruder (less skilled than me) with an avenue to virtually everything that customer has to offer. I suspect that this exposure includes information which the customer is required to keep confidential, making the exposure legal as well. My opinion is that this must be attended to immediately, and an extensive additional review be undertaken to lock down customer’s important data.

2.    Review Procedures

The Customer has a class C network (192.168.10.0/24) with Internet service provided through (ISP), but the great bulk of the 254 addresses are not visible to the outside world. Of the machines that are visible, several are of particular interest:

(list deleted)

 

Though clearly the mail server must be exposed to the outside world, it is not clear why the other machines must be.  Note that these machines are known by different IP addresses on the “inside” of the network, which is a symptom of one of the significant problems.

3.    Penetrating the Mail Server

The mail server is used to receive electronic mail from the outside world, and this is where my interest started. It is known as PDC\MAILSRVR on the inside of the network, and it is found at 10.1.1.55.

This machine runs Microsoft Windows NT Server, and its “network neighborhood” facility is open to the general public. I used a free tool[1] available on the internet to enumerate the users and the shares. A very small part of this listing is shown in Section 10, with the full listing running to hundreds of pages and about 800 users.

When penetrating a network, surveillance is always the first step. Gathering lists of users provides a tremendous amount of information to an attacker, and this list alone is dangerous to allow the world to access. The next steps make this even more clear.

Because the “network neighborhood” facilities are available, an intruder is also able to guess passwords on the NT server, so the user list he just gathered is a great starting place. Of the 800+ users on the system, 22 of them have Administrator privileges, which allow “free run” of the system. If one of these passwords can be guessed, the entire machine will be penetrated, and it turned out to be easier than expected.

Another free tool[2] was used to try automated password guessing. My experience is that many accounts are set up with very poor passwords, so with this many users to choose from it was likely that some would be guessed. The tool was given the list of administrator users and a small list of a few hand-picked sample passwords. This list included the words “root”, “admin”, “password”, “customer”, and “customer1”.  After a few minutes, it revealed that the Administrative account “XYZ” has the password “password”. I’m in.

This provided full access to all data on the machine. My brief investigation showed a fair amount of financial information, such as a wire transfer log. Not being well-versed in Customer accounting, most of it didn’t mean anything to me, but it’s hard to imagine that this was public information.

The next step was essentially to crack these passwords. Using a $100 tool[3] I was able to connect to the full user list and pull down the encrypted passwords, then apply both dictionary and brute-force attacks to the passwords at just less than a million guesses per second[4]. It found the first 400 passwords in two or three seconds, with additional passwords coming rapidly thereafter. Of the 829 accounts on the system, 743 have been cracked as of this writing. Section 11 is the list of passwords cracked so far.

The danger of allowing the general public to have access to the Customer’s primary domain controller is obvious, but this provided the information needed to access even further inside the Customer’s network.

4.    Penetrating the UNIX machine

The machine “finance” at inside IP address 192.168.200.2 is a machine running type of UNIX, and this machine presents a login prompt to the outside world, so a user who can guess a password can get access to this machine.

I started with the list of users extracted from the mail server. By using the remote “finger” command I was able to determine which users were valid on the machine and which were not. This shows a transcript of that session from my home UNIX machine. My commands are in bold.

$ finger root@192.168.10.251            

[192.168.10.251]

Login name: root       In real life: System PRIVILEGED Account

Directory: /       Shell: /bin/csh

Last login Wed May  3 20:25 on ttyp0 from 172.X.X.X

No Plan.

 

$ finger user1@192.168.10.251

[192.168.10.251]

Login name: user1       In real life: System user #1

Directory: /home/user1       Shell: /bin/csh

Never logged in.

No Plan.

 

$ finger user2@192.168.10.251       ß invalid user

[192.168.10.251]

Login name: user2       In real life: ???

 

$ finger user3@192.168.10.251     

[192.168.10.251]

Login name: user3       In real life: System User #3

Directory: /home/user3       Shell: /bin/sh

Last login Wed May  3 16:59 on ttyp0 from 172.X.X.X

No Plan.

$

 

This process can continue until all users are known, and it was to rely on the common problem of people reusing their passwords in more than one place. Recall that I was able to crack more than 700 passwords, and I only need one to get access to the system.

As it turns out I got lucky, because user “user3” has no password on the UNIX system, so I or anybody else on the internet can log into this server very easily. Once in I spent my time looking around and attempting to get “root” access, which is the superuser and has full access to everything. The approach taken was somewhat complicated, but was accomplished in a few minutes due to the sloppy administration of this system.

My first step as root was to create an account for myself to permit me to get back in later should my initial entry point be discovered. I created an account “1istings”, which looks very much like the real account “listings” already in existence. The difference is that my account starts with a one, not an ell, and this was designed to make it harder for an administrator to see that an unwanted intruder was on the system (hiding in plain sight). The password for this account is “customer”, and it is indeed a superuser.

Looking around revealed numerous systems, including a lot of systems that seem not to be used any longer, but active systems were seen for “user7”, “user8” and “user9”. I am very familiar with the Pick system, and had time permitted I would have surely been able to find interesting information here.

5.    Wandering around the Network

Moving on, I downloaded some tools from my home network to the Unix machine which allow me to investigate the network. One particularly good tool is “nbtscan”, which enumerates all NETBIOS names visible, and just scanning the 10.1.1.0/24 network shows:

# nbtscan -p137 10.1.1.0/24

10.1.1.10       PDC\SERVER1                     SHARING

10.1.1.13       PDC\SERVER2                     SHARING

 

(many more deleted)

 

All machines with “SHARING” noted make some or all of their hard disk data available over the network, and with the proper tools one could access them from the UNIX machine. Even though this is not an NT machine, there is free software available (“SAMBA”) that allows a UNIX machine to interoperate with NT networks, and precompiled binaries are available over the internet. I suspect that Samba could be up and running on this machine in a few hours, and from there it would be a veritable orgy of data access throughout the customer’s network.

6.    Beyond The Internal Network

It turns out that the exposure is not limited to just inside the Customer’s network. The /etc/hosts file on the Unix machine mentions two machines not on your network:

(deleted)

A query to the Internic[5] reveals that these are owned by “Partner”, and I am able to “ping” and “telnet” to these machines from the UNIX system. These IP addresses are not visible to me at my home network, so clearly the Customer’s network is afforded some level of trust by Partner, a trust that is apparently unwarranted.

I did very little investigation of these external network issues because my authority for network review did not extend to Partner, and it is not clear to me (a) how much attention they are paying to their network logs and (b) how friendly they are on security matters. I was not willing to find out either of these by experience, but I believe that the Customer has an obligation to protect Partner-visible networks.

7.    Worrying about Inside Jobs

My review included an onsite visit to the Accounting department, and it became clear that the Customer’s network is essentially “flat”. There do not appear to be any protections between the various departments, and an authorized user of any part of the network could essentially take control of all parts of it.

The same tools used from the outside of the network – nbtscan, nbtdump, L0phtCrack – work just as well on the inside of the network, and any low-level clerk in an unsupervised office could essentially wander all over the network as I did. The big difference is that it would be much faster and easier and less likely to be detected.

In one sense this is less of a danger than that from the outside, because random employees are more likely to be trustworthy than random bad guys on the internet, but this is a two-sided coin. The employees are also much more likely to have specific knowledge of what data is “interesting” and to have a more personal agenda for this access.

[NOTE: Customer was in a sensitive industry rife with intrigue.

In addition, partitioning access between unrelated departments makes much more sense I am able to convey here – it was an unusual circumstance.]

But speaking more broadly, even with fully trustworthy employees, it is much better for network security to have “partitioned” access so that compromise of one part of the network doesn’t bring down everything. There is a remote office at (location), and somebody breaking into that network (say, cutting through the wall near the router) would have more or less full run of your network.

8.    Summary of findings

I am hard-pressed to recall a network with this much valuable information that has such poor protections and such easy access from the outside. Though I believe Customer has an excellent piece of network security equipment (the Cisco Secure PIX firewall), it is rendered virtually impotent by the current configuration.

Though the penetration of both the mail server and the Unix machine required a higher-than-usual level of skill – familiarity with both UNIX and NT networking – there is a second path to the inside network that involves strictly the mail server. In perhaps 10 minutes, an attacker could install Back Orafice, a hacker tool much like pcAnywhere, that allows the attacker to "drive" the computer and not just access its files. Back Orafice is designed to avoid detection, and from here no special additional software is required to access the entire inside network.

I believe that (at least) dozens of high-school students in the area have the technical skill required to penetrate your network by this method, and we’re living in a time when young people often have technical skills that far outpace their character skills. This is a very substantial exposure.

I must be clear that this is not a case of my finding a small hole in an otherwise secure network. Even the best network administrators[6] can make a small oversight that allows the bad guy to get in, and this illustrates one of the common maxims of security:

To be secure, you have to get it right 100% of the time.

The bad guy has to get lucky just once.

No, this network was insecure by design on many levels. No network should ever allow outsiders to guess passwords to normally internal-only services, and this can be easily stopped at your border router that connects you to the Internet. By blocking telnet and NETBIOS traffic at the very entry to the network, none of the attacks I used would have gotten anywhere. There is not a single security engineer that I know who would ever allow NETBIOS access from the internet. Ever.

In addition, no machine that has direct inbound access from the internet should also be dual-homed onto the internal network because this allows one compromise to be complete compromise. At least four machines are dual-homed in this way, and it is not clear why any of the UNIX machines need to be this way.

It is hard to believe that I am the first to have gone down this road, and some brief investigation of the Unix machine shows a few other accesses from outside the network. In February and December there were accesses from UUNET dialup accounts, and in early January there was moderate activity as “root” and “payroll” from an Exodus network. These were derived from the UNIX “last” command that shows recent logins. I’ve excluded my own access:

User       tty       remote IP       Date/time             (duration)

       listing deleted

 

Note that a skilled intruder could easily have covered his tracks by removing entries from the access log, something I didn’t bother to do for my own access. Whether these accesses were legitimate or not may never be discovered.

9.    Recommendations

Customer must take several steps, some of them immediately, to reduce its exposure to outside internet traffic. Some will require purchases of hardware, some will require substantial planning and design, but a few can be taken immediately.

9.1.       Block NETBIOS, SNMP, and telnet protocols at the external router

The Cisco router on the network’s outside border can be configured to drop all NETBIOS (network neighborhood), SNMP (Simple Network Management Protocol) and telnet traffic at the network border. These are the three most dangerous protocols on the internet – in that order – and though they are all useful internally, there is no reason to permit random internet users to attempt access via these channels. Just this step stops 90% of the exposure, and nearly all of it from the casual or high-school crackers.

Configuring the router in this way would take perhaps an hour: the steps themselves are straightforward, but since the current configuration is unknown, a bit more careful study must be undertaken to be sure that legitimate traffic is not blocked inadvertently.

9.2.       Move the UNIX machines fully inside the PIX firewall

The various UNIX machines don’t have any apparent need to allow inbound access from the outside world, so the conduits for these machines should be removed immediately, putting them fully on the “inside” of the network where they belong. This equipment has too much sensitive data to risk exposure to the outside.

It is possible that some remote access to these machines is desired, perhaps by a software vendor for the purposes of providing support, and this need may be legitimate. However, solutions exist to permit this secure access without exposing the network to undue risk. This is addressed in section 9.6 on Virtual Private Networking.

9.3.       Establish a DMZ

A “Demilitarized Zone” (DMZ) is the common term for a small portion of a network between the inside network and the outside internet, and it must be built carefully to limit your exposure to compromise.

The current mail server is the Primary Domain Controller for the COMPANY domain, and it is much too sensitive a machine to permit direct contact with the internet. This machine should be moved inside the PIX firewall and a new mail server put in its place on the outside. This new server would not actually hold any mail: it would simply relay the mail from the outside to the PDC on the inside.

Furthermore, the PIX firewall should be told to accept email ONLY from the relay machine in the DMZ, and to accept no other traffic from this machine. By this arrangement, an intruder achieving even full compromise of the DMZ mail server has no way of further penetrating the inside network.

9.4.       Secure the UNIX machines

The UNIX machine I used to break into the network was compromised in part because a user had no password, and there are seven such users (presented here with their descriptions from the password file, if any):

(listing deleted)

These users must either be deleted or given proper passwords.

Furthermore, the nature of the UNIX machine is that if I can access any part of the system, I can access all of it. Breaking root was an easy trivial exercise because an administrator was sloppy, and this must be cleaned up also. But more importantly, the Customer data stored in the Pick system is all open to any visitors. Though the programs may ask for passwords, the underlying data files are all readable, and it would not take much effort to duplicate the (say) payroll system in a way that didn’t require a password.

I never managed to penetrate either the other UNIX machines, but this was because other targets were more promising, and a similar review of these machines should be undertaken as well to track down these simple issues.

9.5.       Establish Password and Account Policies

In an organization with thousands of employees and hundreds of PCs, it is very hard to insure that everybody has a good password, but at least the administrators can be policed. In my onsite review of the Department A systems, we uncovered several users who were administrators but shouldn’t have been. All Primary Domain Controllers in the network should be checked inspected for accounts with administrative access, and users “downgraded” when appropriate.

In addition, when employees are terminated, they must be removed from every system to which they have access. There should be some kind of procedure that makes this a necessary part of termination and not left to the whim or diligence of individual administrators.

All the Administrator accounts must be required to have very strong passwords, and they should be audited with password-crackers like L0phtCrack. A “strong” password is one that is not simply alphanumeric, and it cannot be a variation of a dictionary word or words. This takes some time to get used to typing “al1;10%zz” instead of “billy[7], but this is simply necessary to maintain a secure network.

All NT machines should have aggressive password-protection policies that prevent many kinds of shenanigans. For instance, there should be a “three strikes” policy on bad passwords: three incorrect passwords given in a row should create a 30-minute lockout of the account, and these attempts should all be logged and reviewed periodically.

9.6.       Establish a Virtual Private Network for remote users

It is inevitable that some users outside the network require legitimate access to the inside: software vendors providing support, managers working from home, or temporary remote offices. All of these are legitimate needs, but providing this access should not compromise the rest of the network in the process.

By using a Virtual Private Network, a secure “tunnel” from a remote site – say, at my house – to a point on the inside of the network, and it is done in an encrypted manner. This prevents the bad guy from intercepting the traffic even should the bad reside inside the network, and it doesn’t open up any substantial exposure from unwanted access.

Some VPN solutions are software-only, including Microsoft’s PPTP (Point to Point Tunneling Protocol), though they are not considered fully secure or very expandable. Other solutions are based on hardware, and though more expensive, provide rock solid security, scalability, and performance.

Knowing just which solution is appropriate depends on the customer’s needs, knowledge of which is outside the scope of this review.

9.7.       Perform Full Internal Security Audit

The information gathered for this Report was done hastily[8] and with no “inside” information. The primary focus was on the external visibility, and even then it only touches on the key points.

A much more comprehensive audit should be undertaken that takes into account all network assets, and a plan formulated that achieves a balance between security and productivity. This kind of analysis cannot be done properly from the outside looking in.

10.           Appendix: Mail server network user/shares (partial list)

This only a partial listing of the more than 800 users on the external mail server: the full list is available upon request. It’s 137 pages.

 

Cerberus Internet Scanner

Results

for

192.168.10.252

by David Litchfield

Cerberus Information Security

NetBIOS

 

Share Information

 

Share Name      :NETLOGON

Share Type      :Disk

Comment         :Logon server share

 

Share Name      :ADMIN$

Share Type      :Default Disk Share

Comment         :Remote Admin

 

(much more information deleted)

 

11.           Appendix: Mail Server Passwords

These passwords were “cracked” from the mail server machine in a matter of a few hours after extracting them via the L0phtCrack tool. Administrator users are shown in Bold early in the list: these are particularly dangerous. This list might included disabled users, but even this information can’t be considered harmless.

 

(15 administrator accounts with passwords deleted)

 

(659 “regular” user accounts with passwords deleted

12.           Appendix: Machines seen on the Customer networks

This is not an inclusive list: it’s the result of a quick scan (five minutes) using information available as an outsider. A more comprehensive report is surely possible with more time.

 

10.1.1.10       PDC\SERVER1             SHARING

10.1.1.13       PDC\SERVER2             SHARING

 

(about 400  other machines deleted)



[1] nbtdump, from http://www.cerberus-infosec.co.uk

[2] nat, the NETBIOS Auditing Tool

[3] L0phtCrack 2.5 from http://www.l0pht.  “L-zero-pht” is pronounce “loft”

[4] A 1GHz Pentium III can do more than two million guesses per second

[5] The body responsible for allocation of all IP addresses on the internet

[6] Even my otherwise-secure network was hacked a few months ago due to a very small oversight

[7] This is Manager A’s password

[8] Less than 20 hours, including preparation of this report