Rasputin whips out large intimidating tool, penetrates uni, city, govt databases – new claim A Russian-speaking miscreant dubbed "Rasputin," who potentially hacked into the US Election Assistance Commission and sold access to its systems, has struck again, it is claimed. Rasputin has allegedly infiltrated database servers within 60 organizations, US government agencies, and international universities. These victims …
I contacted my MP to ask them for ways I can get my medical records removed from the NHS systems.
I have to contact each GP practice I have ever used, but so far there is no way I can remove any records for Hospital treatments, like scans or Xrays.
Coupled with the UK Govt via one of the NHS trusts paying Google to take our data for "AI" analysis when Google would have taken it for free anyway as thats what they do, I think the public should be aware what all these centralised databases the Govt run are doing with your data.
Do you want your kids school reports to be posted online helping to make them become a future playground bully target via a twisted tech savvy parent with prejudices that we all secretly harbour?
Either GCHQ know what they are doing but are playing dumb making Parker @ MI5 red in the face with all the russian hacking meme sweeping the news or we have some expert bullshitters in dangerous positions of power trying to get the security standards raised by pointing the finger at the Russians.
In the mean time....
Привет Я русским языком негодяй
Not sure why you have been in "touch" with so many GP practices, or why you would want to get your records removed, but that's neither here or there.
With your obvious skills at penetration you could probably find some means of entry and cause these practices to DROP their TABLES, perhaps after a nice JOIN to SELECT their PRIMARY KEYS.
It wouldn't surprise me a'tall to believe that some subtle use of UTF-32 lubricant could let your magic wand slip through rather painlessly.
"This well-established but easy-to-remediate problem continues to vex....
...the lazy, fuckwitted, and incompetent. Like TalkTalk.
Field validation is soooooooo basic, so fundamental, it should be a crime to not do this properly. I was designing and coding systems that did this back in 1987, three decades ago, it wasn't rocket science then.
Whilst I agree with your sentiments it's a lot different these days with the multiple vectors that connect to your database that you may not even have control of (think multinational or large company with multiple IT departments). There is also code auditing, you may know how to do it but there may also be someone writing modules who is a bit green in the grass, who audits them and how do you know the auditor knows what to look for? Searching for sql injections bugs I would assume would be a huge task of auditing what could be thousands of lines of code, think app/web/internal web/whatever other smart arse connection some of has thought you need.
A chain is only as strong as it's weakest link.
Obligatory xkcd.
https://xkcd.com/327/
Spot on in the article but to further the point, until the outcome of not securing your database costs more than employing staff to make sure it doesn't happen nothing will change. What is the cost of the outcome? Lost customers depends on whether people care about their data which clearly a lot of people don't (TalkTalk) and the fines are a joke. When data is used nefariously en masse things may start to change but I am not holding my breath.
I work as a security auditor, recently worked on a major Insurance company, during an interview with the Database guy, I asked about data leaks, especially since they were dealing with PCI and HIPAA data (And several other regulations). Their policy is to just pay the fine and not fix anything, because fixing would be too costly.
Their company is also set up in that insurance policies are technically owned by independent local groups (Technically the owners of the policies) and managed by regional authorities (who own the actual data itself) that are subsidiaries of the main company. Whenever a regional authority screws up badly enough to get shut down, the main company dissolves the regional authority, builds out a new one, and since the parent technically owns all the regional subsidiaries' assets and employs all its people, they just transfer everything to the new one (The buildings, equipment, etc is all leased to regional by the parents and the employees are contracted out to the regional), the local groups then refile under the new regional subsidiary. Everything then just continues one as if nothing had happened.
They get away with a lot of this because they are privately owned and their brand is over 100 years old and is close to being a generonym, so they don't really care about the brand damage from a subsidiary failing.
yes, Universities are named but if its like past/previous victims, its likely that what they have access to are random departmental boxes run by post grads or such as tests/experiments with random junk on them and not secured - hence why they have remote access to the SQL daemon and/or web site allowing such injection.
Uni networks are, by and large, playgrounds of many many targets and broken systems - a place where many GOOD and BAD people cut their teeth and learn IT/security.
they are also places of research and discovery - without them being so open and accessible, the Internet would never have started in the first place (most of the first important/visited 100 web sites were on someones research workstation that was supposed to be doing other things)
so long as the serious business corporate side and important (confidential/export controlled/personal etc) research stuff is isolated and secured, this is no bad thing
(almost no commercial companies can operate in this mixed way)
IIRC that was the espoused as best practice, and still may well be, but I think there are ways round the use of functions and SPs by injecting SQL code into parameters.
If the function or SP isn't well written and is expected to return a table, if data put into the table or the SP/function isn't scrubbed or validated, I suspect someone could get round it and return a more comprehensive table using --/r/n'UNION ALL SELECT * FROM USERS' etc..
Note - I am neither SQL DBA, App Dev nor Hacker so smarter minds feel free to correct.
Secondary note - from experience I will almost guarantee that no matter what you try and do some user (legitimate user) will try to copy-paste code breaking garbage into an input field and will break something. Not maliciously, just because they want to copy the field exactly as it is, and if it is in middle-kingdom hieroglyphic mirror-writing so be it.
Can you allow only functions/stored procedures the only access for the web application account to prevent this or is it much more complicated than this?
Depending on the database engine, yes, you can limit access to functions/stored procedures.
But if those functions/stored procedures simply repeat the mistake of concatenating user input into commands without sanitizing, then you still have the same injection vulnerability.
You have to either sanitize the inputs completely (which can be quite hard) or completely isolate them from the code, never concatenating them into a string with the actual code. You can do that in any acceptable application stack, yet SQL Injection remains incredibly common. It's almost as if web app developers are incentivized to develop code quickly and security is the last thing on anyone's mind...
But never fear. I hear those web app developers have moved on to IoT....
Yes you can. But then someone may have gone and written a bad proc that allows for 'dynamic' execution... ie creates an executable statement from the inputs.
But then again, if the coders construct their calls to that procedure incorrectly then it makes no difference how well written the procedure is.
Even in places where they go out of their way to hire a DB team to do the 'database coding' the boundaries still typically leave the .net or whatever layer outside the DB team scope, with a bunch of coders who seem to think sql injection means putting data into a database.
Did they really, or was it more like a twig or a leaf ....
its only fines of the GDPR size 2-5% of turnover or CEO jail time that make a big enough stick.
how hard is it to parse a text input for control characters and wildcards, and escape or remove them?
a quick string search routine and all done.
Or do what my company did, all input is encoded in Base64 before getting put into an SQL query, the data in the DB itself is also base64 encoded. We did it to solve all kinds of problems. If you want your username to be "Robert'); DROP TABLE Students;--", go for it, all the query is going to see is "Um9iZXJ0Jyk7IERST1AgVEFCTEUgU3R1ZGVudHM7LS0=". We did this as part of an internationalization project so we can support other character sets, unusual names, or just other cultural oddities, the fact that it protects against SQL injection is just gravy.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
