A recent story making the rounds in both the infosec and public press is the recent use of internet-connected security cameras as a base for DDOS attacks. They dont have a lot of CPU, but theyre linux platforms that are easily hackable, never get updated and usually have good bandwidth available to them.

This shouldnt come as any surprise to folks who are in the security business, or those who do any kind of a product eval before they plug new gear into their network. I see security cameras on network assessments and penetration tests regularly.">PORT STATE SERVICE VERSION
23/tcp open telnet security DVR telnetd (many brands)
80/tcp open http Boa HTTPd 0.94.14rc21
1025/tcp open NFS-or-IIS?
9000/tcp open tcpwrapped
56575/tcp open unknown

The give-away is that Boa web server. For some reason, security camera vendors seem to have standardized on this as their web service. Or more likely, one vendor has, and theyre selling the chipset to everyone else to put inside of their cases.

Lets take a look at that. The Boa project has an active website (www.boa.org), and version 0.94.14rc21 is listed as the latest development release, complete with signatures. Sounds great so far right? Except when we look at the code, it was posted Feb 2005 (yikes!). It looks like this project is no longer seeing active development (as of 11 years ago!). So even if the vendor supplies updates and you apply them, theres no fixing the web portal that faces the network - and so often the public internet.

A quick google shows that this version of the web server is subject to a command injection vulnerability, as described in CVE-2009-4496. Exploit-db has an example curl one-liner that demonstrates this: https://www.exploit-db.com/exploits/33504/ , vulndb has a larger write-up here: https://vuldb.com/?id.51542

Nessus has identified this remote code exec issue for years (plugin 47463).

Shodan identifies 936,736 of these servers on the public internet - because of course its just too much trouble to VPN in to view the video footage on your ATMs or other physical assets

So a DDOS really is that simple. Just using a curl script, you can start a ping -t or ping -t -l 1000 against your victim (I picked 1000 just to prevent any packet loss due to fragmentation prevention). With a few thousand camera devices, you have what the victim will perceive as a sophisticated DDOS attack. Your curl string to attack a test ip address with default sized icmp echo requests would be:
curl -kis http://camera.public.ip.address/%1b%5d%32%3b%70%69%6e%67%20%2d%74%20%31%2e%31%2e%31%2e%31%07%0a

The first few characters are the escape sequence: %1b%5d%32%3b

The string ping -t" />

That aside, what folks are missing in all of this is that these cameras are usually connected on the inside, trusted network, right there next to the servers. Folks seem to find it too much trouble to make a DMZ for these things. So the majority of these cameras make dandy pivots inbound to the customers servers and workstations - your command string isnt restricted to ping, you can run anything you want on the box (that the web service has rights too). From the public internet, you could easily craft an inbound proxy or relay, giving you full access to the internal network - or at least long enough to establish a more reliable reverse shell or vpn solution. Or just use teamviewer or logmein if you have that kind of access, youre less likely to trigger an IPS if you use the same tools that the IT group uses!

The remediation for this? There are a number of things you can do, depending on your situation:

  • Scan your network, look for vulnerable services like this. NMAP will do the job with some legwork, tools like Nessus or OpenVAS will make it easier and smack you with the proverbial LOOK HERE two-by-four.
  • Put vulnerable things that cant be fixed and cant easily be replaced (like these cameras) into a DMZ or a jail VLAN, and dont give that subnet access to anything on the inside network.
  • Restrict access to these cameras to VPN or internal access only (you can reach them, they cant reach you).
  • If you have a vendor monitoring your cameras, do the VPN thing with them also. If you MUST give them direct access, only allow their IP or subnet. (But also start looking for a different security monitoring vendor if you have to do this)
  • Most important of all, try to head this stuff off at the pass. Scan new gear during the evaluation phase. If it doesnt pass your assessment for some reason, phrase your report in business terms, outlining the real risks to the business. You cant get buy-in from the folks who make these decisions by saying No, but its too complicated for me to explain it to you, just No..

As always, preventing these problems before they occur is the easiest way to deal with them. You wont catch them all, but hopefully youll catch things like this!

If you find one of these cameras on your network, please let us know in our comment section! Or better yet, if you have a network-connected security camera that has a different web server, please share the server and version in our comments!

Rob VandenBrink

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Earlier today people have started reporting that they have received a subpoena" />

The email links through to a various compromised sites which redirect the user to afederalcircuitcourt.net web server. Once on the web server you are expected to enter a number and the captchashown before a case.js file is downloaded. " />

