Now, tell us, Troy
How long had you been waiting for this to happen?
Obligatory xkcd: you know which one...
A hapless IT bod found the Have I Been Pwned service (HIBP) answering its own question in a way he really didn’t want – after a breach report including a SQL string KO’d his company’s helpdesk ticket system. A pseudonymous blogger posting under the name Matt published a tortured account of what happened when a breach …
Does Troy know Joy? My first thoughts were the song by Harry Nilsson which could start as:
The other day, I got an email from Troy,
He said 'you've been pawned,
Don't be someone else's Troy boy,'
Well I went SQL and things were fixed,
Now every time I think of Troy,
It makes me sad
It makes me... sad
https://youtu.be/H7v_v7xbagY
Are you really in "Today's Ten Thousand" people who learn something that we thought "everyone" knew?
https://www.explainxkcd.com/wiki/index.php/327:_Exploits_of_a_Mom
https://www.explainxkcd.com/wiki/index.php/1053:_Ten_Thousand
(10000 is estimated from U.S. population and birth rate. In fact we should call it... 10000. Or how could we link to the comic?)
This post has been deleted by its author
Keeping the software up to date has been good practice for eons now. The only question is whether one should let most updates marinate for a couple of weeks to make sure there are regressions made. Of course those issues being actively exploited in the wild or are causing you grief for other reasons probably get updated more quickly.
No downvotes but maybe a dose of reality.
The path to upgrading software is rarely as smooth as it could be. Changes in licensing/maintenance costs causing your costs to spiral, cascading software dependencies for integrations or just vendors taking an age to release newer versions mean "running the latest version" quickly descends into supporting software ranging across 5-10 years. And then there's the appliances/IoT/IT systems that aren't IT's responsibility like security/BMS/SCADA systems. And I haven't even mentioned cuts to budgets...
Not that this appears to be the case in this instance - more a case of if it ain't broke, don't fix it until it gets pwned like a chess set with only one type of piece...
I mostly take the opinion that any software whose licence requires the exchange of money isn't worth paying for, especially those which rely on hellacious licensing manager servers in order to work.
Open source software is "standing on the shoulders of giants" put into practice, and we are all of us the better for it (and, yes, I do donate to my favourite OSS projects: just because it is free doesn't mean that it is not worth paying something for, if you can afford to).
I would say it is almost impossible for nearly everyone in a any reasonably sized organisation. I mean it's not just big software packages but firmware, drivers, packages, libraries, routers, switches, firewalls, wifi, controllers, system boards, iLOs, bioses, internal system webservers, third party maintained products, mobile devices, rarely connected laptops etc etc
Getting your main public facing systems takes time, energy, resources and disruption let alone everything else.
I'm just being a realist - running the very latest patches, software versions everywhere isn't easy despite understanding the risks and trying to mitigate them, even with quite advanced automated systems.
Yes, I was being trite. Yes, awful bugs make it into the best of software. Yes, even from people who should know better (looking at you, Invoke-SqlCmd). But when something so earth-shatteringly basic that it's the subject of an infamous 13-year-old xkcd and has infused IT pop culture to the point that it's inspired joke company names and vehicle registration plates makes it into production software, you should be doing your due diligence and wondering what other security nightmares have made it through their code reviews.
> So if it was written in Perl (Other languages are available) it would suddenly be immune from programming errors?
Maybe. Perl has a very useful taint mode whereby you have to explicitly 'untaint' values received from external sources else they cause compiler warnings.
Sure it's easy to overcome if you wish, but that's the point - you chose to override it and added code to do so.
To be fair, the problem is using a database API that requires a human-readable SQL command which your code has to construct so that the command interpreter can parse it back into the component parts you originally assembled. That's just asking for trouble and it's not really a PHP issue.
If you use PHP with Oracle, for example, you could at least use oci_bind_by_name
to assign values to named parameters in a template SQL command without having to worry about quoting and escaping.
And if PHP was anywhere near fit for purpose it would have a decent core API for database interaction that uses bind variables. An API that wasn't specific to each databases engine. Perl for all it's faults ay least has a decent de-facto standard DB API that has an abstraction layer above each database engine specific library.
Even worse, I get email from one company (I would name and shame them, but I can't actually remember which one it is) where the pain text part says "You are using an outdated email package. Please update to something more modern to read our emails".
The html emails contain nothing that couldn't be achieved with plain text.
"HTML has NO PLACE in email"
Of course not. When html email was "invented" about two decades ago, many folks pointed out that it was going to be a security nightmare. Sort of like teaching useful trades like gunsmithing, knife making and locksmithing to prison inmates. They were shouted down of course. HTML email is cute, possibly has a bit of utility in a few cases, and, what could possibly go wrong?
My concern is that in the broad scheme of things, HTML email is a minor contributor to the massive fragility of the "internet". We live in a world that is suffering severe economic dislocations from a disease pandemic that is really rather mild as such things go. I don't mean to trivialize COVID-19, but it's surely not going to, for example, wipe out half of humanity. But it's become a serious problem.
So, what is going to happen if/when electronic communications -- which we are becoming critically dependent upon -- collapses as a result of cyber-warfare, malicious activity, or the sheer mass of dubious design decisions like HTML email, Javascript, npm, etc? As far as I can see, there is no Plan A for dealing with such a contingency. Much less a Plan B.
Have a nice day folks. Party on!!!
HTML email isn't seemingly responsible in this case. While it might let you more easily hide some text, it won't make an SQL injection happen if it wouldn't already do so. If you can embed the string somewhere in text, something printing that string from a database is just as vulnerable to a dev mistake. That wouldn't be hard to do; just include it in something that doesn't get read: "For more information, consult our privacy policy at https://www.ourcompany.com/q/znof/meozv9enao30z0daf0wq8t8f'; select * from data; 'ambkz94p010av8zpfp8g4372j9". Since HTML isn't allowed, this link would have to be a text URL, so it would be a common sight by users.
HTML in email can have some downsides, but most of the most worrying ones are already prevented--you can't send a script in one and expect it to be executed, for example. Most mail clients don't load remote content from messages, while some mailservers instead immediately fetch it when the message is received and then rewrite the message to refer to the local and untracked cache. A lot of HTML can also just be annoying by enabling massive messages that we don't really need or providing a method for the annoying mail designers to play with weird formatting, but those are not security risks.
I have little attachment to HTML in email, but let's be honest about what we can really fix by dropping it.
"A lot of HTML can also just be annoying by enabling massive messages that we don't really need or providing a method for the annoying mail designers to play with weird formatting, but those are not security risks."
Arguably the opposite, since you can be fairly sure that the content isn't worth reading and, with a bit of training, your anti-spam filter can learn this too.
"enabling massive messages that we don't really need"
Such as the many, many lines of "legal disclaimer" added automatically to most business email address which get multiplied instead of stripped in the many replies in the chain.
I find the ones telling you to delete it if you received it in error particularly amusing since you don't even get to see the disclaimer until after you read and scrolled through the message itself. They probably have about as much legal authority as a shrink-wrapped EULA.
"HTML email" is just a file transfer protocol, like HTTP, together with a way of combining several such files in a single package, like TAR or ZIP. Run a sufficiently buggy client and you can have trouble with all of these.
Most normal human beings appreciate being able to properly format their communications, and include relevant non-text bits and bobs. When, for example, was the last time you received a letter in the post that looked like it had been banged out on an actual typewriter starting from blank paper? If you are happy to shut off 99% of the human race, by all means stick to plain text email. We are probably happier to be shut off from you.
If HTML email did not exist, someone would invent it and it would rapidly grow in popularity until only weirdos insisted on avoiding it. Oh wait, that's exactly what happened.
The basic premise is that each app or set of apps is run in its own VM that can be spun up or deleted as you would a portable installation or git branch - with all the security bonuses a VM brings.
So start the email app from your menu, and the window that opens is in its own VM (as denoted by a different colour title bar). You can run from a fresh snapshot every time (with settings saved), or allow persistence, or allow disk access to a shared folder to save attachments. Or Not, as preferred.
The Networking stack in Qubes is literally a pfsense VM, just to give you an idea of the flexibility available.
I don't think that anyone suggested that HIBP was at error. It would actually seem like Troy did this on purpose as a joke for systems that didn't sanitise their inputs or at least a little geeky joke for those receiving it.
The whole story seems to suggest the helpdesk software is at fault.
The very first paragraph in the linked article:
"I should say before we get started, the fault for this lies entirely with GLPI, I place no blame at the feet of haveibeenpwned.com or Troy Hunt for this issue. It’s all good fun! Concerning> Oh, for sure. You can’t help but laugh though. Obligatory XKCD."
I'm really quite glad that this ended so amicably and not with Troy being sued. It doesn't seem like it would be too unlikely in certain litigious areas of the world, and could potentially not end well given a judge without any technical knowledge and/or sense of humour.
I got around Office 365 removing .ps1 file attachments recently by changing the file extension to something alone the lines of ".not-a-virus nyet, definitely not a virus" followed by the first two lines of the Russian national anthem in Cyrillic. Worked fine.
logicalextreme,
"...by changing the file extension to something alone the lines of ".not-a-virus nyet, definitely not a virus" followed by the first two lines of the Russian national anthem in Cyrillic."
Товарищ, do you realise how many old 'Sleeper Agents' you have just woken up by that quoted sequence of characters!!!
:) ;)