Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Hacked

Status
Not open for further replies.

430s

Programmer
Nov 29, 2001
33
GB
I run a website using joomla and an sql database.
The site was subjected to an sql injection attack [Remote File Inclusion] that appears to have been successful. Initially it looked as if no harm had been done but, subsequently, it would appear that the database is corrupted.
I have the ip address of the attacker. It is a fixed ip address belonging to a 'dedicated' server. This server is owned by an isp who is renting dedicated access to the user.
If I go to this ip address I get a control panel log in page.
The owner of the ip address has another ip address, one digit different, which is 'his' website on the same server.
The 'his' is a commercial organisation with several sites and multiple PCs.
Is there a way to trace the PC responsible? [It may be possible to get physical access to any of the sites and remote access to the server].
Alternatively, to narrow the search, is it possible to identify the site?
 
This kind of thing understandably makes you angry. It is a violation and it makes me angry to even read about it. The best thing you can do, however, is make sure that your response is measured and on target. One of the worst things you can do is attempt to retaliate or engage in any sort of reverse surveillance.

Instead, here is what I would recommend:
Gather as much evidence as you can. Logs, times, dates, scans, etc. The purpose is two fold. One you will want this evidence so that you can take action against those that were responsible if at all possible. Two, you need to determine exactly how you were compromised so that you can correct the situation and prevent it from happening again.

With that in mind let me ask a bunch of question for you to begin your investigation with:
0) if you haven't yet, review the CERT intruder detection check list for your platform.
1) what type of system were you running, Linux, Window, Mac?
1A) what distribution or version?
1B) what revision or patch level
1C) what is the version and patch level of your web server, and content manager
1D) what other server applications do you have installed, e.g. what database and version.

2) what evidence do you have of the intrusion. Specifically, what do you have that you could use to show someone that the events in question actually took place.

3) How much, if anything have you done to this system since the incident. Note, the less, the better

4) If it isn't too late, put a firewall in front of the system or pull the network plug. Do as little as possible while you investigate.

5) how did you track the perpetrator. Document, but don't try to reverse-crack their system. Obtain the who-is and responsible party information.

If you have enough information, my advice would be to contact the authorities. Your ISP may be in a position to help you in this regard. In the process you will undoubtedly need their logs and assistance. What they have done is indeed a crime and is severely punishable. You need to handle it properly with documented proof, though.

 
Thanks for looking into this, here is a long reply:

0) if you haven't yet, review the CERT intruder detection check list for your platform.

I am using a host so I don't think I can get access to this

1) what type of system were you running, Linux, Window, Mac?1A)
The Operating system is linux

what distribution or version?1B) what revision or patch level1C)
what is the version and patch level of your web server, and content manager
Apache version 2.2.15
PHP version 5.2.13
MySQL version 5.0.91-community
[I got the above from Cpanel]


1D) what other server applications do you have installed, e.g. what database and version.
A second Joola install
Several static html sites [web pages]
A couple of other php applications [phpurl - two of these], a php helpdesk tool [osTicket]

2) what evidence do you have of the intrusion. Specifically, what do you have that you could use to show someone that the events in question actually took place.

Joomla has a number of plug-ins. One of these [Marco's interceptor warning] sends an email to me when it detects things like attempted sql injections. On this occasion, I received multiple emails indicating multiple attempts.

This is part of one of the emails:

** Local File Inclusion [GET:eek:ption] => /../../../../../../../../../../etc/passwd
** Local File Inclusion [REQUEST:eek:ption] => /../../../../../../../../../../etc/passwd
**PAGE / SERVER INFO
*REMOTE_ADDR :
xx.xxx.xxx.xx
*HTTP_USER_AGENT :
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20)
*REQUEST_METHOD :
GET
*QUERY_STRING :
Itemid=1&catid=1:latest-news&id=xxxx:title-of-article-theywere-targetting-&option=/../../../../../../../../../../etc/passwd&view=article


So far, all of these attempts have failed because, as advised by joomla, I have the latest version [1.5.22] and keep an eye on their list of problem extensions and plug-ins.
As usual, I banned the ip address of the culprit and, for the time being, forgot about it.
These attempted 'sql injections' are comparatively rare on this site because they usually come from china, russia etc. most of these countries are banned by another joomla plugin. Sites that are reported by Marco's interceptor are banned using CPanel Ip deny manager. The range of IPs are also banned - not just the IP itself.
It is only with hindsight that I have realized that problems on this joomla install and other problems with other sites on the server all started after this 'attack'.

3) How much, if anything have you done to this system since the incident. Note, the less, the better.