The case.js file is being looked at at the moment and the diary will be updated with any findings. In the mean time feel free to block the domain">federalcircuitcourt.netin your web proxies. This is not a legitimate domain.

The federal circuit court has issued a media release -- http://www.federalcircuitcourt.gov.au/wps/wcm/connect/fccweb/about/news/mr080716

If you receive one of these emails feel free to contact us via the contact form and if you can provide the headers of the email and the URL being used for the link that would be appreciated.


Mark H - Shearwater

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

Security experts have documented a disturbing spike in a particularly virulent family of Android malware, with more than 10 million handsets infected and more than 286,000 of them in the US.

Researchers from security firm Check Point Software said the malware installs more than 50,000 fraudulent apps each day, displays 20 million malicious advertisements, and generates more than $300,000 per month in revenue. The success is largely the result of the malware's ability to silently root a large percentage of the phones it infects by exploiting vulnerabilities that remain unfixed in older versions of Android. The Check Point researchers have dubbed the malware family "HummingBad," but researchers from mobile security company Lookout say HummingBad is in fact Shedun, a family of auto-rooting malware that came to light last November and had already infected a large number of devices.

For the past five months, Check Point researchers have quietly observed the China-based advertising company behind HummingBad in several ways, including by infiltrating the command and control servers it uses. The researchers say the malware uses the unusually tight control it gains over infected devices to create windfall profits and steadily increase its numbers. HummingBad does this by silently installing promoted apps on infected phones, defrauding legitimate mobile advertisers, and creating fraudulent statistics inside the official Google Play Store.

Read 8 remaining paragraphs | Comments


Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.

The term APT often describes the methodology more than it does describe the actual exploit used to breach the target. Target selection and significant recognizance work to find the right bait to penetrate the target are often more important than the final vulnerability that is exploited. Traditional defenses like anti-malware systems and blacklists are not tuned to look for the vulnerability being exploited but are more looking for specific known exploits which can easily be obfuscated using commodity tools.

Cymmetriatoday released a research report showing results of a deception campaign they launched to learn more about a particular actor. In this case, the attack was targeting specific individuals using a spear phishing campaign, which are APT characteristics. The vulnerability being exploited (CVE-2014-4114) is about two years old and only affects PowerPoint 2003 and 2007, something you would expect to be patched by now. Privilege escalation was achieved using the UACMEcode which can be found in the public domain.

To exploit and pillage the infected system, open source software like Metasploit was then used to establish a remote shell via Meterpreter.

Cymmetria calls this a Copy / Paste APT in that it used code that was mostly copy/pasted from various well-known sources and methods which would be taught in an intermediate penetration testing class.

Another interesting aspect is the way in which Cymmetria used its deception tools. The overall idea of deception isnt exactly new, but it has seen a renaissance in the last couple years. In the past, Honeypots were mostly used by researchers to learn more about commodity attacks. Researchers usually configured systems with known vulnerabilities in unprotected networks to lure attackers and to learn more about their methods and objectives. Modern commercialdeception tools take a slightly different approach, more along the idea of honey tokens then honeypots. The goal of these tools is to detect more advanced attacks. Systems are not made particularly vulnerable to entice the attacker, but instead, these systems follow more the ideas of honey tokens, small bits of data that entice the attacker to pursue specific targets that are used to detect the attacks. For example, Cymmetriadeployedspecific file shares that would look enticing to an attacker, and left documents behind with pointers to RDP servers that were part of the deception campaign.

In this particular case, after the system was infected via the PowerPoint document, the attacker exfiltratednumerous documents from the system. It took about three days until the attacker discovered the deception file share and tried to access it. The attacker then took the bait, and also connected to the RDP system. However, they were not able to log in as the document describing the RDP service did not include credentials. Instead, credentials would have been available in memory on the infected system (e.g. the attacker would have to run mimikatz).

Cymmetria published IoCs as part of their release. You can use them to look for this threat in your systems. But I think the lesson should be that even more advanced actors can be tricked into using honey tokens, which creates a relatively low-cost opportunity to detect a compromise early. In this case, it took about three days, which doesnt sound great at first, but keep in mind that these attacks are usually only detected after months using more traditional means.

[1] https://www.cymmetria.com/patchwork-targeted-attack/

Johannes B. Ullrich, Ph.D.

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Acer Portal Android Application - MITM SSL Certificate Vulnerability (CVE-2016-5648)
[SECURITY] [DSA 3617-1] horizon security update
Internet Storm Center Infocon Status