1

One potential client gave me access to his FTP last night to check a small web software to see if I can perform the changes he wants and I found the following line in the code

$query = mysql_query("SELECT * FROM request WHERE MD5(CONCAT(id, code)) = '{$_GET['r']}' LIMIT 1");

I read in this question that mysql_query doesn't support multi queries, so that's the reason why I wasn't able to erase one test-table I created myself.

I did manage to use the old trick ' or 1 = 1 -- but the software interface is designed to list only 1 result of the query, which means I can't get my hands on all the data. But on this subject, the application is a small web software that processes requests.

  • You get a link
  • You click on Pay now
  • You pay your debt in another website
  • You return to the website
  • You get a receipt email.

The application doesn't hold sensitivity data, doesn't matter if you can find and load other people's request because you're not willing to pay their bills and there's nothing else you can do. No password involved, no credit card involvement, nothing. Nothing you can steal from the database matters.

The question is

In this case, do I have anything to support the allegations that inputting your data directly into the SQL is unsafe? Is there any way around to delete or update (update in a matter of corrupting) the data using SQL Injection so I can prove that it's actually unsafe? Or otherwise we have to admit that under the circumstances the software is safe enough?

The question is design to help me decide whether I should report back explaining that the client should pay someone to fix all the SQL Injections vulnerabilities. But if it's not broken, he won't be paying to fix it and apparently I can't prove that it's broken.

Edit 1:

In answering to @James on comments, the website doesn't handle all your bills, just your bills with the specific client. For the sake of argument we can safely assume that nobody is going to be paying to fix only select vulnerabilities because indeed you won't find any customer of theirs worried about their bills getting out.

Community
  • 1
  • 1
Marco Aurélio Deleu
  • 4,279
  • 4
  • 35
  • 63
  • Does that code run it seems to have several bugs in it? – Joshua Byer Apr 09 '15 at 12:35
  • 1
    "*doesn't matter if you can find and load other people's request because you're not willing to pay their bills*" you don't consider other people's debts or bills "sensitive" data? Would you be happy your debt/bill information being publicly available? – James Apr 09 '15 at 12:35
  • 2
    What about an injection that over-performs and hijacks CPU, effectively a DOS attack. – ʰᵈˑ Apr 09 '15 at 12:35
  • '{$_GET['r']}' should be '{$_GET[r]}' or it won't work 80 - 90 % sure – Joshua Byer Apr 09 '15 at 12:37
  • You should never ever ignore vulnerabilities. – Jacob Apr 09 '15 at 12:37
  • @Joshua `"{$_GET['r']}"` works just fine. – deceze Apr 09 '15 at 12:38
  • @James I edited the main question. The data in question is not really much of a treat to the public knowledge. – Marco Aurélio Deleu Apr 09 '15 at 12:40
  • 3
    This is 2015. Prepare your statements. – Joost Apr 09 '15 at 12:40
  • 2
    TBH I don't care what bill or information it is - it's not up to *you* to decide if *I* want my info to be available to others or not. (obviously not including obvious public data such as posting on twitter etc) – James Apr 09 '15 at 12:43
  • @Joost like I said in the question, it's an app not developed by me. I always listened to the dangerous of SQL Injection and have been always prepared, but it's not my fault other people do it and if there's nobody to pay to fix it, it will never get fixed. Life goes on. – Marco Aurélio Deleu Apr 09 '15 at 12:43
  • @James I understand that in theory James, but in practice let's just assume in this case that if I go only with that to the client, he won't approve the fixes in SQL Injection. Let's assume he doesn't care that your data can be retrieved. – Marco Aurélio Deleu Apr 09 '15 at 12:45
  • @James now you're not really being fair with me, right? I do have bills to pay and this project is a hell of a billable hour since nobody wants to "maintain" PHP 4 projects anymore. If I can make in 10 days what I don't make in 2 months, should I be picky that the client doesn't care about exposure? Not to mention the fact that about 8 developer friends of mine that saw the project agreed with me that it really doesn't matter the data you can extract because it's useless data. – Marco Aurélio Deleu Apr 09 '15 at 12:55
  • 1
    @MarcoAurélioDeleu Does the program have other points of entry? You told us about the retrieval of data, but when the visitor returns are they carrying information for an update to say the bill was paid? Does the payment gateway do that directly (ie. silent post)? Or are there any other entry points (visitor facing or not) that can be accessed to perform any level of update of delete? If so, then the ability to discover what those weaknesses are will be available through this vector and they can exploit through another. – BA_Webimax Apr 09 '15 at 13:04
  • @BA_Webimax It's like the app is just a "Click here to pay" layer. It's all handled in a safe website and after payment, a 3rd system connects to this database and checks the request as "paid" (a Ruby on Rails system). So in reality, the App is just to give you a "Pay" button, a "Processing status" and a "Paid" green light. – Marco Aurélio Deleu Apr 09 '15 at 13:10
  • @MarcoAurélioDeleu Do the bills get entered into the system through a PHP or Rails interface using that database? Is there an administrative dashboard (or similar)? I ask because if there are some sort of user credentials in the database (even in a different table) that allow someone to login and maintain the system, they can be retrieved through the SQL Injection hole you have already found. It may not be trivial to exploit and may take a lot of probing to ultimately get in, but if there are credentials in there, someone with time to kill could do it. – BA_Webimax Apr 09 '15 at 13:25
  • @BA_Webimax I checked for that. The Dashboard is in Rails and it only generates "requests" in this separated database so this PHP code can list it. The server holding this PHP script has only 1 database with only a handful of tables only linked to the request (child tables). – Marco Aurélio Deleu Apr 09 '15 at 13:27
  • Honestly, how large is this application? The time spent deliberating whether to fix this or not could have been spent on a `grep mysql_query` – Joost Apr 10 '15 at 09:00
  • 1
    @Joost The application is fairly small, but like any PHP 4 structured application, there's tons and tons of mysql_query executing SQL with direct input. It's not hard to fix, but pretty boring. I estimate 100 files with at least 5~10 queries each, not to mention the number of variables being used without proper treatment. I would rather spend time discussing and building knowledge on the matter than fixing it for free. I love science. – Marco Aurélio Deleu Apr 10 '15 at 19:22
  • Right, 500 to 1000 queries is way more than I expected. I agree completely with your comment. – Joost Apr 10 '15 at 19:24

