[OPLINTECH] Additional Info on the recent website server attack

[Bob Neeper]

Looking at the log file it seems to have been an SQL Injection attack.
This type attack breezes through a firewall as it comes in direct to 
your website on port 80.
Some prevention seems to require due diligence in your coding.

Our quick fix was to change permissions in mysql to slow them down a bit
   Database         Privileges    Grant    Table-specific privileges    
Action
   DB23              SELECT     No       No

Yesterday's attack started with this string arriving.  The xxx has been 
changed, as it shows which file on our server was used.
As it seemed to go direct, they were in before, possibly using a 
different IP.
67.205.102.196 - - [08/Feb/2010:12:12:34 -0500] "GET 
/xxx/xxx.php?id=1+union+select+version(),2+from+mysql.user+--+ HTTP/1.1" 
200 6055 "-" "Opera/9.80 (Windows NT 5.1; U; ru) Presto/2.2.15 
Version/10.10"

That string returned one of our web pages with our mysql version displayed.

This attack was not dedicated to us but rather a general attack to see 
what it could find.
Some strings looked for logs, config files etc. by checking common 
locations.

By locating logs, a dedicated attack could then easily rewrite them to 
hide the tracks.
It didn't get our logs (this time) as we use different names.
Some examples:
/apache2/logs/access.log
/usr/local/apache/logs/error_log
/usr/local/apache2/logs/access_log
/var/log/httpd/access_log
/Volumes/Macintosh_HD1/opt/apache/conf/httpd.conf
/etc/firewall.conf
/etc/ssh/sshd_config

To prove a file could be written on our server through our website, I 
googled for a while.
Google is your friend!
Then built this string which actually could (it won't now) create  file 
c.php on our server.
http://community.lib.oh.us/xxx/xxx.php?id=1+union+select"<? 
system($_REQUEST['cmd']); ?>",2 INTO OUTFILE "/var/tmp/c.php" --

Our server is virtual and we have a 11/9/9 copy so everything would not 
have been lost.
And to further lock this particular barn door, today, we have a current 
export of mysql data.

Future plans have been a second virtual server and moving over in-house 
blogs, wiki's etc. from the main website server.
And possibly even configuring VMware to restore a snapshot of the 
website server on demand.

As is, our current network configuration by Level 9 Networks will limit 
damage to an individual server.
An outside attack should never see, let alone reach our file server, or 
internal PC's.
And it should even be really slowed down trying for the circulation server.
(But then again, nothing is really ever 100%)


So you may be paranoid, but are you paranoid enough ?    Bob

R. W. (Bob) Neeper     Cell: (740)-407-3572 
Community Library
44 Burrer Dr.
Sunbury, Oh 43074
Tel:  (740)-965-3901



Bob Neeper wrote:
> An FYI
>
> Yesterday we noticed our website server was subject to at least an hour 
> of a scripted attack of about 7000 messages.
> It APPEARED to be from an IP in Canada by someone using
>    User agent identification Opera/9.80 (Windows NT 5.1; U; ru
>    U for strong security and  ru for probably Russia
>
> It resulted in:
> Almost a denial of service, as the server CPU was close to 100% at times
> Up to 784 emails sent back to us using our fill in form.
>
> PHP and or mysql query's seemed to be part of the attack and they were 
> able to get some information from the server.
> A few attempts were made but nothing seems to have been added to the server.
>
> No financial or patron information is on this server.
>
> Due to the network setup by Level 9 Networks there was only very minimal 
> internal disruption.
>
>
>