Thanks for that. I've learnt a lot from this thread. Peace to you all. On 5 December 2011 20:11, Gage Bystrom <[email protected]> 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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> 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/ >>> >> >>
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
