Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

I built a website from scratch using PHP and MySQL for my residential community and our budget is a big fat '0'.

Five days ago I discovered that there were 222 entries in a table in my database that looked suspicious. The I found another 196 entries in another table with similar entries. All these entries had been made within a 11 hour span.

Since then I have been breaking my head trying to 1. find ways of preventing such things from happening - basically trying to learn and convert my PHP to MySQLi (my host does not support PDO) and 2. trying to find out for sure whether this is an SQL injection attack. 3. the Apache log for the relevant day had a 4976Kb size whereas, all other days it is less than 50Kb 4. I have also taken a dump of one of the tables (222 records).

  • What I would like to know is, which of these is the first place to visit?
  • Do I study the logs first to try and find out what they got out of this exercise?
  • Do I study the table entries to find out how they did it?
  • Do I take down the site?
  • Do I flush my tables, change existing passwords etc? (luckily, since this site had not been 'launched', there is no data that I need to preserve - I can simply flush all tables!)

Searching on SE has given me a lot to think about especially http://serverfault.com/questions/218005/how-do-i-deal-with-a-compromised-server and RobM's answer made perfect sense.

I don't know the implications of what I see in my tables. Some of the entries are not displayed in the preview - obviously because it contains special characters. I'd have loved to be able to upload the excel dump of the table in question but that doesn't seem to be possible here...

I don't want to remove these entries before I can understand what they could mean and how much I am compromised. At the same time, I am not sure whether leaving them there can cause me further harm....

share|improve this question
1  
It would be interesting to actually have a sample of the entries :) –  Lucas Kauffman Jul 6 '13 at 7:25
    
I could do that but as some of it is in script language they get rejected by the tool. Is there a work around? –  vinaya Jul 6 '13 at 8:05
    
@vinaya You could base64 the data e.g. using base64encode.org –  Nick Jul 6 '13 at 21:07
    
I did that right after the last post and it looks as though it was a test run by nessus.org because one of the entries turned out to be a link to a text file from their website with some php code. When I copied the code and created a php page and then ran it, it brought up data about my website. I also found some string that when run through UTC-7 becomes a script tag...... Nessus is an outfit that provides network security solutions and I have seen one of their reports from 2012. ....Since both the tables that had these extra entries had the absolute same entries, I am hoping this was nessus! –  vinaya Jul 8 '13 at 6:56

2 Answers 2

up vote 3 down vote accepted

You might have been subjected to the process called "Fuzzing". This is when an attacker submits many inputs and perceives how your web application behaves. Web Fuzzing could include sql injection, XSS, overladed input or invalid input strings in general.

Well first you need to look at the entries.. Do they contain SQL commands? like SELECT, UPDATE, DELETE, INSERT
or sql operators, such as OR + - or many sql characters such as ' > < = "

If u see them, then it means that the hacker tried an SQL injection on your database.

If you see any html characters in your database, the attacker tried to execute stored XSS against you.

If the inputs are long, the attacker tried perhaps to DOS your website and bring it down. (Same is true if he submitted a lot of input in short time).

You need to observe the functionality of your site which accepted those values. If the entries/inputs didnt come from a specific functionality (e.g. registration form) than it was probably a hacking attempt.

Other types of injections that exit are LDAP, XML, Command and a few more that i cant remember. Look for characters that contain the following: % , > , ( , ) , ", ', dots , commas.

You can test it with mysql commands/operators: 1) LIKE '%searchStringGoesHere%' 2) MATCH AGAINST.

Panels like phpmyadmin, provides the same functionality but for people who dont know the sql language.

Alternatively, someone might have run some SEO bot on your site, and that was a spam attack, which is not much to do with security, but you could introduce captcha on your forms and tokens per each request to prevent a XSRF attack

share|improve this answer
    
Thanks, @BlackFire. Beyond my comment to Nick, once the panic subsided, I also saw that there were no sql language items, mostly what looked like script tags and some alert commands which were getting executed in the browser, a couple of what looked like hyperlinks that lead nowhere and one link to the nessus.org site. Nessus seems to be a provider of security solutions. I am hoping this was part of their usual exercise for their monthly vulnerability reports. I guess I am thankful that there was no action that damaged the database and also that it gave me a kick before a malicious attack! –  vinaya Jul 8 '13 at 7:36
    
@vinaya In that case, it is very likely the scanner was looking for persistent XSS vulnerabilities, not SQL injection vulnerabilities. If any of the injected alert function calls were being executed in your browser, then your web application is vulnerable to persistent XSS and should be audited immediately. If you like, you could check your HTTP server access logs to verify if it was Nessus.org scanning you, or a malicious attacker using the Nessus client. Either way, you need to fix your application. –  Anorov Jul 8 '13 at 11:44
    
Thanks @Anorov! I tried to look into the log but for that particular day, (and only that day) the log file is huge! I am also wondering about something else - I activated site scanner on my site that day. That scan is what seems to have created that massive log file. When I copied it into a word document it showed 1335 pages! At my wit's end trying to think of a way to figure out how to pin point the few hundred entry items in that huge file! Any ideas? –  vinaya Jul 8 '13 at 11:53
    
@vinaya If you view the log on the Linux server it's presumably running on, less logfilename.log + an in-file search for around the date and time you believe everything began would be your best bet. less doesn't load the entire file into memory at once, which makes it good for viewing and searching very large files. –  Anorov Jul 8 '13 at 11:56
    
@Anorov- After reading your first suggestion I tried out a simple search in the log file I had downloaded earlier and found NESSUS in that! But now I am even more confused! Here is one of the entries (identifying items changed) - 72.167.191.11 - - [28/Jun/2013:11:42:41 -0700] "GET abcd.in/~xyz/robots.txt HTTP/1.1" 404 503 "-" "Nessus" 0 "-" "/var/chroot/home/content/##/#######/html/.errordocs/404.html" 12629.... On a hunch, I tried a whois on the IP in the beginning of the entry. It turns out this belongs to my HOST! So does that mean the SiteScanner that my HOST ran was using Nessus client? –  vinaya Jul 8 '13 at 12:12

Do two things immediately. (1) walk through your code and make sure all inputs used to construct queries are quoted or otherwise re-interpreted rather than used directly to construct queries. If you have cases where that's hard to do, suck it up, there is no substitute. (2) centalize all your queries through a filter that logs ANY query that fails. This will likely tell you where (1) was unsuccessful.

share|improve this answer
    
Thanks @ddyer! I wish sucking it up was not the only solution! I learned php just to create this site and just when I thought I only needed to tweak some things before officially opening it up for our community, I discovered the data in the database and went ballistic! My next step, I guess is to understand what you meant when you said "queries are quoted or otherwise re-interpreted" and "centralize all your queries". ....I know! I Know NOW, I have taken on much more that I anticipated! But thanks for the pointer! –  vinaya Jul 8 '13 at 7:41

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.