More subtle attackers might decide to corrupt or disrupt your data instead of (or as well as) stealing it. Instead of dropping SQL tables, attackers could inject queries of their own, thus learning not only the structure of your internal databases, but also extracting and stealing their juiciest parts. As shown above, the classic example of a SQL injection attack is large-scale data destruction. In other words, by the time you patched your own servers (or Progress patched its cloud service), crooks might already have injected rogue commands into your MOVEit SQL backend databases, with a range of possible outcomes:
#Sophos home utm management how to#
The bad news is that this vulnerability was a zero-day, meaning that Progress found out about it because the Bad Guys had already been exploiting it, rather than before they figured out how to do so. So, if you use the cloud version, you’re now automatically up-to-date, and if you are running MOVEit on your own network, we hope you’ve patched by now. The good news in this case is that Progress patched all its supported MOVEit versions, along with its cloud-based service, once it became aware of the vulnerability. The second is a “comment command” that causes the rest of the line to be ignored, thus cunningly eating up the trailing %' characters generated by the server’s command generator, which would otherwise have caused a syntax error and prevented the injected DROP TABLE command from working. The first extra command is the destructive DROP TABLE instruction. In fact, both these examples involve two injected commands, following the sneakily-inserted “close quote” character to finish off the search string early. You can see why this sort of trick is known as an injection attack: in the examples above, the malicious search terms cause an additional SQL command to be injected into the handling of the request. If you’ve ever heard syadmins or coders making jokes about Little Bobby Tables, that’s because this sort of SQL injection was immortalised in an XKCD cartoon back in 2007:Īs the cartoon concludes in the last frame, you really need to sanitise your database inputs, meaning that you need to take great care not to allow the person submitting the search term to control how the search command gets interpreted by the backend servers involved. …but you’ll be the last person to get anything useful out of the filesdb table, because your rogue search term will follow up the search with the SQL command to delete the whole table. You’ll get back a list of all filenames in the database table that end with the string duck (the special SQL character % at the start of a search term means “match anything up to this point”)…
SELECT filename FROM filesdb WHERE name LIKE '%duck' Sneakily, because everyting after - is discarded by SQL as a programmer’s comment, these three lines are the same as: SELECT filename FROM filesdb WHERE name LIKE '%duck' - matches names ending duckĭROP TABLE filesdb - deletes whole table SELECT filename FROM filesdb WHERE name LIKE '%duck' DROP TABLE filesdb -%'īecause a semicolon ( ) acts as a statement separator in SQL, this single-line command is actually the same as sending three consecutive commands: If that search term were blindly converted into a query string, you might be able to trick the web server into sending the SQL server a command like this: Of course, the web server needs to be really careful with the search text that it receives, in case a malicious user creates and requests a URL like this: The data that comes back from the query could then be formatted nicely, converted to HTML, and sent back as an HTTP reply to your browser, perhaps giving you a clickable list of matching files for you to download. SELECT filename FROM filesdb WHERE name LIKE '%duck%' The % characters added to the text duck mean that the search term can appear anywhere in the retrieved filename, and the single quote characters at each end are added as markers to denote a SQL text string: If the backend data is stored in a SQL database, the web server might convert that URL into a SQL command like the one shown below. The query text duck could then be extracted from the name parameter in the URL, converted into database query syntax, and stitched into a command to submit to the database server. Web-based SQL injection bugs arise when an HTTP request that’s submitted to a web server is converted insecurely into a query command that’s then issued by the server itself to do a database lookup in order to work out what HTTP reply to construct.įor example, a database search that’s triggered from a web page might end up as a URL requested by your browser that looks like this:
0 kommentar(er)
