Student requested access to research data. And waited. And waited. And then hacked to get root
- Reference: 1681716553
- News link: https://www.theregister.co.uk/2023/04/17/who_me/
- Source link:
This week meet a reader we’ll Regomize as “Wesley”, who 25 years ago was about to embark on a thesis in mechanical engineering, continuing the work done by a more senior student who was working towards his doctorate.
Wesley needed that student’s data to commence his own efforts, so politely asked for the relevant files and code.
[1]
The senior student readily agreed, but the days passed, and Wesley still didn’t have the data he needed. Repeated requests were ignored.
[2]
[3]
“I decided to take things to my hands,” Wesley told Who Me? “I had access to the workstation where the files were stored, and a little research on Altavista let me write a small script to gain root access.”
Not many minutes later Wesley had the senior student’s data and code and got cracking on his thesis thinking he’d committed the perfect crime.
[4]
Until a couple of days later when a visit to the lab to access the workstation was interrupted by a couple of PhD candidates who wanted a chat. And not a chat about mechanical engineering.
[5]Pager hack faxed things up properly, again, and again, and again
[6]Defunct comms link connected to nothing at a fire station – for 15 years
[7]Botched migration resulted in a great deal: One for the price of two
[8]IT phone home: How to run up a $20K bill in two days and get away with it by blaming Cisco
“They took me into an office, and they started the conversation by saying that they saw the logs and observed unauthorised root accesses to the workstation.”
“I confessed because what else was there to do? I told them that the other guy was not cooperating, and I did what I had to do.”
At this point the meeting became a little tense: the PhD candidates mentioned that the would be well within their rights to report Wesley’s actions to the department.
Wesley was saved when he mentioned the name of the senior student who’d been so slow to share data: it turned out one of the PhD candidates was a friend so was willing to let it slide.
[9]
But Wesley was given a terrible punishment: the job of defragging every PC in the lab, and few others for good measure.
“I spent the next week formatting and defragging Windows 98 hard disks.”
The pair of PhD candidates who bailed Wesley up were both awarded their doctorates, became professors, and are still in touch with Wesley.
“We meet sometimes and remember the good old days,” he told Who Me?
Have you been busted doing the wrong thing for the right reason? [10]Click here to confess your crimes and we will consider sentencing you to an anonymous appearance in a future instalment of Who Me? ®
Get our [11]Tech Resources
[1] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZD0Yvwxo0xOX4wLzBlSuCwAAAYQ&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZD0Yvwxo0xOX4wLzBlSuCwAAAYQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[3] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZD0Yvwxo0xOX4wLzBlSuCwAAAYQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZD0Yvwxo0xOX4wLzBlSuCwAAAYQ&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://www.theregister.com/2023/04/10/who_me/
[6] https://www.theregister.com/2023/04/03/who_me/
[7] https://www.theregister.com/2023/03/27/who_me/
[8] https://www.theregister.com/2023/03/20/it_phone_home_how_to/
[9] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZD0Yvwxo0xOX4wLzBlSuCwAAAYQ&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[10] mailto:whome@theregister.com
[11] https://whitepapers.theregister.com/
Not caught either...
Not busted as such, but I do remember seizing admin rights of a previous company laptop some years back. The frustration was that I was a contract IT engineer, so I had a customer laptop and an admin account that worked across their entire estate. If anything went wrong, I had the power to fix it. But for the laptop I had from my own company, no admin rights and everything heavily locked down.
Then one day my USB docking station stopped working with my company laptop - worked fine with other laptops so I knew the dock was physically OK. Of course I couldn't re-install the drivers from Lenovo's website as I didn't have the admin rights to do so, and trying to re-install them via the SCCM bundled version my company provided kept failing. So, I logged a ticket with our in-house support and many hours later after struggling to manipulate big spreadsheets on a little laptop screen, someone connected remotely, opened an elevated command prompt and ran a couple of commands before telling me to reboot the laptop in my own time and then ending the remote session.
At this point I noticed they'd left the elevated command prompt open, and 30 seconds later I'd used it to create a local admin account. One reboot later, the dock still didn't work and SCCM still wouldn't let me install the drivers for the dock correctly, but now I could at least use my local admin account to install the drivers direct from Lenovo's website and my docking station promptly burst back into life.
Yes, in hindsight it was a naughty thing to do, but I guess my frustration of being an IT support engineer who didn't have the rights to fix my own company laptop kind of grated on me. Anon for obvious reasons...
Re: Not caught either...
You didn't work for Wipro by any chance? They had an awful habit of locking their machines up so tight that you couldn't even run their compliance checker without admin rights... which, of course, you didn't have. So you didn't run it. Until you got the e-mail saying that your machine wasn't compliant which meant that you had to raise a support ticket.
And, of course, this support ticket was dealt with either during the UK night or the weekend and, as you hadn't replied (because you were - shock horror, not only not on-shift but were sleeping), - the support ticket was closed.
And then you got another e-mail telling you that your machine was non-compliant...
Not caught either... Or they never caught up with me
I once unintentionally created a security vulnerability in the lab website by creating a PHP webpage that allowed users to upload files into a subdirectory — for instance, upload an arbitrary PHP file that would then be executed on request, including executing bash commands. I realized the problem afterwards but didn't fix it, which came in handy later when I needed to grab a data file from my private directory once but couldn't get ssh to work for some reason; I was able to upload a PHP that would copy my file to the website and download it from there.
Re: Not caught either... Or they never caught up with me
Incase you aren't aware and if that website is publicly accessible and still live, anything that handles file uploads is potentially vulnerable to this if not handled correctly and dodgy people know that and will try to exploit it.
In Code We Trust
Anyone else remember this handy dandy bootable CD image? You could wipe out any Windows NT based OS admin password, do what you needed, then restore the password. Came in handy for semi-legitimate reasons (needing an app on a work PC that was locked down) but no doubt used by others for more nefarious means.
Unfortunately drive encryption being more or less "standard" these days has put paid to such skullduggery. But I do still have the ISO ... just in case.
Re: In Code We Trust
Yeah, we used something similar in one place before there was a sensible route to request admin rights, although it didn't reset the password back afterwards. Helped a lot for installing software we needed.
Then confused the deskstop support guy because the Administrator password he had didn't work on my PC while I feigned ignorance as to how that could have happened...
Re: In Code We Trust
Yep, I used it when I was at a site migrating PCs from the old company domain to our one (having purchased their company) and realised after the first reboot that I'd forgotten to change the local admin account password, and therefore couldn't log on to join to the new domain...
Re: In Code We Trust
Hirens Boot CD.
Still have v15 ‘just in case’. VERY useful for clients who had forgotten passwords
We used to hijack lab PCs running Windows NT by booting them on Windows 95 from a zip drive (remember those?)
Once Quake was running, you could unplug the drive and move to the next one.
An ancient NT4 workstation was still dotted around our office a few years ago. It was off network, but kept around because it had some useful applications on it.
Nobody could remember the passwords on it, however, being the IT bod; script kiddie tools for replacing NT4 passwords have been around for ages (thanks, SysInternals).
Obviously, using one of these keeps the "old" usernames intact. The boss was somewhat taken aback when I logged into this terminal using his user ID and my (replacement) password.
Not Caught...
Our OpSys project at Uni was carried out on a Unix box. With several student groups all vying to use it, plus lectures, etc. time on the system was precious. It didn't help that the operations people had blocked logins daily from 12:00-14:00, "In case we need to carry out updates or maintenance!"
Fortunately one of the PhD students was sympathetic having been in the same position the previous year, and conveniently had the su password which he let slip. That would bypass the block and then allow us to sudo login on our own user. This happened most lunchtimes for at least a month, the ops staff never did notice so their maintenance window was hardly essential.