As administrators, we often devote a lot of energy to external security. We install firewalls to protect the network from outside hackers. We use encryption to protect the data we send over the wire. We use group policies to control who has access and when. However, too often, we forget that the greatest threats can come from those who already have access to the network. I’m going to share the story of how one administrator dealt with an internal attack on her network and how it caused a reevaluation of internal security in her organization.
Meet the enemy
Internal security has always been a priority in the company where Debra works as a senior network engineer. Management has made it clear to users that they are not to share passwords and should never attempt to access information they are not intended to access. In fact, breaking either one of these rules can be grounds for termination. Nevertheless, that didn’t stop one particular new employee from becoming a nuisance.
A new associate in sales came to the IT department shortly after he started working at the company and wanted to talk about an idea he had to save the company money. Upper management encouraged IT to work with him since the idea involved cost savings.
The company was considering purchasing an expensive software package. The sales associate claimed he could put together the same system using Linux, some other readily available open source packages, and a little programming. He met with IT and diagramed it all on a white board. It was impressive, and it sounded pretty easy to set up. All he needed to begin was a network connection for his Linux box. Feeling pressured by administration, IT gave him access but explained he would need to work with IT and contact them when he needed assistance.
Debra was given the task of working with him on the project. She had been learning Linux and looking for areas where the company could use it on its network. She was excited about the project, but like her boss in IT, she was a little hesitant about the new associate’s ideas, which seemed too good to be true.
The new associate’s office was equipped with two network connections: one to his company-supplied Windows NT PC and the other to his Linux box. He was not given any special access. He was a domain user like any other normal user. He was instructed to contact Debra if he needed additional access.
About a week later, an IT employee was walking through the part of the building where the new associate had his office and noticed something out of the ordinary. A small generic network hub was plugged into a nearby network jack and was being used to span the port. A network cable was connected to a nearby server. This server was part of the project the new associate was working on.
The hub was removed and the incident was reported. When confronted, the associate apologized and said he just wanted to get going on the project and didn’t want to bother IT. Once again, he was informed that he needed to work with IT on this project. IT explained that a cable run was ordered and should be completed the next day.
A few days later, Debra was given the task of setting up his e-mail. She attempted to connect to his PC via PCAnywhere and received an error that the machine was not present. She checked Server Manager and verified the PC was active on the network. A check of the services on the associate’s PC revealed that the PCAnywhere service had been stopped. She started the service without problem. Right away, she became suspicious.
The PCAnywhere service typically does not stop unless it has a problem on startup. She checked the event log of the PC and didn’t see any messages indicating the service had failed to start. She proceeded to connect and begin the Outlook setup process. At the end of the process, an authentication dialog popped up. Something was wrong. The IT departments has Outlook set to use the NT logon, and the only time the logon will appear is when NT does not recognize the account that is trying to access the mailbox.
Debra clicked on the Start button to see who was logged on and was shocked to see “administrator.” She turned to her manager in IT, who was standing behind her, and said, “He’s changed the administrator password on this machine.” To verify this, she logged off and attempted to log on with the administrator password. The password had been changed.
The entire event was documented and submitted to upper management. Now the IT department had to decide what action to take. It decided that the associate’s PC would have to be locked down better, and that IT would need to monitor the machine and the new associate closely. The administrator password was reset using Winternals System Commander 2002. Next, Debra removed the ability to boot from floppy and CD-ROM and set a password on the system BIOS. She knew the BIOS could potentially be reset with a jumper or possibly by removing the system battery. To prevent this, or at least make it difficult to open the system, she added a lock to the case.
On the software side, she enabled auditing on the PC and began checking the logs on a daily basis. Several days later, she remembered a TechRepublic article that mentioned a tool known as SELM, or Security Event Log Monitor. She installed the SELM product—which can e-mail alerts as well as create reports for later review—so that she wouldn’t have to manually check the logs every day. In addition, she monitored the PCAnywhere service on this PC.
In a meeting, the new associate apologized for his actions. He explained he was working very late and did not want to bother anyone at that hour. He had some software that he wanted to install for the project he was working on and needed administrator access to install it. The IT manager went on to explain the policies the company has in place restricting anyone from installing software without IT involvement. He further explained that IT was on-call after hours for any problems or needs that might arise. The new associate decided that he did not want to work on the project anymore.
During a routine check the next day, the new associate’s PC did not appear to be connected to the network. A call to his office confirmed that he had not arrived for work yet. Debra was given access to his office and discovered he had disconnected his PC from its network jack and had connected his Linux box to that jack instead. She disconnected the Linux box and reconnected his PC.
The next day, the same scenario played out again. His PC was gone from the network. Debra couldn’t gain access to his office, so she entered the wiring closet where his network jacks were connected and viewed the status of the switch ports. One port had an active connection. Since she knew his PC was not connected, the only possibility was his Linux box. The patch cable was disconnected, and the entire incident was again reported to upper management. He was asked to remove his Linux box from the premises. He indicated he would comply, and his other PC was reconnected to the network.
Debra realized that she needed some way to be sure that his Linux box was truly off the network. Again, she remembered a TechRepublic article about various net admin tools. One of those tools was the GFI free network scanner called LANguard. She installed LANguard and scanned her entire network. It did a pretty good job of identifying the types of systems it found. It recognized a Red Hat Linux system as “probably UNIX,” but it recognized one of Debra’s Mandrake boxes as “Linux Mandrake.” After running a scan, LANguard can sort the results by OS, which makes it easy to view what has been discovered. In addition to listing the OS, it indicates all the open ports on a system and points out known vulnerabilities. Debra now runs scans daily and reviews to see whether any new systems show up. The registered version offers a comparison feature that allows comparison of two scans to note any differences.
Once a hacker
Things were pretty quiet for a while. Then the SELM software sent a few alerts with the new associate’s name. If you have used security auditing in NT, you already know the security event log can have some pretty cryptic messages. Nevertheless, after doing a bit of research, Debra figured out that the new associate had downloaded some software and was stopped dead because of the lack of admin privileges. Looking closer at the machine, she found that several services had been stopped; one was the antivirus software, and another was the PCAnywhere service. The associate was again confronted, and he told IT what it had suspected: He had attempted to install software on his PC but was unsuccessful because of the lack of administrator rights.
Next, the IT department turned to the System Policy Editor. It wanted to disable access to several Control Panel applets, especially the Services applet. IT was already using system policies to perform change control, such as limiting access to the Display applet in the Control Panel and use of the Run command and the registry editing tools.
Although the System Policy Editor in NT has no built-in controls for limiting the Control Panel except for the Display applet, you can customize it by creating your own ADM files with the proper registry tweaks. So Debra created a custom ADM file that removed the Devices, System, Services, Server, and Network applets from Control Panel.
The entire event was exactly what Debra’s IT department needed to test its current security policies and find out the strengths and weaknesses of its internal security. Sometimes, a problem such as this is ideal for evaluating your security practices, as long as you have the right stuff to fight the problem—and most important, to keep a similar problem from popping up in the future.
In this battle, Debra and her IT department mainly acted reactively. But it led them to look at their policies and practices and try to be more proactive and prevent similar incidents from occurring. They are still revising their security policies and making changes to keep their network secure and their data protected.