Although a lot has been done since the attack [march 2] in actual fact it is mostly just the addition of articles & photos to the affected joomla site.
However, again with hindsight, it was when using the joomla install function that things usually go badly. Firstly, the akeeba back up facility would not work saying that it could not find directories. In an attempt to fix this I upgraded Akeeba only to result in the site playing up and eventually crashing. I resorted to getting the host to use a back up to restore the site. Akeeba still would not work so I ignored it as the rest of the site seemed okay.
Subsequently, I was installing a search plug in and again things went wrong and the host had to use an even older back up to restore the site.
So, with hindsight, it is the joomla installer which seems to crash the site. However, the reason the installer is being used is because something is malfunctioning causing one to want to upgrade or remove a plugin or component.
The site at the moment seems to be fine but I believe that a fault will appear and things will get worse and worse. If an attempt to make repairs is done by eg removing a plug in or doing an sql db repair - this will result in losing the site.
If could do the equivalent of a system restore and use a back up I have from October 2010. But, because this is a news and information site, I would lose 6 months of news!

At present, I am barely touching the site to avoid it crashing and to see if I can spot a sequence of events that cause it to fail. Again, because it's a news site, this is leading to complaints that we're not running stories we've been given.

After it dawned on me when the troubles began I went to the raw access logs. Because we're still in march i got the info - up until now, we were not archiving the logs.

This was their first visit:
xxx.xxx.xxx.xx - - [02/Mar/2011:10:40:20 -0500] "GET index.php?option= HTTP/1.0" 404 1390 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.20)"
I don’t know what this indicates: index.php?option=
They then went on to do stuff like this:
xxx.xxx.xxx.xx - [02/Mar/2011:10:47:46 -0500] "GET /index.php?Itemid=1&catid=1:latest-news&id=/../../../../../../../../../../etc/passwd&option=com_content

After checking what they had done on the web [searching terms like used above] I believe they succeeded in a RFI or LFI injection.
But, I don't know exactly what they did [eg if they changed a file - what file did they change?]

4) If it isn't too late, put a firewall in front of the system or pull the network plug.
As this is a hosted server - I can't do that
What I have done is use a commercial plug in that claims to stop such attacks. The log for this plugin and the system’s log do not work [another problem?!]

Do as little as possible while you investigate.
Apart from the odd article and test this is what I'm doing

5) how did you track the perpetrator.
As above, This was gleaned from the warning details and the logs.
Using on-line tools such as ipwhois, reverse lookup etc I was amazed to find the perpetrator is in the same country as me, using a fixed ip. On the same dedicated server he has his own website. This is a commercial company providing news & info [the same as us but in another area].

Document, but don't try to reverse-crack their system.
-I would love to be able to reverse-crack their system

Obtain the who-is and responsible party information. If you have enough information, my advice would be to contact the authorities.
I have. One police department refused to act.
The second [where the attacker is] are 'looking into it'
I was hoping to be able to say to the police do x y and z when the other party says 'no we didn't do it']
The first police officer said ‘it could be a spoofed ip’. My feeling is that this is not the case.

Your ISP may be in a position to help you in this regard.
I don't think so – it would be the host who is only interested it providing the service

I have no way of saying whether the site is definitely damaged or not. Despite the work that has gone into the site, if it crashes again it will have to be abandoned.

Because of the nature of our site a mainstream broadcaster wants to cover the story but can't because the police are investigating.
I have been told that, if I run a story to the effect of 'this is why the site is going or has been damaged xxx did it'- they'll sue me.

ps I can send you our site url and the ip of the attacker if required
 
One things that I would suggest is to take a look at this thread: Joomla-compromise-thread It is a discussion about a situation that is similar to yours involving an investigation of a system using joomla that was compromised. You also mention cpanel, which has been involved in a few recent compromises, though mostly involving mail servers (especially exim). Here are some threads that might have some educational value in terms of dealing with these types of situations. cpanel-link-one and cpanel-link-two. My personal experience is that the forum I reference in those links is as good at Linux security, as tek-tips is in regards to windows security. It is good that you got the authorities involved, which is probably your best course of action. Hopefully something will come of this.

The URLs you listed definitely show attempts to use SQL injection and other vulnerabilities to gain user account information. That is what is up with all the ../.../etc/passwd parameters. I am not sure what they were trying to do with the circle.gif reference, but my guess would be that it is an attempt to get your site to grab and execute trojan horse code.

Apache revivision 2.2.15 is getting long in the tooth. 2.2.17 was released mid Oct of 2010 and I am not sure about 2.2.15. PHP 5.2.13 was released in Feb 2010. I am not even seeing a release date for PHP 5.0.91, with the oldest one I am seeing for download is 5.0.92. You might want to look for any security bulletins and review the change logs. There is a good chance you were hit by a known exploit from the older revisions. Here is a link to the cert checklist I mentioned. It contains the steps that you will want to engage in while performing your investigation. Most notably you will want to examine the output of the following:

Code:
netstat -pane, lsof -Pwn, and ps -axfwwwe
You should also look for any files with setuid and guid set. Be sure you look in places like /tmp, /proc, /dev, where bad guys like to hide their things. At this point, I don't think there is enough evidence to say whether or not you have a root level compromise or not. Caution should be the word of the day. Running an application like iftop might also show you evidence of active connectivity between your site and the perpetrator. This could help you gather evidence for the authorities.

I understand you would love to retaliate. As unfair is it is, doing so would most likely only get you in the cat-bird seat.





 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top