Rootkit Findings (updated)
A reader who wishes to remain anonymous sent us a nice write-up of findings uncovered while investigating an intrusion. Below is the entire note, minus identifying details. (New information is available below...)
I got caught out by the recent MailEnable buffer overflow vulnerability by a few hours. I'd been running the patch in pre-live for a few days for testing but was too slow in getting the live server patched unfortunately.
The rootkit seemed to be running 2 ServU deamons one on port 43958 and the other on port 1050 using an SSL connection. There were a host of other ports opened by the rootkit and I couldn't figure out what they were for... The server I had to fix is 200 miles away so it was all done via a remote desktop connection.
I used a heap load of sysinternal tools to figure out what was going on and compared services etc to the build manifest that I created for that server before it was put into production. Using the manifest I was able to ascertain exactly what services had been installed and how to remove them.
The problems came with the rootkit hiding the netsv! and certmngr services along with the associated files in the directory C:\Windows\Congig\system.
I used netstat -a -b a lot to verify information regarding the applications running and used that along with the info from RootKitRevealer to use the sc command from the Windows resource kit to first stop then remove the services.
One thing to note is that the thing renamed the display name of the netlogon service to "System Spooler". If I hadn't been paying attention I might have tried to delete that service too... It would have been a catastrophic mistake to make...
One file that I deleted accidentally was the logon.exe file that resided in the system32 directory. That file was run by the pipext service with the display name of "Windows Media Client (WMC)".
(UPDATE) We asked the person who sent us this information if he would share some additional facts about what he used to build his manifest. Here is his response.
Lesson learned: taking those baseline snapshots, building records of what a "normal system" looks like, anything you can do to establish something as a reference point to compare to when you are investigating an intrustion is a life-saver!
I got caught out by the recent MailEnable buffer overflow vulnerability by a few hours. I'd been running the patch in pre-live for a few days for testing but was too slow in getting the live server patched unfortunately.
The rootkit seemed to be running 2 ServU deamons one on port 43958 and the other on port 1050 using an SSL connection. There were a host of other ports opened by the rootkit and I couldn't figure out what they were for... The server I had to fix is 200 miles away so it was all done via a remote desktop connection.
I used a heap load of sysinternal tools to figure out what was going on and compared services etc to the build manifest that I created for that server before it was put into production. Using the manifest I was able to ascertain exactly what services had been installed and how to remove them.
The problems came with the rootkit hiding the netsv! and certmngr services along with the associated files in the directory C:\Windows\Congig\system.
I used netstat -a -b a lot to verify information regarding the applications running and used that along with the info from RootKitRevealer to use the sc command from the Windows resource kit to first stop then remove the services.
One thing to note is that the thing renamed the display name of the netlogon service to "System Spooler". If I hadn't been paying attention I might have tried to delete that service too... It would have been a catastrophic mistake to make...
One file that I deleted accidentally was the logon.exe file that resided in the system32 directory. That file was run by the pipext service with the display name of "Windows Media Client (WMC)".
(UPDATE) We asked the person who sent us this information if he would share some additional facts about what he used to build his manifest. Here is his response.
For every machine I build and put into production I use tools like tlist to dump out the status of the services and then I put the information into a spreadsheet. The spreadsheet is then kept in an SVN repository. Any changes are logged and the spreadsheets are altered.
I also keep records for firewall configurations, IP filter settings etc all of the things that you would need to reference if an incursion took place.
To be honest, this is the first time in six years that I have ever had to use the information that I log. Most people in the past when I tell them what I do tell me I am mad for doing all the extra work. This one incident proves them all wrong :)... Without it I would have had to reformat and re-install without question and that would have taken quite some time with a 350/400 mile round trip into the bargain too...
I also keep records for firewall configurations, IP filter settings etc all of the things that you would need to reference if an incursion took place.
To be honest, this is the first time in six years that I have ever had to use the information that I log. Most people in the past when I tell them what I do tell me I am mad for doing all the extra work. This one incident proves them all wrong :)... Without it I would have had to reformat and re-install without question and that would have taken quite some time with a 350/400 mile round trip into the bargain too...
Lesson learned: taking those baseline snapshots, building records of what a "normal system" looks like, anything you can do to establish something as a reference point to compare to when you are investigating an intrustion is a life-saver!
Keywords:
0 comment(s)
More DNS Tricks
As a follow-on to yesterday's discussion about the RIRs and how to use the whois service, Alex sent us some thoughts on a favorite site of his, dnsstuff. Thanks, Alex!
It's very easy to use, and can find information without having to look around and fiddle with command line tools. For example, if you type 65.173.218.103 into the whois box, it responds with clickable links to two other blocks, with
at the top of the page.
If you click on NET-65-173-218-0-1, it then takes you to the listing for that record, with another "NOTE: More information appears to be available at MF974-ARIN." Message.
Rather cool.
Also, if you type in 202.30.50.50 into the whois box, it returns:
And drops you straight to the record containing the NOC contact details.
All of this makes www.dnsstuff.com one of my favourite sites.
The site also offers lots of other DNS related tools, too numerous to mention here, you really must have a look around the site yourself.
For the "experts" among us, the site contains two other pages, http://www.dnsstuff.com/pages/expert.htm - containing things like RADB Routing, CIDR/Netmask Lookup, and the very cool WHAT IS? Where you can enter anything and it will tell you what it is.
There is also the test bed at http://www.dnsstuff.com/pages/testbed.htm
which contains some cool new stuff.
Location: United States [City: Bethesda, Maryland]
NOTE: More information appears to be available at NET-65-173-218-0-1.
at the top of the page.
If you click on NET-65-173-218-0-1, it then takes you to the listing for that record, with another "NOTE: More information appears to be available at MF974-ARIN." Message.
Rather cool.
Also, if you type in 202.30.50.50 into the whois box, it returns:
Location: Korea-KR
ARIN says that this IP belongs to APNIC; I'm looking it up there.
APNIC says that this IP belongs to KRNIC; I'm looking it up there.
ARIN says that this IP belongs to APNIC; I'm looking it up there.
APNIC says that this IP belongs to KRNIC; I'm looking it up there.
And drops you straight to the record containing the NOC contact details.
All of this makes www.dnsstuff.com one of my favourite sites.
The site also offers lots of other DNS related tools, too numerous to mention here, you really must have a look around the site yourself.
For the "experts" among us, the site contains two other pages, http://www.dnsstuff.com/pages/expert.htm - containing things like RADB Routing, CIDR/Netmask Lookup, and the very cool WHAT IS? Where you can enter anything and it will tell you what it is.
There is also the test bed at http://www.dnsstuff.com/pages/testbed.htm
which contains some cool new stuff.
Keywords:
0 comment(s)
Firefox update time (updated)
Just a quick note to mention Firefox has released version 1.5.0.2 (and 1.0.8, for those who were not able to upgrade to 1.5) of it's browser. This update fixes some undisclosed security issues. (UPDATE: Mozilla has been releasing details about the issues on their security page. Other alerting services such as Secunia and FrSIRT also have new bulletins available. [m. sachs])
Intel based Mac users can choose to install a universal binary instead of running it in roseta. Choose carefully as it has consequences for the way you install it and for the add-ons you might be able to use.
Some of our readers reported trouble finding the downloads in this early stage, the ftp archive has the best chance of success if the automatic updates fail for you.
Swa Frantzen - Section 66
Intel based Mac users can choose to install a universal binary instead of running it in roseta. Choose carefully as it has consequences for the way you install it and for the add-ons you might be able to use.
Some of our readers reported trouble finding the downloads in this early stage, the ftp archive has the best chance of success if the automatic updates fail for you.
- Release notes
- Security vulnerabilities that are fixed
- Downloadable files from the mozilla web server
Swa Frantzen - Section 66
Keywords:
0 comment(s)
Opera updates, too
And while we're on the subject of web browser updates, version 8.54 of Opera has been released to address a buffer overflow issue in handling cascading style sheets. Time to upgrade Opera, too.
-----------------------------
Jim Clausing, jclausing //at// isc.sans.org
-----------------------------
Jim Clausing, jclausing //at// isc.sans.org
Keywords:
0 comment(s)
Horde exploit attempts in the wild
The Horde Team released version 3.1.1 and 3.0.10 of the Horde Application Framework on 28 March which provided some critical security fixes. On Thursday, 6 April, we got some e-mail to the handlers list about rumors of exploit attempts and an exploit was publically made available on Sunday, 9 April. We have now received some logs that show that there are active attempts in the wild to exploit the help code viewer remote code execution vulnerability. If you are running Horde, you need to upgrade to the latest version as soon as possible.
---------------------------------
Jim Clausing, jclausing //at// isc.sans.org
---------------------------------
Jim Clausing, jclausing //at// isc.sans.org
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments