I hate having to tell clients that they must choose between securing their network and easing their employees' workload, but when the safety of your corporate assets is at stake, tough love is sometimes the only real option. I'm a security expert and information security consultant, and I dealt with a situation recently that brought this dilemma to life when one of my clients called me in a bit of a panic. The client's Help desk had reported suspicious configuration changes on a remote employee's laptop. My client called me in to assist the IT staff and investigate a possible security breach. The background information I was given about the problem was troubling, to say the least.
The remote employee had called the Help desk to request a unique software installation. In this company, employees have limited privileges on their systems and can't install software themselves—instead, they must contact the Help desk for assistance. The Help desk technician initiated a remote session to the employee's laptop and was preparing to remotely install the requested software when she noticed something suspicious: The local Guest account was enabled and given administrator privileges with a password set to never expire. The company's standard laptop image always disables the Guest account, and the only way the account can be enabled is if an administrator with root privileges changes it. But for an administrator to make such a change is against company policy, and the remote employee couldn't have made it herself. To make a bad situation worse, the Help desk tech noticed that a non-standard piece of software—an FTP utility—as well as a nonstandard email program were installed on the laptop. That was when the tech reported the situation to the IT security department. That's also where I came in.
A Well-Hidden Portal
The security department obtained a forensics image of the laptop for security and legal reasons and began a Security Incident Report. My job was to figure out the who, what, where, and when. The Help desk asked the remote employee to immediately ship the laptop back to corporate headquarters for further investigation. Once the laptop arrived, I inspected the system log files, the SQL log files, and the FTP program log files. The "hacker" wasn't very savvy and had made no attempt to cover his or her tracks.
The laptop was an unpatched Windows 2000 system that had been deployed in early 2004. The remote user hadn't installed the firewall/router that the IT department had provided her. The user was running personal firewall software, but an absent or incorrectly configured firewall hadn't made the exploit possible—an unpatched system had. Windows Update wasn't configured to run automatically because installing patches required administrator privileges that the user wasn't allowed. That policy was a real mistake on the part of the IT department. IT explained the policy to me by saying that they had been forced to deploy laptops to the sales team before the company deployed a software management system. Their only choice was to manually update more than 700 laptops in the field on a monthly basis. The members of the sales team, who were constantly on the road, didn't always connect to the corporate network for patches and upgrades, an unfortunately common scenario.
In trying to discover how the compromise occurred, I learned that members of the company sales team had a local copy of the sales database on their laptop for the simple reason that they needed to access the information in the database when they were on the road and disconnected from the corporate network. The team members had been instructed to initiate a database replication periodically when connected to the corporate network through the VPN to keep their local copy and the corporate copy updated. This type of configuration requires Microsoft SQL Server Desktop Engine (MSDE) on the sales team's laptops.
The intruder had successfully executed an exploit that allowed him or her to achieve Administrator privileges on the laptop. The exploit took advantage of a well-known SQL vulnerability for which a patch had been released months earlier. The command line
osql.exe –S-U sa -P
made the exploit possible. The local SQL installation had to have a blank sa (systems administrator) password for the exploit to work.
The intruder was using the laptop to upload and save movie files that anyone to whom the intruder gave the IP address could use Guest access to retrieve. Some of the movie files were for prerelease movies in various languages. The corporate SQL server didn't appear to have been compromised, and the FTP logs didn't show that the intruder had lifted any confidential corporate or customer files. The possibility that such theft could have occurred, however, was all too real. I had no evidence to confirm or deny additional suspicion or speculation.
The IT security community is well aware that a black market exists for prerelease movie versions. The recording and movie industries are acutely aware of the problem as well. The remote laptop in question was inadequately protected and also connected to the Internet via a home DSL connection, making it easy pickings for a black marketer to finger as a distribution point. Any Internet-connected system running an unpatched version of MSDE or SQL Server is a potential target for this type of intrusion.
Taking Action
What now? My client had hundreds of laptops in the field with the same configuration as the compromised machine. The first order of the day was to document the results of the investigation and present it to senior management. Second, I pulled together the IT and Security teams to discuss the options for patching remote systems. Third, and perhaps most difficult, was initiating the larger discussion about how to secure remote systems in the field.
In our meeting, the IT team declared that they had shipped Linksys routers to remote employees with instructions for installing the routers to protect DSL or cable modem connections. I countered that the routers could do nothing more than provide Network Address Translation (NAT) and wouldn't protect a valid port from "listening" and thus running the risk of being discovered. True, each company laptop had antivirus and personal firewall software installed (specifically, the enterprise version of a Trend Micro antivirus product and Check Point's Integrity Desktop). However, the exploit had been performed through use of a valid, "legal" port, through which any firewall would allow a connection, and antivirus software would continue to operate unaffected. Users would remain blissfully unaware of what was happening.
So, what was the answer? As I told my client, the most conservative—and secure—solution is to prohibit remote employees from connecting company equipment to their home network. One Telecom company I'm familiar with allows only sales personnel to dial in to their privately owned network. Remote users must authenticate using a one-time authentication token, and their laptops are so completely locked down and their networks so completely locked up these employees can barely do the job they are required to do. Telecommuting is discouraged, and local field sales offices are provided for connectivity. There is no flexibility in this system, but neither are there security concerns.
To address the immediate problem, my client chose to inform the remote sales team that each member had to connect to the corporate network on a specific date so that patches could be pushed to all the systems. Additionally, a database replication was prepared for the sales application that pushed out a hard-to-crack Administrator password to the local MSDE installations.
Get Tough
If your enterprise sanctions telecommuting and you have an installed base of remote employees, securing remote systems is a tough problem that you need to address. The main problem in my client's situation was that no software management system was in place to regularly update systems in the field. The IT team contended that senior management had cut the software management system from the budget but had also insisted that the sales force be "enabled immediately." However, if the corporate network had been breached as a result of the exploit I've described, my client would have had a much larger problem than a budget-cutting executive with egg on his face.
