Date: Mon, 5 Dec 2011 20:21:42 +0000
From: Dan Ballance <tzewang.dorje@...il.com>
To: Gage Bystrom <themadichib0d@...il.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: one of my servers has been compromized

Thanks for that. I've learnt a lot from this thread. Peace to you all.

On 5 December 2011 20:11, Gage Bystrom <themadichib0d@...il.com> wrote:

> Tripwire is awesome for many reasons. The original use of rootkit
> detection is no longer one of them. It was used back when userland rootkits
> were big, it has zero effect on kernel rootkits. That being said you can
> use it to watch other critical files for improper access. Keep tabs on your
> cron files, configs, and your web pages(why crack password hashes when you
> can force the login script to hand deliver the plaintext?), etc.
>
> Afaik, rootkit detection has made practically no progress. In part because
> of several advancements in rootkits and also in part of the overzealous
> trend in reimaging even the slightest compromised box.
>
> That being said a modern rootkit detector would need to be installed first
> and watch for suspicious behavior, such as attempting to hook system calls
> and watching kernel module loading. Nothing but the kernels mod loader
> should have a legitimate reason to change the list of kernel modules.
>
> In OPs case he really shouldn't need to worry about a rootkit. This wasn't
> a targeted attack. If it was, or even if the script tried to load a rootkit
> then he wouldn't even have seen the questionable files in the first place,
> nor the processes, or the loader. He wouldn't have even been able to grep
> them. Also deploying a rootkit as part of a serious attack is annoying. You
> fuck up one thing and not only have you lost the box, but left a strew of
> evidence that you were trying to hide. Not to mention public rootkits never
> really caught up with the kernel developments. Most rootkits in place are
> still targetting 2.4 kernels because only smart dedicated attackers would
> have the skills to develop and deploy a modern rootkit for a modern kernel.
> Such an attacker wouldn't make so many rookie/nonchalant mistakes as the
> attacker on the ops box did. At most he needs to be concerned if he had
> caught all the backdoors or not. Considering he doesn't realistically need
> to worry about a rootkit(remember, rootkits are annoying, usually easier
> and more practical to stay quiet, get want you want, and leave quietly),
> then he could watch for outgoing connections while monitoring any new open
> ports that have spawned. I would suggest iptables but the OP stated he
> doesn't own the server and has no root access. Sure there are many clever
> ways to reserve access but they all start falling apart as long as your
> waiting and watching for them to make a peep.
>  On Dec 5, 2011 5:53 AM, "Dan Ballance" <tzewang.dorje@...il.com> wrote:
>
>> Thanks for the heads-up on rkhunter Gage.
>>
>> Is there anything else out there atm that works as a reasonable root kit
>> detector or is such a thing considered impossible now? I realise a skilled
>> attack will be able to bury itself without a trace, but I'm thinking of
>> something that can be used in less skilled breaches such as the one thought
>> to have been identified in this thread. Sometimes something imperfect is
>> still better than nothing I think.
>>
>> Also, am I correct to think that using something like tripwire is the
>> best way to detect root kits properly, but that it obviously needs
>> installing when the box is fresh and before it has been physically
>> connected to a network?
>>
>> thanks to everyone for their valuable contributions here - much
>> appreciated!
>>
>> dan :)
>>
>> On 5 December 2011 11:13, Gage Bystrom <themadichib0d@...il.com> wrote:
>>
>>> If it was a rootkit then trying to run the outdated rkhunter would be a
>>> moot point. Whatever seizes the kernel first wins, hands down.
>>>
>>> Fortunately for him, since the bot was so easy to find in the first
>>> place and such a simple way of maintaining it, the box was clearly seized
>>> by someone who didn't give a rats ass about it. Probably a skiddie or an
>>> automated attack to begin with.
>>>
>>> As for plugging any security holes, check your httpd error logs. If you
>>> noted down the time of the bot files creation date you would look around
>>> the same time for suspicious log entries. If they were as careless in
>>> scrubbing the logs as they were holding the box it would give you a look
>>> into how it may have been compromised. If you're getting things like
>>> ../.../../../../etc/passwd then some sort of lfi vuln was likely exploited,
>>> start grepping your php files for stuff like include(), or if you're
>>> getting something like into outfile then check your mysql user permissions
>>> and don't let it have file perms, and then start grepping down for sql
>>> vulns.
>>>
>>> If it comes down to being too much of a hassle to get all the obvious
>>> vulns at least then go to your boss, admit there is an issue and that time
>>> needs to be taken to remove such legacy code as this could have been a far
>>> worse incident if it had been more targetted and the end goal wasn't a
>>> botnet.
>>>  On Dec 5, 2011 3:02 AM, "Dan Ballance" <tzewang.dorje@...il.com> wrote:
>>>
>>>> I'm no expert, but here's something to get you started while you wait
>>>> for more experienced replies. Check for root kits:
>>>>
>>>> sudo apt-get install rkhunter
>>>> sudo rkhunter --update
>>>> sudo rkhunter --check
>>>>
>>>> On 5 December 2011 10:44, Lucio Crusca <lucio@...web.org> wrote:
>>>>
>>>>> Hello *,
>>>>>
>>>>> I'm not new here, but I've mostly lurked all the time through gmane. I
>>>>> never
>>>>> believed it could happen to me until it actually happened: they
>>>>> compromized
>>>>> one of my servers. It's a Ubuntu 10.04 server with all security patches
>>>>> regularly applied. I'm inclined to believe they used some hole in the
>>>>> web
>>>>> application, which is a old customized Virtuemart version (1.1.3),
>>>>> which is
>>>>> not upgradable because of the invasive code customizations (I'm not the
>>>>> author of that code, so I have no clue about what had been changed back
>>>>> then).
>>>>>
>>>>> Now the problem for me is to track down the security hole. Here is the
>>>>> email
>>>>> my provider received and forwarded to me:
>>>>>
>>>>> > Subject: ISP Report; botnet activity on irc.undernet.org
>>>>> > [...]
>>>>> >
>>>>> > Hello, I am an operator on the irc chat network,
>>>>> > irc.undernet.org and i would like you to investigate the
>>>>> > owner of the Ip addresses that are listed at the foot of this
>>>>> > email.
>>>>> >
>>>>> > This/These host(s) have likely been compromised, and had an
>>>>> > altered/rogue process installed on it, and was part of a botnet
>>>>> > that was found on our network.
>>>>> >
>>>>> > The exploit or compromise running on this system is likely
>>>>> > to be an irc bot. Can you please alert the person who is
>>>>> > responsible, for its security to patch/upgrade, remove the
>>>>> > irc process and secure their system.
>>>>> >
>>>>> > = Unix System owners =
>>>>> > A favourite place for hiding the bot(s) is in tmp
>>>>> > and in /var/tmp/ or /dev/shm/ or in a users home directory
>>>>> > sometimes it may be hidden like /tmp/".  ."/ or similar.
>>>>> >
>>>>> > The bot files can usually be found by running these one line
>>>>> > commands as the root user.
>>>>> >
>>>>> > find / -exec grep -l "undernet" {} +
>>>>> > find / -exec grep -l "sybnc" {} +
>>>>> > find / -name "*.set" | perl -pe 's/.\/\w+-(\w+)-.*/$1/' | sort | uniq
>>>>> > find / -name "inst" | perl -pe 's/.\/\w+-(\w+)-.*/$1/' | sort | uniq
>>>>> >
>>>>> > netstat -tanp
>>>>> > lsof -i tcp:<Port number>
>>>>> >
>>>>> > *netstat looking for connections to remote port 6667 or the
>>>>> > range of ports between 6660-7000 once you find the port you
>>>>> > can use the command, lsof -i tcp:portnumber to determine
>>>>> > which process/user it is running under, and terminate it.
>>>>> >
>>>>> > = Windows System Owners =
>>>>> > most windows bots are mIRC scripted bots and generally
>>>>> > need a file called mirc.ini to run, you should search for
>>>>> > this file. Run a good antivirus scanner and firewall.
>>>>> >
>>>>> > This Ip/host may be removed from our Irc network due to the
>>>>> > risks it presents to our users.
>>>>> >
>>>>> > Should you need any help with removing the files or bot
>>>>> > process, feel free to contact me by mail or on our network,
>>>>> > which you connect to using any irc client and issuing
>>>>> > /server irc.undernet.org
>>>>> >
>>>>> > I look forward to your reply
>>>>> > Scot
>>>>> >
>>>>> > * Affected host/IPs, capture time is GMT+1: United kingdom
>>>>> > and servers they were connected to.
>>>>> >
>>>>> > Please note: when resolving server names to IP Addresses
>>>>> > that all our servers end with .undernet.org (for example)
>>>>> > Tampa.FL.US. is actually  Tampa.FL.US.undernet.org
>>>>> >
>>>>> > Important: If you reply to this mail needing further
>>>>> > information, please leave this mail intact, or supply us
>>>>> > with the IP Address(es) in question, as we reference these
>>>>> > mails by the unique IP Address
>>>>> >
>>>>> > Time of Capture: DECEMBER 3, 2011 10:03:48 PM
>>>>> >
>>>>> > List of IP address(es) and server it connected to:
>>>>> > my.server.ip.address (CHICAGO.IL.US
>>>>> >
>>>>> > BUDAPEST.HU.EU
>>>>> >
>>>>> > MONTREAL.QC.CA.undernet.org)
>>>>> >
>>>>>
>>>>> I've run the "find" commands and found a number of file with the first
>>>>> "find", under /tmp/.m
>>>>>
>>>>> Deleted them, looked up remote connections with netstat, killed perl
>>>>> processes that where trying to connect to port 6959 (only trying
>>>>> because
>>>>> I've now set up iptables so that they actually can't), but those
>>>>> processes
>>>>> kept spawning. Checked crontab of www-data, found the launcher,
>>>>> removed it.
>>>>>
>>>>> Now the problem is: how do I pervent further abuse? What should I
>>>>> search in
>>>>> the logs (if anything) to spot the security hole?
>>>>>
>>>>> TIA
>>>>> Lucio.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>
>>>
>>> _______________________________________________
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>

Content of type "text/html" skipped

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists