Today I've had to deal with a security issue for a friend, a certain department manager had a machine with a set of serial numbers for each of his developers tool stack, quite expensive stuff, these were stored in a text file on his desktop in a folder called "serials".
The problem? Before Christmas an individual was asked to leave the company, his parting gift?... He stole all the software.
They knew this because he got a little drunk with a common friend of the manager over New Years and boasted he'd be starting his own company with the same software stack... We're talking about £4000 worth of software.
The machine the chap was working on (windows 7) was pretty locked down, he could not install, nor run a cloner, nor could he add a drive or boot from CD/USB or even get into the BIOS settings to take the software directly off as it was installed.
My friend, investigating, suspected that the chap had simply taken the serial numbers, the manager frankly denied this. His machine was checked, no-one had been accessing it other than him, there was no file sharing set up and it too could not be booted into anything other than the Windows 7 installation on the machine....
There was no-way, in the managements eyes, that the software could go missing... My friend suspected different... And so co-opted me to help, getting a copy of the disk I was not able to log-on, but I could see a whole bunch of scripts run at start up, whenever ANY user logged onto the system, they ran a series of scripts, one of which was a batch file (slaps forehead).
This batch file was stored as a regular file in a folder "C:\devscripts" and could be written too... I had a hunch this was where something could go wrong, but couldn't initially see how, the file looked unchanged... But then I noticed a hidden folder... a git repo metadata folder... in the same directory.... It seems the source of both this folder and the file was a git repo, so updates to the devscripts would be stored and commited to the git repo... and pulled to each machine every-reboot.
But the git-repo was open for ANYONE to commit to!
The developer had simply, within the massive cloud of commits, committed a new batch file to the repo. This new script started the python interpreter with the command line "-m http.server 8080 C:\Users\<manager>".
The development machines used port 8080 for the remote debugger, and let this connection start without warning the user that a new firewall rule was required.
The developer then simply used "wget --spider" to pull all the files from the managers desktop, this included a bunch of documents about staff performance and of course the serials folder in it's entirety.
Once he had all these files, just before the festive break and his departure he committed the original script again which removed the starting of python. He did this in the midst of the sprints to the break no-one noticed that their commit numbering had slipped by a place!
If he had reverted the repo he'd have needed the managers approval, but as it was the script just went from green to a yellow to a green against their sign off system, so no-one paid it any attention that the revisions had slipped in date & time. And that the sign-off system didn't treat the signature of the commit as being different was a bug in the system.
So the lessons to learn...
- Don't let batch files start as the root user on a machine, EVER!
- Don't update said files from a public or even open internal source
- Don't just ignore any subtle changes (like the commit number order changing) when you observe them!
No comments:
Post a Comment