Oh the Irony.... Email causes SQL injection in help desk ticket software

Forums › IT Pro and developers › Oh the Irony.... Email causes SQL injection in help desk ticket software

frankv

5680 posts

Uber Geek

Lifetime subscriber

#272001 5-Jun-2020 07:53

https://www.itnews.com.au/news/email-from-haveibeenpwned-wipes-helpdesk-tickets-548916

Recreational vehicle app developer QB8 LLC had signed up for the free HIBP messages to check for compromised accounts on its fyre.io domain.

When a message from HIBP arrived to QB8's helpdesk address after a recent data breach, it was automatically turned into a ticket in the company's tech support system, the open source
Gestionnaire Libre de Parc Informatique (GLPI) version 9.4.5.

The QB8 techs read the HIBP report, checked the data and alerted users to the breaches.

After that, the ticket was assigned to one particular technician, and marked as solved.

By assigning the ticket to a particular team member, the GLPI system parsed the ";--" characters in the header of the HBPI email, and interpreted it as a Structured Query Language database command that deleted data in the helpdesk system.

1 | 2

3816 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2498659 5-Jun-2020 07:58

Sounds like the SQL Injection vulnerability was already known prior to this incident and they had not patched their systems

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

freitasm

BDFL - Memuneh
79281 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2498661 5-Jun-2020 08:05

nztim:

Sounds like the SQL Injection vulnerability was already known prior to this incident and they had not patched their systems

Correct.

PolicyGuy

1727 posts

Uber Geek

ID Verified

Lifetime subscriber

#2498676 5-Jun-2020 08:54

freitasm:

nztim:

Sounds like the SQL Injection vulnerability was already known prior to this incident and they had not patched their systems

Correct.

Seems like a very good reason to put these developers on your "Do NOT buy or even use anything from these guys" list
You'd have to reckon the apps they develop are likely to reflect a, shall we say, less than optimally diligent attitude to security

freitasm

BDFL - Memuneh
79281 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2498679 5-Jun-2020 08:56

PolicyGuy:

Seems like a very good reason to put these developers on your "Do NOT buy or even use anything from these guys" list
You'd have to reckon the apps they develop are likely to reflect a, shall we say, less than optimally diligent attitude to security

It is an open source software. What happened to "open source is more secure because of many eyes"?

frankv

5680 posts

Uber Geek

Lifetime subscriber

#2498750 5-Jun-2020 09:27

freitasm:

PolicyGuy:

Seems like a very good reason to put these developers on your "Do NOT buy or even use anything from these guys" list
You'd have to reckon the apps they develop are likely to reflect a, shall we say, less than optimally diligent attitude to security

It is an open source software. What happened to "open source is more secure because of many eyes"?

I think he was referring to the software developed by QB8, not the software used by them.

nztim

3816 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2498754 5-Jun-2020 09:29

freitasm:

nztim:

Sounds like the SQL Injection vulnerability was already known prior to this incident and they had not patched their systems

Correct.

Sad to say it, but they got what they deserved - Also a good web application firewall will prevent SQL injection at the front end

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

freitasm

BDFL - Memuneh
79281 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2498770 5-Jun-2020 09:50

frankv:

freitasm:

It is an open source software. What happened to "open source is more secure because of many eyes"?

I think he was referring to the software developed by QB8, not the software used by them.

I can't see why QB8 would be penalised. They use a ticketing software that has a SQL vulnerability. They did not develop the software. They investigated and found the problem.

Unless the idea is that "if you can't even keep your ticketing system up-to-date, why would we buy your own software?"

Lenovo

Shop now for Lenovo laptops and other devices (affiliate link).

chevrolux

4962 posts

Uber Geek
Inactive user

#2498776 5-Jun-2020 09:58

I just dont get how this can still happen in 2020.

Like, really? No sanitisation at all?!?!?!

I feel like you're making work for yourself not using well known libraries that will just do this out of the box!!

BlakJak

1275 posts

Uber Geek

Trusted

#2498781 5-Jun-2020 10:03

I don't see the irony, i'll be honest.

No signature to see here, move along...

freitasm

BDFL - Memuneh
79281 posts

Uber Geek

Administrator

ID Verified

Trusted

Geekzone

Lifetime subscriber

#2498791 5-Jun-2020 10:11

BlakJak:

I don't see the irony, i'll be honest.

Me neither. The irony would be if these folks developed a security software and got their systems wiped out. As it is, just unfortunate (or reckless) they did not keep the ticketing platform up-to-date.

nztim

3816 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2498795 5-Jun-2020 10:15

freitasm:

Unless the idea is that "if you can't even keep your ticketing system up-to-date, why would we buy your own software?"

That would be my argument, especially if they knew that their ticketing system needed to be patched, also I question a lot of people run their web servers using SQL accounts with more permissions than required, the account used by the front webserver to access the database doesn't need permissions to drop tables (which I guess is what happened in this instance)

I think the front end should have two accounts, DB reader to read data from the DB, DB writer to write data back to the DB, neither account should have access to drop tables

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

frankv

5680 posts

Uber Geek

Lifetime subscriber

#2498820 5-Jun-2020 10:35

BlakJak:

I don't see the irony, i'll be honest.

I thought it was ironic that a system intended to improve security (HIBP) was what took down their system via a security flaw.

frankv

5680 posts

Uber Geek

Lifetime subscriber

#2498831 5-Jun-2020 10:44

nztim:

I question a lot of people run their web servers using SQL accounts with more permissions than required, the account used by the front webserver to access the database doesn't need permissions to drop tables (which I guess is what happened in this instance)

I think the front end should have two accounts, DB reader to read data from the DB, DB writer to write data back to the DB, neither account should have access to drop tables

My reading of it is that the intended SQL statement was something like

UPDATE table SET description TO ';-- ...' WHERE field = ';-- ...'

but what actually got executed was

UPDATE table SET description TO ';-- ...'

BlakJak

1275 posts

Uber Geek

Trusted

#2498914 5-Jun-2020 12:22

frankv:

BlakJak:

I don't see the irony, i'll be honest.

I thought it was ironic that a system intended to improve security (HIBP) was what took down their system via a security flaw.

HIBP sent an email. So do many, many other things. I think the link is tenuous at best, thus the lack of actual irony. Mauricio is right. :-)

No signature to see here, move along...

nztim

3816 posts

Uber Geek

ID Verified

Trusted

TEAMnetwork

Subscriber

#2499185 5-Jun-2020 16:54

frankv:

My reading of it is that the intended SQL statement was something like

UPDATE table SET description TO ';-- ...' WHERE field = ';-- ...'

but what actually got executed was

UPDATE table SET description TO ';-- ...'

I guess my question remains, why is the software frontend updating database tables? Surely it just needs to SELECT FROM or INSERT INTO ??

Any views expressed on these forums are my own and don't necessarily reflect those of my employer.

1 | 2