Project 11 - VoIP low interaction server honeypots

Primary mentor: Sjur Usken (NO)
Co-Mentors: Tan Kean Siong
Helping hands: Sandro Gauci, Markus Koetter, Mark
Student: PhiBo
Website: Official project page
Source code: The source code was merged in to the official git repository back in October 2011.


May 2nd - update from Phibo
  • pushed source into GSoC11 git repo
  • created nightly build on launchpad "dionaea-gsoc11"
  • played with wireshark, ekiga, twinkle and asterisk
  • played with svmap and asterisk
  • read sipp documentation to create automated tests for dionaea
  • created xml file for sipp to test registration and invite(tested with asterisk and dionaea)
  • analyzed parts of dionaea
  • analyzed parts of twisted
Done in Week 1 (May 23rd - May 29th)
  • new class to parse and generate sip messages
  • new class to parse URIs
  • new class to parse sip headers
  • use new Message class to answer OPTIONS request
  • handle unknown methods
  • add test using supp and smap
  • new class to parse SDP
  • helped to fix a bug in the recvfromto() function
  • Handle INVITE and BYE methods
Done in Week 2 (May 30th - June 5th)
  • Removing unused code, improving handler detection
  • New Via handler: parse and generate via headers with Via class
  • Handle REGISTER requests without password
Done in Week 3 (6th - June 12th)
  • New config format for sip module
  • new class SipConfig to manage config options
  • Use SQLite DB to store personalities
Done in Week 4 (June 13. - June 19)
  • New auth class (RFC2617)
  • Implement CANCEL
  • Implement BYE
  • Fixed some bugs in a regex
  • User support (REGISTER)
  • Call support (INVITE)
  • Have a look at sip fingerprint db from smap and SIPVicious; can we use them in dionaea?
Done in Week 5 (June 20. - June 26)
  • Have a look at sip fingerprint db from smap and SIPVicious; can we use them in dionaea?
  • Plan how to fingerprint clients
Done in Week 6 (June 27. - July 3)
  • Send SDP data on OK after INVITE
Done in Week 7 (July 4. - July 10)
  • Added idle timer to SipSession
  • Added Contact header to reponse
  • Fixed BYE after INVITE
  • A few fixes
Done in Week 8 (July 11. - July 17)
  • Use logger.debug() instead of prints()
  • API Changes to unify function calls
  • Implement OPTIONS
  • Support compact headers
  • util: - send data over udp
  • Fixed some bugs
Done in Week 9 (July 18. - July 24)
  • Capture RTP-Data
  • Support more than one stream
Done in Week 10 (July 25 - July 31)
  • Setup Lync-Server
  • SSLSniff, Wireshark to decrypt Data; but no luck
  • Setup Asterisk with TCP-Support
  • Used some tools from BT5 to test Asterisk
Planed in Week 11 (August 1 - August 7)
  • TCP-Support
  • Error Handling
  • Add more timers to handle timeouts


  • Trouble to install MS Lync - Displays an error when applying the AD schema

Project Overview:
This project is about the further development of this module to support more scanning tools and also handle client registrations and calls. It is also important to capture the rtp data and to convert the captured data into an audio file like wave or ogg.

Project Plan:

extend test lab (backtrack, dionaea, ... already installed)
setup Astersik
setup OpenSER/Kamailio/OpenSIPS
setup Microsoft Lync Server
explore sip tools and analyze the data send
work on the http module
dump post data to hard disk
logging to file
logging to sqlite db
maybe: logging to ore
May 23: Students begin coding for their GSoC projects
Week: 1 (May 23 - May 30)
In the current version of the sip module the response messages are hard coded.
  • Analyze existing sip module in detail
  • Use guide from and the RFCs to implement sip support
  • implement a class 'Request' to parse request messages
  • implement a class 'Response' to generate a response
  • Support basic client(Twinkle, ekiga, ...) registration
  • Implement REGISTER (RFC3261)
Week: 2-3 (23. May - 13 June)
  • Parse SDP message
  • Generate SDP response
  • Implement OPTIONS (RFC3261)
  • Implement INVITE, ACK and BYE to make calls (RFC3261)
Week: 4 (June 14. - June 19)
  • Implement CANCEL (RFC3261)
  • State-Machine - keep track of the states; already exists in the class 'SIPClient'
  • I think some states are missing in class 'SIPSession'
Week: 5-6 (20. June - 3. July)
  • Add user support (REGISTER)
    • Config entries
    • UserID with or without password
    • UserID ranges

  • Call support (INVITE)
    • Config entries
    • Only Ring, don't answer calls

  • Error handling
    • BYE without INVITE
    • ...
Week: 7-8 (July 4 - July 15)
  • Support SIP over TCP(MS Lync)
    • ... I have to do some research on this ...
    • maybe we have to do stream resampling?
    • fragmentation?
  • Do delayed tasks - I hope to get things done in time. ;)
  • Test support for scanning tools: SIPVicious, smap, ... and fix missing things
  • Test clients and fix missing things
July 15: Mid-term evaluations deadline
Week: 9-10 (July 18 - July 31)
  • Capture RTP-Data
  • Decode RTP-Data
    • use class incident to report complete state
    • use an ihandler to convert rtp-data
    • use python + commandline tools to convert data (,

Week: 11 (August 1 - August 6)
  • Extend SIP to Support SIMPLE (RFC3428) (MS Lync, SIPE module for Pidgin)
Week: 12 (August 8 - August 14)
  • Do delayed tasks - I hope to get things done in time.
  • Add some extra features, it depends on the data captured in the last weeks. Some ideas are:
    • Handle 'PUBLISH'. Ekiga sends PUBLISH messages, after registration
    • Send RTP data
    • Redirect to real sip server with 302 temp moved
August 15: Suggested 'pencils down' date.
  • Clean code
  • Run some final tests
  • Improve documentation
August 22: Submit code

Comments from last year student (tobi)

* BUG: Sipvicious -mCANCEL makes the sip honeypot return "200
OK" even when no session is running; should be some kind of error code
since user is trying to cancel a non-existing session/request

* to make analysis easier, a more SIP-specific SQL table should be used,
the current one is more suitable for SMB, HTTP, etc. That's because SIP
is a bit special when it comes to port multiplexing (ask common, he
hates it :D )

* I used dionaea for my MSc thesis and found a "bug" in the processing
of incoming calls. It's not really a bug because the SIP message is
processed according to the protocol but the honeypot should be flexible
enough to accept incomplete/invalid SIP messages. I simply quote my
thesis text:
However, a response for the INVITE requests was not sent because of a
software bug in
the honeypot module. The moment the incoming INVITE request is processed
by the SIP
parsing function, the following log entry is generated:
warning: Mandatory header content-type not in message
This is due to the fact that a phone call has to specify the details of
the session, which is
usually done by embedding an SDP message in the SIP body. Because of the
SDP message, no research on brute-force attacks against the
authentication mechanism
used for INVITE requests could be conducted. Also, no RTP channel was
that could have provided useful information on the type of the phone call.