2 Answers2

4

You are able to alter the structure and meaning of the query; you are able to add or remove conditions etc. from it and generally make it behave in ways the author did not intend. This is a security issue no matter how you look at it. You may not be able to find an adhoc exploit for it, but it can give someone a leg up in some way or another that nobody anticipates right now. For example, it can be used to probe the database for the existence of data or tables and columns. That alone can give an attacker additional information to formulate a more specific attack elsewhere.

deceze
  • 510,633
  • 85
  • 743
  • 889
4

Yes this is a security risk.

For example, 

$_GET['r'] = "1 AND code LIKE '%_[^!_%/%a?F%_D)_(F%)_%([)({}%){()}£$&N%_)$*£()$*R"_)][%](%[x])%a][$*"£$-9]_%'";

And we have a wildcard attack.

SQL Wildcard Attacks are about forcing the underlying database to carry out CPU-intensive queries by using several wildcards. This vulnerability generally exists in search functionalities of web applications. Successful exploitation of this attack will cause Denial of Service.

Beyond that, an attacker can manipulate $_GET['r'] to find out more on your database, such as other tables, columns, and even databases - which is a huge security vulnerability in itself.

ʰᵈˑ
  • 11,279
  • 3
  • 26
  • 49
  • I'll be asking permission to test this during the night, if it works it will be reason enough to fix. On the database matter, like I said in the question, retrieving data won't matter at all. – Marco Aurélio Deleu Apr 09 '15 at 12:42
  • @MarcoAurélioDeleu Why not grab a copy of the site and test away from live? Then you can hammer it to death in all ways without it being a problem to anyone – James Apr 09 '15 at 12:44
  • 2
    @MarcoAurélioDeleu "retrieving data won't matter at all". It will. If an attacker knows your database design (tables, columns, databases) he can then use this knowledge on other attacks, or even probe them for data. If you did not intend for someone see some data (ie: data linked to another account), this is a security risk. – ʰᵈˑ Apr 09 '15 at 12:44
  • @James because the client in question will argue that it is not unsafe until I prove otherwise in his own website environment. Unless I show a table being dropped, a record being altered or the server going down, life will move on. Apparently, this is running since 2008 and no problems have arried. – Marco Aurélio Deleu Apr 09 '15 at 12:49
  • 1
    Just curious, but did you manage to test this @MarcoAurélioDeleu - if so, did you see the effects? – ʰᵈˑ Apr 10 '15 at 07:38
  • @ʰᵈˑnot tested yet, I'm still awaiting permission. Although I feel like since anyone could do it, so can I. Problem is, you can't ask permission to DoS a live server and then do it anyway, it will be pretty suspicious. I do plan on testing this. – Marco Aurélio Deleu Apr 10 '15 at 19:20