Student hacks high school software and finds “SQL injections galore”
secalerts.co
secalerts.co
This made it possible to hijack other accounts, including our professors'. So we hacked our own grades and then reported it. Luckily we didn't suffer the same fate as Demirkapi.
Blog post here: https://bustbyte.no/blog/how-we-hacked-blackboard-and-change...
I posted it on the full disclosure mailing list, and IIRC they ignored it as far as I could tell. This was back in 2010.
(And before I get flak for not notifying them before disclosing it, I was a teenager and I wouldn't do it that way now)
I don't recall any sort of disclosure mailing list, and the only contact link I found seemingly went through my college's IT department. Whether my university had applied some customization, or whether it was just me being a young college student, I'm not sure.
Anyways, a few days after I had reported the vulnerability, I was summoned to a meeting where I found myself sitting at a table opposite my academic advisor, as well as the Department Chair of the CS department, where they began to speak to me about "academic integrity".
I'm glad the story mostly ends there, as during this meeting I realized what had actually happened; someone in the IT department had misinterpreted my report as some sort of hacking threat, and they had "tracked me down on the university network", which makes no sense because I had reported the vulnerability via email directly from my .edu address.
While I wasn't exactly well-liked among the professors in the CS department, the department chair at least recognized that it was a big misunderstanding, that I wasn't doing anything nefarious, and had been acting in good faith.
After that meeting, I had approximately zero interest in disclosing vulnerabilities of any sort, for fear of being on the hook if/when they were ever exploited.
fyi, your parent post referred to [1] here. Glad nothing too bad came of your disclosure.
Sales to a private broker is one alternative.
Also reminds me of a bug that was common in Adobe Reader that would create a very deep recursion of adobe folders in the users directory. You could not delete said files because the path was far too long. Had to use SUBST to map it to a shorter path then delete your way up.
For local businesses the second one probably sounds much more scary.
https://en.wikipedia.org/wiki/General_Data_Protection_Regula...
As an example, Cambridge Analytica was started in 2013 and was presumably a startup when it started doing public manipulation, so that's an example of whom I think has it coming if they get a company-bankrupting fine. Your mom and pop shop having a data breach due to a negligent SQL injection won't have to close up just because of that. I would be interested to hear a case where a company was fined to bankruptcy when they did not totally deserve it. Until then, I feel like reciting this over and over (people often bring it up in a negative context) is just spreading FUD about doing business in the EU.
But they absolutely haven't been fined to bancrupcy, just a few thousand Euro.
That's why I underscored the "up to".
250: Let strsql = "Update TbfFileManagementSystem Set FileName = replace(FileName,'" & Me![PONumber].OldValue & "','" & Me![PONumber] & "')" & _
" Where FileID = '" & strFileID & "';"
260: mdb.Execute (strsql)If the code you're starting with is already in such a state, the chances of the reviewer being:
1. able to understand what you've done
2. receptive to unnecessary functional changes to a legacy application
In some languages migrating to the prepared statement API can be a considerable amount of work and that takes a lot of time.
If the code is mainly made up of queries with an integer ID then you can make the code safe using guards with a fraction of the effort meaning that your software is stable faster. Then you can take your time rewriting your data access layer to use the safe-by-design APIs.
I should have made that clear in my original post :)
BTW at some point you might need to get into escaping / validation to support operations not supported by the safe APIs. If/when you encounter this it's a massive red flag. Your system design should reflect that. It should be treated like radioactive waste: be paranoid.
I've prioritised identifying and fixing these problems whenever I'm leading teams. It's an easy sell to management (spend a sprint to greatly lower risk) and a good training exercise for teams.
I do think it's reasonable to try and get third party software auditing to become more normalized, if a contractor is writing scheduling system to control class enrollment I'd appreciate another contractor looking it over... but even that has it's issues.
So then, "shady" sellers are pricing software solutions below cost, maybe there needs to be some standards around minimum time length warranties similar to manufacturer warranties. Somehow the refrigerator market managed to standardize onto requiring a certain minimum for each fridge - maybe we need a software association or union to do the same.
As a security consultant, I disagree. There is quite a clear trend in what kind of vulnerabilities web applications have. XSS is getting slightly better but still has a way to go, CSRF has much more awareness and went from "rarely prevented" to "usually prevented", SSRF is getting more common due to new kinds of architectures (more back-ends talking to each other), but SQL injections are, well, not quite a solved problem, but vastly better than it was ten years ago.
I think this can be attributed largely to better libraries that make the secure way the default (such as parameterized queries) and somewhat to more awareness (tutorials and examples will mention things like escaping variables). Perhaps people also hear more about it in school nowadays, but I don't think schools changed much.
My view of the world is somewhat tainted since companies pay me to find their bugs (they are serious about security), but I also am a normal user of random websites like everyone else. Some websites smell, and I'll investigate and sometimes find vulnerabilities. And I hear what is going on in the field, what leaks have happened, what bugs people are finding. I try not to let my paid work taint my view too much.
You could argue that the major source of insecure code these days is old answers on stackoverflow which show vulnerable examples. Though, i believe there was an initiative to go back and change old answers which posted vulnerable code but not sure if that ever took off.
Some URLS:
As you said SQL server, i literally googled microsoft ado.net example, first result is showing how to use parameterized queries: https://docs.microsoft.com/en-us/dotnet/framework/data/adone...
Googled the same with sql injection/security: huge article on it all https://social.technet.microsoft.com/wiki/contents/articles/...
As an (ex) security professional myself, i definitely agree with the guy above saying that these days in general you do see a lot less of the "schoolboy" vulnerabilities. Definitely still out there though, even in tier 1 public-facing websites of global banks, but certainly not widespread, and certainly not ubiquitous. I'd say this is due to a combination of hand-holding in frameworks, and better education all round.
Some ORMs are powerful and even have subsets of language for data transformation, and so on... And now you have even another problem: another layer of abstraction that might fail or have their own bugs and security issues.
I miss writing pure and simple SQL queries whenever I'm forced to use an ORM. This is one of the things I enjoy in the Go ecosystem: if you want SQL, probably go with database/sql and write SQL directly instead of any fancy ORMs out there.
Then, what happens next? They might end up hating SQL for no good reason and embracing the 'NoSQL' flag with any kind of non-relational database out there and make the very same mistakes they were complaining about SQL, only this time it'll be probably in JSON instead.
And they will probably notice earlier the errors and end up thinking SQL is harder and, say, whatever-NoSQL-brand is easy... only because they had more experience and a clear vision of everything when trying out the later.
I just wished more people would just keep things simple. For most common web applications out there a single SQL database suffices well, and you can do most, if not all, queries on two or three lines at most with no complex operations and keep things lean.
For sure, for search engine ElasticSearch is marvelous, and for keeping track of documents without ever losing data, Datomic is a robust and proven solution... but what I see is mostly people writing software for mom-and-pops shops using Mongo with no transaction support whatsoever.
As someone pointed out the other day, we do seem to be getting better about security -- less issues overall than there used to be. Likely a sign people are taking this seriously and frameworks have gotten better.
* Full Disclosure Mailing List || https://seclists.org/fulldisclosure/
Ultimately, a big issue with security is that nobody thinks of it as their job. "Oh cool, I made code my non-technical boss said was good enough! Time to clock out!" And that's really flawed. Security is everyone's job. Everyone. The best system is still susceptible to bad passwords. (=
What's security training look like in your org? Most likely there isn't any. So... pitch it. Here's a good template to get started:
* For Everyone - PagerDuty Security Training || https://sudo.pagerduty.com/for_everyone/
At various points, we had a shared file server for sharing movies and music for the whole school, bypassed the proxy (which also gave us a vastly improved connection speed), had Unreal Tournament 99 on the computers (this was ~2010, but it was one of the only games that would play well), we figured out how to send messages to all computers (using Novell Zenworks or something), and eventually a few of us just had full root access to the entire system. We also had lots of fun with fork bombs, setting peoples desktops to porn (we weren't meant to be able to change our desktop but there were workarounds), and the occasional broadcast storm.
If only we had known about bitcoin at the time, we'd have become rich running a mining network on the school computers.
Luckily, our school had a very relaxed attitude to our shenanigans. We generally avoided doing anything actively harmful and we also got a few free passes by helping the IT staff when they had problems (they were useless at their job).
The Novell messaging utility[0] thing? For us that was disabled in the registry. Unfortunately that was an easy fix. "Fun" times were had.
[0]: http://www.novell.com/documentation/linux_client/linuxclient...
My parents asked me point blank if I'd done and if I knew how to do it, or which I honestly replied no to both. That was when I got my first C++ book. My parents were like "if you got suspended for something you didnt do, you're sure as fuck going to learn how to do it."
Many teachers left the default password on their accounts. Was messing in the interface that I didn't understand very much and sent a broadcast message to the entire network. One by one they started beeping and displaying a blank message notification across all the computer labs in the school. Luckily I had some opsec at that age and didn't do it on the workstation I was assigned to. Logged out and quickly went back to my seat in the confusion that quickly spread in our class.
Wasn't till 2 years later that I got in trouble and got kicked off the computers for a month. For having a shareware game on the network. The network admin said something to the effect of "We are pretty certain you have done a lot of things far worse than this, but we can't pin any of them to you, so this is what you get punished for", and well, he was right.
In college, had to crack some passwords. Turns out all of the lab computers, the admin password of all NT lab Pcs was a 5 character building abbreviation + room number of where campus IT was based... I was expecting the crack to run overnight on my then 500 Mhz P3. The password was cracked before I could stand up to go to dinner. Last cracked passwords on my old XP laptop, that I couldn't remember the password to. Hard part is getting the unencrypted password file (since I think Win2k, Windows encrypts the SAM file on disk and exclusively locks the file while the OS is running), but if you can run something with system authority, you can inject a dll and extract the decrypted file. You still have to brute force the NTLM hashes after that, but on modern hardware, takes just a few mins. Back in the NT 4 days, at least the way our comouters were configured, nonadmins had write permissions to everything under c:\Windows. Easy way to get system? Replace the default screen saver with a copy of cmd.exe, then log out and wait for the logon screen saver to fire. Back in the day, screen savers ran as system. They dont any longer.
On the NT 4 boxes, I was able to script everything. Pop in a bootable floppy with the script and an NTFS driver, reboot, wait for the script to complete, having copied the SAM file, then reboot again and back to normal. Walk back to my dorm room, crack at will.
I reported it to the school first and got threatened with legal action. Reported it to the central IT department and a guy came and bought me lunch and yelled at our principal for not letting me report it.
Good times.
My highschool reported the incidents and I got caught in a few weeks. I almost went to trial, my hard drive with my StarCraftII campaign almost finished was confiscated (I haven't seen it again since that moment) and it was overall an instructing episode. It didn't go any further because my parents had good relations with the highschool's direction and they withdrawed the report as soon as they knew it was me.
In the following years I kept in contact with the webmaster and I remember feeling very encouraged to report any other flaw I could find to him. I found a few more things over the years, but most importantly learned a lot.
Every time I read news like this I remember how grateful I felt when my highschool not only forgave me but also helped me keep learning. I believe it can make a difference, and even more so when dealing with younger kids.
Keep vulnerabilities to your self.
When I was in high school a few of us grabbed passwords from unencrypted wifi/network protocols (maybe it was POP3 logins, I don't remember) and "reported" it with some harmless website defacing, telling the admin (who was a cool guy). Nothing happened and I don't think anyone ever even noticed.
I was nearly expelled from my high school for finding and immediately reporting a vulnerability, without having actually exploited it. Also my story is far too common. Most of the people in charge don't know anything!
Many of us in the industry who have been around the block a few times support either selling your exploits or open disclosure. We have our reasons.
This even extends into victimless[1] hacktivism. (@see Aaron Swartz)
1. This is my opinion, not a declaration of fact.
My brother had a classmate who ended up being subject to pretty intense investigation for something similar, mostly because the IT guy was incompetent and characterized a problem in a certain way. He wasn't charged, but it cost his family a bunch of money.
I would advise anyone to never volunteer anything of a infosec nature in a public school environment.
For some reason, all students had access to the admin file systems - and for some other reason, the IT people had usernames and passwords stored like that. Either way, he reported the findings to the school admin.
What did the school do? Press charges. Police came knocking on his door, and confiscated his computer.
Or, just keep doing what they've been doing.
Seems like a pretty obvious choice, even if it doesn't feel "right"
The other alternative is open source. Lower the initial cost of entry, amortize the cost of maintaining and enhancing core components, and let vendors compete on the basis of what they can offer on top of that. Unfortunately, this approach yields much lower margins than what "vertical" software vendors are used to, so they'll fight any such thing tooth and nail. That gets us into the domain of trusts, cartels, and regulatory capture. The business factors preclude technical solutions, and users pay the price. :(
When I was in school, there was a vulnerability where you could reach courses that you didn't belong to, simply by changing the id in the URL. A couple of students got punished (banned from school computers for months) for exploiting this (to leave a message on said courses). As of a year later, the vulnerability was still not fixed (although the messaging infrastructure was disabled).
Security on the old Macs was hilarious though - the student user accounts had a limited set of applications they were allowed to launch, but it was only enforced via Finder checking when you double clicked it.
There were so many other ways to launch things. Custom buttons in AppleWorks toolbars, AppleScript, dragging it into Safari and then opening it from the downloads manager, and setting the creator code to match any application you had permission for were convenient options.
Don't have access to run Script Editor? That's ok, type applescript: into Safari's URL bar and it'll pop right up.
My family made a fuss when they wanted to expel me and I switched over to Electronics. Had a grand time.
after that i think either the CDC or l0phtcrack or one of those groups posted a way you can get to the user/groups window with admin privledges. i did that on one of the library computers which was logged in with the library account and deleted the admin group. what a shit storm that was. i was never caught for that one thank goodness.
i was a terrible script kiddie!
We often shared our computer lab with others, so whenever they came into the room we'd shut the computer down and watch them get confused, move to another PC and we'd shut that down too.
They apparently missed that another group had already created their own domain admin account, and didn't notice that until some weeks after the net send incident (I think it lead to them paying closer attention for anything unusual happening). I do think they brought it on themselves to some extent - having a domain admin password of "school" (easily shoulder-surfed), later "<name of school with an o replaced with a 0>7" (ophcrack made short work of that one, using cached credentials), and a VNC password of "vnc" (server installed on every machine in the school), is asking for trouble.
Fortunately they weren't malicious, just curious (the most "damage" they did was changing a single pixel in the desktop background of all users to see if it was possible) - they even slipped a note under the IT Admin's door with the current domain admin password on it, but apparently they either didn't see it or didn't act on it. Given they had write access to every user's network drive, it could have been far worse. It ended up being a lesson in OPSEC as well - getting logged on a rogue domain admin account using a device called "<family name> USB" is a bit of a red flag.
I think the punishment was pretty fair though (despite some initial ranting from senior leadership about suspensions and getting the police involved - cooler heads from the deputy leadership and IT technicians prevailed) - helping the IT technicians out for a week, which amounted to cataloguing hardware (chasing down services tags), and re-wiring a couple of the computer rooms.
Were they only viewing material? Students viewing (and perhaps learning from) extra material should be commended! :)
Well, after a software update, nobody noticed that the permissions system for the TV was disabled. So I come along, a few weeks/months/? later and make an ad for Math Club, and it went live immediately. No Student Life approval.
Of course, this isn't a glamorous bug. Briefly thought, "Man, if I was a bad guy, I'd totally post some really _shocking_ material." I wasn't a bad guy though, told Student Life, and they fixed it.
EDIT: There is a shared account detailed in the Club manual on how to create a TV ad (for context).
https://www.vice.com/en_us/article/59nzjz/teen-security-rese...
This article has more details about the reasons Demirkapi was suspended. Apparently he first tried to contact Follett (the software maker) directly, but they ignored him. He then tried to use the software itself to send a message Follett, but the message was instead broadcast to a large number of parents, teachers, and administrators across the district. This does seem pretty irresponsible, and Demirkapi said he understood the reason for his suspension.
Thus, this doesn't seem like the usual "person reports vulnerability and is punished for it" story.
Of course the ultimate responsibility lies with the software makers who have these vulnerabilities in their software and who don't respond when someone reports them.
I've reported vulns in school before and got an unexpected bug bounty. I also abused vulns to put games on a school server when I was younger and that time I got a firm talking to. I also know someone and their friend who were around 18 at the time and stole a teacher's password (don't remember how, but nothing clever) and changed some grades of theirs. They were indeed suspended.
I bet most schools are in a similar situation. Lack of a proper budget, cheaply made software sold by shady vendors, IT staff that isn't properly trained, etc.
Taking about manipulating the URL parameters... yeah, I used that trick to apply discount codes way back in the day. The web form wouldn't accept them, but if you bolted them on to the URL after that step in the checkout process, they'd blindly get applied to your cart anyway. Found one for like 95% off a CD, and used it on a laptop at BestBuy. 15 year-old me thought he was really smart, but mostly he was just a vandal and a thief.
Best line:
> "Don't fall for marketing. Just because (vendors) say they take care of data doesn't mean they do."
I got off with some stupid fine and my online access being locked for 30 days. Was pretty annoying though, because they counted the 30 days only during when school was in semester. I happened to be doing this the final day of the semester... so that 30 days ended up being a lot longer.