Even though I've spent some time on dionaea lately, I did not commit much of it yet, so here is a short heads up.
I'm glad worms do not use metasploit. Metasploits smb stack has improved during the last months, and now it tries to use NTLMv2 when talking to an host which claims to support 'extended security'.
If you want to play with current metasploit (3.2), you can use the following code to reset the extended security flag, so metasploit won't use it.
--- modules/python/scripts/smb/smb.py (revision 2179)
+++ modules/python/scripts/smb/smb.py (working copy)
@@ -169,6 +169,7 @@
tmp = tmp.payload
r.DialectIndex = c
+ r.Capabilities = r.Capabilities & ~CAP_EXTENDED_SECURITY
I've broken some parts of libemu's detection while fixing some denial of service issues, so you might experience problems with detection, it is cynical to break the service when fixing a denial of service flaw …
in some cases metasploit showed really strange behavior here …, I was able to trigger some weird bugs in metasploit, including a denial of service attack on metasploit
you get a 5/1 ratio: 5 fails, one success, for some reason metasploit sometimes forgot to send the payload, or send some crap which invalidated the smb protocol session (I used wireshark to confirm this misbehaviour)
While disabling 'extended security' might help if you want to test/demonstrate something, it does not fix the root cause: dionaea does not understand NTLMv2, and my approach to add support for NTLMv2 failed for various reasons:
NTLMv2 itself is rather easy to come by according to this documentation.
But, today Georg Wicherski from mwcollect asked me how he could contribute to dionaeas smb stack, as he copied dionaeas smb emulation for use in his mwcollectd honeypot.
So, there is one more on it, I'm excited to see what he comes up with.
Another challenge I faced was supporting real RPC calls, providing results based on the arguments received. Sometimes attacks use RPC to probe the remote operating system to be able to provide accurate payloads and offsets.
So, I had a look on the data format which is used to transfer remote procedure call arguments for DCE and the format is is called NDR.
Of course, python has no support for NDR, it has support for xdr, which does the same, but slightly different. After some time I actually found some docs, wrote my own ndrlib, and using the (m)idl provided by Microsoft and Samba I was even able to implement some remote procedure calls to fool smbclient to list 'virtual' shares.
smbclient -NL '\\127.0.0.1\test'
Anonymous login successful
Domain=[WORKGROUP] OS=[Windows 5.1] Server=[Windows 2000 LAN Manager]
Sharename Type Comment
--------- ---- -------
test Disk it works
test2 Disk it stillworks
As I get many probes for it, I gave ServerAlive2 a shot, but somehow my replies do not match the attackers expectations, and did not change anything …
To get over it, I wrote mentioned code to list the shares …
My initial idea for dionaea was to make use of XMPP to allow a distributed setup, xmpp has the benefit of providing a secure and autenticated layer to transfer messages. All sensors join an xmpp multi user channel and report their actions in an xml format.
The database backend can be a bot, parsing the messages sent to the channel and storing them into a database.
To avoid messages from sensors getting relayed to other sensors, one can make use of muc acls and hack them not to route messages to users with a specific acl to others, in this case visitor.
If you have mates whom you want to grant access to the raw data, so they can build their own database, webinterface or whatever, you grant them some higher acl on the channel, and they can receive messages from the sensors connected.
I spent some cycles on it last year, and found libloudmouth to be useable for the sensor reporting, ejabberd2 for the serverside, and every scripting languages xmpp binds to connect a backend.
But, when I asked others for it, nobody was interested to support it, as I do not operate a sensor network myself and lack the resources required to provide a jabber server, it got abandoned.
If you are interested in creating the architecture required to operate a sensor network via xmpp, and can to deal with the ejabberd2 erlang code to hack the muc channel's message routing, give me a shout, I still think it would be worth a shot.
As I've been slightly optimistic about traffic in the beginning, I decided to run this blog with comments.
Due to lack of readers, I did not expect spambots to come by and abuse the given freedom. But of course I was wrong, starting Janurary I had to remove the first spam.
To take care, I decided to use a Completely Automated Public Turing test to tell Computers and Humans Apart. Even though the captcha provided is rather weak by default, I decided to increase the image, as captures tend to annoy myself if they are unreadable.
The good news is: spam has stopped, the bad news, the bots never gonna give you up
spambot's multiplied the traffic
Even though it does not affect operations, I feel offended …
As all bots do not GET the page and spam on the same blog entry, they are pretty easy to identify.
Current plans is to