lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <c21aec84-fbb4-e073-a39f-f5b3ff4eba2b@me.com>
Date: Mon, 05 Dec 2011 14:15:09 +0000 (GMT)
From: "Larry W. Cashdollar" <larry0@...com>
To: mitchell <mitchell@....bg>
Cc: full-disclosure@...ts.grok.org.uk, Lucio Crusca <lucio@...web.org>
Subject: Re: one of my servers has been compromized

I'd check these too:

http://virtuemart.net/security-bulletins

On Dec 05, 2011, at 05:35 AM, mitchell <mitchell@....bg> wrote:

> Hi,
>
> Here is what you generally need to do in such cases.
> 1. Suspend the webapp until you investigate.
> 2. Check the web server logs for unusual entries and identify the entry point. You should have noticed the timestamp of the Perl script in the /tmp directory. Try looking for entries around this timestamp. Usually, the timestamp would be your starting point. The files created in the /tmp/.m directory were most probably put there via an HTTP request.
> 3. Find all locations writable by www-data.
> 4. Touch a file with a timestamp = the date of the incident.
> 5. Find all files -newer than the file you `touch`-ed in the locations writable by www-data.
> 6. Identify any malicious files in the returned listing.
> 7. Stat the malicious files and log the data.
> 8. Quarantine / remove the malicious file(s).
> 9. *Patch* the Web application.
> 10. Check the application code for other vulnerabilities.
> 11. Allow access to the Webapp.
> 12. Check for updates for the application regularly and apply fixes for any security issues if full upgrade is not possible.
>
> Unless you patch the application, the issue will most certainly re-occur.
>
> Regards,
>
> --
> # m
>
> On Mon, Dec 5, 2011 at 12: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/
>  
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