Binaries not captured, connection reset
ISSUE TYPE
- Bug Report
DIONAEA VERSION
Dionaea Version 0.6.0
Compiled on Linux/x86_64 at Jun 27 2017 02:39:48 with gcc 4.8.4
Started on ip-xxx running Linux/x86_64 release 3.13.0-135-generic
CONFIGURATION
No changes to default config file in 0.6.0
Using HPfeeds to send data to MHN server.
MHN successfully receives logged text alerts, but does not receive payload data (logs or binaries).
OS / ENVIRONMENT
- Ubuntu 14.04 on Amazon EC2
SUMMARY
Binaries are not captured, connection appears to be reset by Dionaea before anything can transfer.
Update Did not specify here originally, the issue was with SMB. I have since verified it is dropping FTP connections as well.
STEPS TO REPRODUCE
Initiated t2.micro instance on AWS EC2. Configured AWS security group to allow all connections.
Ran the below to install:
sudo apt update
sudo apt dist-upgrade
sudo apt install software-properties-common
sudo add-apt-repository ppa:honeynet/nightly
sudo apt update
sudo apt install dionaea
sudo apt-get -y build-dep curl
mkdir ~/curl
cd ~/curl
wget http://curl.haxx.se/download/curl-7.50.2.tar.bz2
tar -xvjf curl-7.50.2.tar.bz2
cd curl-7.50.2
./configure --prefix=/usr
make
sudo make install
sudo ldconfig
Confirmed curl had been updated:
curl -V
curl 7.50.2 (x86_64-pc-linux-gnu) libcurl/7.50.2 OpenSSL/1.0.1f zlib/1.2.8 libidn/1.28 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp
Features: IDN IPv6 Largefile NTLM NTLM_WB SSL libz TLS-SRP UnixSockets
Uncommented SMB.yml to allow for spoofing a Win7 box.
Start Dionaea:
sudo service dionaea start
Verify port is open and vulnerable:
PS C:\WINDOWS\system32> nmap --script smb-vuln-ms08-067.nse -p445 x.x.x.x
Starting Nmap 7.60 ( https://nmap.org )
Nmap scan report for xxx.amazonaws.com (x.x.x.x)
Host is up (0.0080s latency).
PORT STATE SERVICE
445/tcp open microsoft-ds
Host script results:
| smb-vuln-ms08-067:
| VULNERABLE:
| Microsoft Windows system vulnerable to remote code execution (MS08-067)
| State: VULNERABLE
| IDs: CVE:CVE-2008-4250
| The Server service in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2,
| Vista Gold and SP1, Server 2008, and 7 Pre-Beta allows remote attackers to execute arbitrary
| code via a crafted RPC request that triggers the overflow during path canonicalization.
|
| Disclosure date: 2008-10-23
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250
|_ https://technet.microsoft.com/en-us/library/security/ms08-067.aspx
From another box, initiated ms08_067_netapi in Metasploit and sent to the Dionaea install. Exploit fails and Wireshark confirms that Dionaea reset the connection.
I wondered if Amazon/DO were blocking a crafted exploit such as this, but could find no confirmation of any sort. Outside of my test exploits, this install hasn't received any other binaries, at all.
tl;dr
Installed v0.6.0 from the PPA, per the official instructions, on a t2.micro VM on AWS. Updated curl to 7.5.0 as has been suggested in other issues. Ports verified as open, AWS firewall configured to allow connections. SMB.yml is uncommented allowing for connections. Nmap shows vulnerability for MS08-067 and confirms port 445 is actually open.
Using Metasploit to send the exploit, the connection is reset by Dionaea (verified this with Wireshark), and the exploit binary is never received.
Was able to replicate on Digital Ocean as well, also Ubuntu 14.04.
EXPECTED RESULTS
Binary captured and stored in /opt/dionaea/var/dionaea/binaries
ACTUAL RESULTS
Connection reset and binaries folder remains empty.
Output of dionaea.log:
[27022018 19:06:30] connection connection.c:2213-debug: connection_ref con 0x1828df0
[27022018 19:06:30] processor processor.c:207-debug: processors_io_out_thread data 0x1828df0 userdata 0x186d320
[27022018 19:06:30] connection connection.c:2220-debug: connection_unref con 0x1828df0
[27022018 19:06:30] thread threads.c:52-debug: Thread fn 0x41d925 con 0x1828df0 data 0x186d320 took 0.000008 ms
[27022018 19:06:30] python module.c:869-debug: traceable_io_out_cb con 0x1828df0 ctx 0x7f11b2763558
[27022018 19:06:30] connection connection.c:1766-debug: connection_stats_accounting_limit_exceeded stats 0x1829230
[27022018 19:06:30] connection connection.c:1766-debug: connection_stats_accounting_limit_exceeded stats 0x18291f0
[27022018 19:06:30] connection connection_tcp.c:210-debug: connection_tcp_io_in_cb con 0x1828df0
[27022018 19:06:30] connection connection_tcp.c:225-debug: can recv 1 bytes
[27022018 19:06:30] connection connection_tcp.c:230-debug: io_in: throttle can 1 want 1
[27022018 19:06:30] connection connection.c:1869-debug: connection_throttle_update con 0x1828df0 thr 0x1829200 bytes 0
[27022018 19:06:30] connection connection_tcp.c:290-warning: recv failed size -1 recv_size 1 (Connection reset by peer)
[27022018 19:06:30] connection connection_tcp.c:373-debug: connection_tcp_disconnect con 0x1828df0
[27022018 19:06:30] connection connection.c:2208-message: connection 0x1828df0 accept/tcp/established [AMAZON:445->MY.IP:46179] state: established->close
[27022018 19:06:30] connection connection.c:1218-debug: connection_disconnect con 0x1828df0
[27022018 19:06:30] python module.c:884-debug: traceable_disconnect_cb con 0x1828df0 ctx 0x7f11b2763558
[27022018 19:06:30] connection connection_tcp.c:386-debug: reconnect is 0
[27022018 19:06:30] connection connection.c:654-debug: connection_free con 0x1828df0
[27022018 19:06:30] connection connection.c:1766-debug: connection_stats
Thanks for reporting the issue.
Reseting the connection is logical because dionaea is low interaction honeypot and It wouldn't establish the connection. But not capturing binaries is strange. How you are exploiting MS08067 from metasploit you are taking reverse shell or some thing else ?
Hello, Has anyone found a workaround for this issue? I have tried installing Dionaea 0.6.0 in Ubuntu 14.04 and Dionaea 0.8.0 in Ubuntu 16.04 and am not getting any binaries in the binaries folder. I can also confirm that I have completed the steps described above by "sbrws". Thanks,
@ahezza have you test your environment whether is vulnerable or not ?
I have created a guide for testing the environment have a look through it.
https://docs.google.com/document/d/1PctBZW1w4wlIyY-uWAtnQXM-ngwrGL5v6oHUJvP-hlg/edit?usp=sharing
Hi there,
I have been able to verify that my dionaea instance is vulnerable to SMB attacks - see below:
Starting Nmap 7.60 ( https://nmap.org ) at 2019-03-13 15:20 CET Nmap scan report for (x.x.x.x.) Host is up (0.00051s latency).
PORT STATE SERVICE 445/tcp open microsoft-ds
Host script results:
| samba-vuln-cve-2012-1182:
| VULNERABLE:
| SAMBA remote heap overflow
| State: VULNERABLE
| IDs: CVE:CVE-2012-1182
| Risk factor: HIGH CVSSv2: 10.0 (HIGH) (AV:N/AC:L/Au:N/C:C/I:C/A:C)
| Samba versions 3.6.3 and all versions previous to this are affected by
| a vulnerability that allows remote code execution as the "root" user
| from an anonymous connection.
|
| Disclosure date: 2012-03-15
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-1182
|_ http://www.samba.org/samba/security/CVE-2012-1182
| smb-vuln-ms08-067:
| VULNERABLE:
| Microsoft Windows system vulnerable to remote code execution (MS08-067)
| State: VULNERABLE
| IDs: CVE:CVE-2008-4250
| The Server service in Microsoft Windows 2000 SP4, XP SP2 and SP3, Server 2003 SP1 and SP2,
| Vista Gold and SP1, Server 2008, and 7 Pre-Beta allows remote attackers to execute arbitrary
| code via a crafted RPC request that triggers the overflow during path canonicalization.
|
| Disclosure date: 2008-10-23
| References:
| https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4250
|_ https://technet.microsoft.com/en-us/library/security/ms08-067.aspx
|_smb-vuln-ms10-054: false
|_smb-vuln-ms10-061: ERROR: Script execution failed (use -d to debug)
Nmap done: 1 IP address (1 host up) scanned in 113.15 seconds ~
The guide has all the useful material and things you want.
Hello Waseem,
Turns out OVH is blocking Port 445 at a network level on all of their infrastructure. This must be why I am unable to receive binaries.
Thanks for your help.