Slashdot Mirror
Company's Former IT Admin Accused of Accessing Backdoor Account 700+ Times (bleepingcomputer.com)
An anonymous reader writes:
"An Oregon sportswear company is suing its former IT administrator, alleging he left backdoor accounts on their network and used them more than 700 times to search for information for the benefit of its new employer," reports BleepingComputer. Court papers reveal the IT admin left to be the CTO at one of the sportswear company's IT suppliers after working for 14 years at his previous employer. For more than two years, he's [allegedly] been using an account he created before he left to access his former colleagues' emails and gather information about the IT services they might need in the future. The IT admin was fired from his CTO job after his new employer found out what he was doing.
One backdoor, which enabled both VPN and VDI connections to the company's network, granted access to a "jmanming" account for a non-existent employee named Jeff Manning...
One backdoor, which enabled both VPN and VDI connections to the company's network, granted access to a "jmanming" account for a non-existent employee named Jeff Manning...
Yeah... because the guy setting up that system wouldn't be able to hide anything he wants outside of the system on those servers. You know, like hiding a backdoor, I mean it's not like he was the ADMINISTRATOR, and had full unlimited access to the servers for a long time or anything....
You can make all the damn rules and regulations you want, but in the end you are bound to having to trust the people who have full access to the systems to implement those rules properly. There will always be someone somewhere in the setup chain that will not be bound to those rules yet, as the settings and rules won't exist on the servers yet.
To err is human; effective mayhem requires the root password!
One of the two accounts he was using was a "service account". You probably have a few of those on your system also, that were not created by any system linked into your HR. The manning account probably should have been automatically disabled however.
Seeing as he had IT level access, no automated steps are going to be very effective. If he created the manning account manually and there never WAS a mannning user, any automated HR system that removes employees on departure will never trigger on it since it was never in HR to begin with. If your HR system does whitelist filtering instead of blacklist, it has to know which internal and service accounts to skip. (or chaos insues!) An intelligent IT person will simply flip the necessary switches to make the account not show up in the pool that's being whitelist-checked. There's probably an "Employee" checkbox in the account list, and he just unchecks that, and now the HR script ignores him.
dscl . -list /Users | wc -l
shows there are 103 accounts on my laptop, only four of which are actual interactive users, the rest are system users like sandbox, daemon, windowserver, etc. A marauding system admin can pretty easily sneak in another plausible looking system account into the list of users that don't show up in most userlists.
tl;dr: it's not so easy to detect when someone in a privileged position like IT (or your IT admin) has installed a back door. Hiring someone to come in and do an audit (or hiring a competent replacement that does the same) is your best response to an IT departure, and is really a NECESSARY response to any departure of upper IT, even if the departure was on good terms.
I work for the Department of Redundancy Department.
Another popular trick is to give one of those service accounts a shell and password so they can double as logon accounts.
I'll just leave this here:
http://io.fondoo.net/
"Fun fact: you could telnet to password.io.com from anywhere in the world, and log on as guest. Lynx, a text-only web browser, was configured as the shell, and you would then be presented with a sparse version of the web-based customer account tools found at http://password.io.com/. This was so customers could reset their own password, update their address, set their PLAN file, etc.
IO forgot to disable browsing the filesystem (press g, period, enter). Also, IO never enforced uniform file and directory permissions or audited active accounts. As a result, through 2004, after IO was taken over by Prismnet (or later), you could roam around and directly view many customer's private files, email, and IO's sensitive system areas. You could also open the Lynx config to define a custom "editor" and thus actually edit files, or run executables. This was a direct back-door into everything! This continued a full two years after IOCOM "hardened" their network to sell network security services."
That sounds easier than it really is.
I once found a root cron job that ran a script that was about 100 lines long. That script called another script that was close to 1000 lines long. The admin hid a call in that script to call a third script. That third script would check the time and the accounts, if it was between 00:00 and 02:00 GMT and his account was not in the system it would add the account with root privileges. When 02:00 came around it would delete the account from the system.
So basicly between 00:00 and 02:00 GMT he could access the system with admin privileges and do whatever he wanted. I only noticed it because I saw a login at 00:30 by an account that did not exist. I almost missed it because it was called deamon and when scanning the logs you can dismiss it as the daemon account. It took me days to find where the add and delete user account commands were hidden.