- Introduction
- Threats from the Inside
- "But I Trust My Employees!"
- Lessons Learned
- "What Can We Do? We Can't Fire Everyone, Can We?"
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
"But I Trust My Employees!"
Certainly, every company should feel that employees can be trusted to behave in a professional and ethical manner, and not do anything that knowingly threatens or compromises the security of company networks or data. In fact, such sentiment is necessary to maximize productivity and create a healthy workplace environment.
But consider the following incident.
On an internal penetration engagement, our team was given a conference room with a live network jack. The goal of the engagement was to assess the security of the client's back-end database servers from unauthorized access by company employees. We didn't know the layout of the network, except that the target servers were behind a firewall and on a separate segment. We did know that the segment onto which we were allowed was populated by employee machines.
The company was running Dynamic Host Configuration Protocol (DHCP), so when we plugged in we received a valid network address. The first thing to do was to discover the network. We broke out our tools and started plugging away. We ran the net view command to obtain a list of domains and user workstations within each identified domain that we could see from our current location:
C:\>net view /domain
Based on the results, we ran this command:
C:\>net view /domain: domain_name
Next, we tried to connect to each machine by creating a null session (essentially a session between two machines with no authentication—no username or password):
C:\>net use \\machine_name\ipc$ "" /user:""
Once we had a connection, we attempted to determine whether there were any shares on these machines:
C:\>net view \\machine_name
Some shares on a few machines were identified. We then attempted to connect to those shares with the net use command again, and by trying some default usernames and passwords. We connected successfully to several shares with the username/password pair administrator/<blank password>:
C:\>net use \\machine_name\c$ "" /user:administrator
NOTE
It's surprising how many NT networks even today are still vulnerable to such unauthenticated or null session connections.
Unfortunately for the company, the local administrator account had a blank password.
Once connected, we were able to copy over, install, and run Virtual Network Computing (VNC), a remote-control program similar to pcAnywhere. This allowed us to control the local administrator's machine from our laptop.
NOTE
We had cracked the local administrator account on a desktop machine. This is not the same as the domain administrator account that has admin access to all machines. This local administrator had admin access only to this machine and its SAM file; it didn't offer user IDs and passwords that could be used on other hosts.
We were ready to attempt to access the back-end servers with the information we had gathered thus far. Before doing so, however, we took a moment to look around this machine's filesystem (and those of others who also had open shares) and found a local copy of a Microsoft Access database. Because databases often contain interesting information, we copied this back to our laptop to examine. Once we did, we found that it contained sensitive customer information. Our client was able to confirm that this was at least a partial copy of a database stored behind that second firewall layer.
While there were additional vulnerabilities that allowed us to get at this information (network-allowed null-session connections, blank administrator password), the true Achilles heel here is that an employee had kept a local copy of a sensitive database.