Category: Blogs


Safe harbor is the best harbor

arsTechnica published an article about, a site promoting an open source approach to creating standard policies for companies that protect security researchers and encourage responsible disclosure. This is a response to the technology sector’s current state, where every company has a unique policy (or in many cases, no policy) defining a process where researchers can submit their findings and be guaranteed protection from legal action. This policy minefield puts a damper on research and reporting of new vulnerabilities.

A study commissioned by the Center for Democracy & Technology (CDT) found that security researchers are often hesitant to report their findings for fear of legal action. This creates a chilling effect in the research community and harms overall security by preventing responsible handling of vulnerabilities. Think about this: If you’re a white hat hacker, who do you target for research? Company A with a clearly-defined vulnerability disclosure policy or Company B that takes legal action against researchers?

Of the researchers we interviewed, few reported receiving threats related to a disclosure, either veiled or explicit. The researcher reporting the greatest number of threats often serves as a disclosure intermediary for other researchers. This subject reported that many of the researchers for whom the subject had performed a notification or disclosure did not want to notify the company themselves because of the risk they associated with notification. Other interview subjects reported being pressured by companies to keep quiet or to sign non-disclosure agreements (NDAs).
– Page 12 of the “Risk Basis for Security Research” report.

What is responsible disclosure?

Responsible disclosure is one of several models of releasing security vulnerability research. The key differentiator in the Responsible Disclosure model is that the information is made public only after a period of time has passed and a patch has been released to the public. This model allows researchers to contribute to the greater good while companies have time to develop, test and deploy patches to protect customers. Researchers still receive credit and, in many cases, financial rewards. The SANS Institute InfoSec Reading Room has an excellent paper on Responsible Disclosure and touches on other models.

Why we need standards:

Malicious hackers are examining products as intensely as white-hats – perhaps even more so as there is a huge financial incentive to develop and weaponize vulnerabilities. These weaponized exploits are incorporated into attack tools available for free or at a moderate price on the dark web. Malware as a service (MaaS) is an extension of the shift to cloud-oriented and subscription-based models and is making sophisticated attack tools more accessible to would-be attackers.

Companies that don’t create a safe harbor for security researchers are only hurting themselves and their users. Policies that promote research, give legal protection and outline financial incentives attract ethical people. These researchers act like an extension of a company’s own security and QA resources. By protecting and enabling research the company will be made aware of vulnerabilities before they are discovered and used for malicious purposes. This allows companies to protect their users and avoid significant fines and loss of goodwill.

Companies with no safe harbor policy reap none of the benefits of this supplemental security blanket. Ethical researchers will avoid companies that stifle research and target responsible disclosures with legal action. As white hats avoid these companies, black hats will be attracted to products that aren’t being evaluated for vulnerabilities. Ironically, these vulnerabilities will cost the company many times what an incentive-based, safe harbor policy would. Now that GDPR is enforced, a company can face up to a 4% of Annual Global Turnover fine (or €20 Million, whichever is greater) for violating data privacy regulations.

All companies, whether the product is hardware and software or they’re used to support business operations, has a stake in the effort to promote responsible disclosure of vulnerabilities. Vulnerabilities will continue to be discovered and weaponized, putting users’ privacy at risk and costing companies millions of dollars in lost revenue and remediation. Vaccines are so effective because they create herd immunity. Like a vaccine, the more research directed at technology products the safer we will all be.

2fcibmMugatu knows a trend when he sees one.


Amok IoT

Armis Security, the firm that discovered the BlueBorne vulnerabilities in the Bluetooth protocol in 2017, released a blog analyzing IoT device susceptibility to DNS rebinding attacks. The bad news: nearly half a billion devices are vulnerable. Worse: Patches are unlikely to be developed. Worse still: Most of these IoT devices are treated like appliances and aren’t touched until they fail.

What is a DNS rebinding attack?

A DNS rebinding attack occurs when an attacker manipulates the DNS trust model to their advantage. When a user visits a website under the attacker’s control (usually through phishing emails or instant messages), the user’s browser is fed malicious code. This code issues HTTP requests that, manipulated through DNS rebinding, direct queries to addresses on the user’s local network. The attacker can use the victim’s browser as a proxy to communicate with the private network, enumerate devices and send commands.

IoT devices see commands coming from the victim’s computer on the local network and will allow access to management pages. The attacker gains access to these devices by using default passwords and exploiting vulnerabilities in software. Once the attacker has control of the device they can initiate connections outside the network, bypassing NAT and common firewall security measures. These compromised devices can be used to attack laterally on the network.

Armis has a great, short video on YouTube explaining the flow of the attack:

An attacker got into my IP camera… so what?

With a foothold on the network and persistence established in multiple locations, the attacker can do just about anything they want on the network. IoT devices are treated like appliances but are actually low-power Linux boxes attached to cameras, microphones, door locks, kitchen appliances… and your network. The same network your file server with your engineering files and financial data.

A short list of possibilities:

  1. Add members to a botnet. Your dozens of IoT devices may have low power but can still push packets out and amplification attacks help them punch above their weight as part of a DDoS attack.
  2. Hijack devices to perform reconnaissance. Security cameras and smart locks are designed to make you more secure but can only so when under your control. An attacker could hijack security feeds to establish employee patterns and support more damaging attacks. For example, consider this: when does your company take deposits to the bank? When does the IT staff knock off for a long weekend? Can your PTZ camera zoom close enough to see access codes entered into a keypad?
  3. Pivot to other network devices. A compromised device on the network can be used to attack servers that are protected from internet traffic. Yes, access to that crusty Accounting Department box running Server 2003 is forbidden from the internet but what about the SMB shares for reports?

That’s bad but I would literally die without my IoT. What do I do?

There are a few relatively simple steps that can be taken to vastly improve the state of IoT security on your network. We know that these devices aren’t updated regularly (if ever) and we know they often aren’t actively managed or monitored.

  1. Monitor egress traffic and apply rules to prevent unintended outbound communication. If an IoT device is compromised through a DNS rebinding attack but outbound communication is blocked at the network edge you’ve prevented your device from being a productive botnet member. By monitoring egress logs you would see connection attempts and be able to respond to the compromised device.
  1. Isolate IoT devices on their own network segment, virtually or physically. By implementing VLANs and restricting access between networks you can limit the damage a compromised IoT device can do. Blocking lateral movement will help protect assets that may be vulnerable to attacks from the local network. For anyone who played the “I’m not touching you” game in the back of the family minivan the answer is clear: Captain’s Chairs for your network.
  1. Monitor IoT devices, keep them up to date and don’t buy the cheapest solution. In IoT, you get what you pay for. Those no-name cameras offer a low entry cost but don’t include the support you receive from established, market-leading companies. Your upfront savings will be obliterated in the face of lost IP, stolen PII, bandwidth consumed and IT staff hours spent remediating the problem. You must also keep tabs on your IoT devices: is anyone reviewing the camera footage? Is one camera angling for a better shot of the back office housing the safe? What about the server room?


IoT promises so much – convenience, security, intelligent devices. Unfortunately, they can’t – and shouldn’t – be trusted on the same network as the servers that house your critical files or the workstations your users depend on to get work done. Think about the smartphone revolution… it’s 2018 and most mobile devices are supported for a few years at best. What’s the refresh cycle on your security cameras?

Taking a few simple architectural steps at the network level, monitoring network egress traffic, locking down outbound communication and checking in on IoT devices regularly can vastly improve the security posture of your network and limit damage caused by compromised devices. The IoT industry will mature over time and standards for patching and security will emerge. Until then, Trust No One.


BlogsRemote Access

RDP? Yeah, you know me.

A recent McAfee Advanced Threat Research team blog post discusses the world of dark web RDP shops – sites specializing in the sale of access to machines via Microsoft’s Remote Desktop Protocol. There are many things for sale on the dark web, from novelty MDMA pills to stolen drone documents. While illegal products and classified information are concerning, sites selling remote access to systems poses an exigent threat to public safety.


Image source: IBTimes

What is RDP?

Remote Desktop Protocol is a proprietary protocol developed by Microsoft to allow users to connect to a remote machine through a GUI. The connection supports transfer of video, audio, clipboard data, printer data and keyboard & mouse traffic. RDP can be configured to encrypt traffic with RSA’s RC4 cipher with a 56 or 128-bit key. Remote Desktop is an invaluable tool for administrators and remote workers but presents a serious security risk when configured with weak credentials and left exposed to the internet.

So, what’s the appeal for threat actors?

Imagine that you’re trying to break into a bank vault. You spent months carefully digging a tunnel from the basement of the dilapidated theater across the street. You’ve assembled a highly-skilled crew: femme-fatale safe cracker, Vegas-native security system specialist, the best conman in the tri-state area and some muscle in case things go south. Months of planning and thousands of dollars have been spent pulling off this heist and acquiring specialized tools. Your tunnel finally intersects the bank’s vault room. Heart pounding, you carefully cut your way through the reinforced concrete and, at long last, face your ultimate challenge – the grey, implacable face of the best vault money can buy.

The elevator dings behind you. Your crew spins around in unison, now-sweaty palms gripping the stippled texture of their weapons. You shout, “Who’s there?” with an adrenaline-fueled voice over the barrel of your pistol.

“Hey guys, chill. It’s me, Donnie, the getaway driver. Remember me?” Donnie steps out of the elevator, arms raised, a set of keys in one hand and a Post-It note in the other. “I was sitting in the car and saw the manager taking off. He left his keys in the door and there’s this thing on the keyring that turns the alarm off.”

“Like a car alarm, right? Then I checked out his office and found this.” Donnie hands the note over. It reads, “Vault Code – 3389”.

You punch the code in, the vault opens like you own the place. Everyone gets paid, but you can’t help but think about the money you could have saved with an easy way in. And next time you’ll try Donnie’s approach.

That’s what having RDP secured with weak credentials and exposed to the internet is like. Someone with a low level of technical skill can breach your security totally with minimal effort.

Malicious hackers benefit from using RDP as it avoids needing to employ specialized tools. Why bother with creating a spear phishing campaign, hoping you get some poor soul to open an attachment and waiting for that malware payload to successfully connect to your C&C when you can easily (and cheaply) purchase direct access to a system?


Does that sound bad? It is.

McAfee researchers examined a fresh Windows Server 2008 R2 entry on sale for $10 at one of the larger remote access shops. For that princely sum, an attacker would gain administrative access to machines controlling security and building automation systems at an international airport in the USA. The team was able to determine the target machine’s full IP address (the last two octets are redacted on the shop site until you’ve paid) by using the Shodan search engine and narrowing results by the city and default RDP port number (3389).

The query returned three results. WHOIS queries on those results determined that they belong to a major international airport. Exploring further, three accounts were available on the Server 2008 R2 machine for RDP connections. The Administrator account was obvious. The other two usernames were determined to be related to two companies that specialize in airport security – one in building automation and the other in video surveillance and analytics. Researchers were also able to determine that the computer was joined to a domain likely related to an inter-terminal passenger transport system. This machine and the available accounts are in a great position on the network to cause major damage and support lateral movement.


RDP is a great administrative tool and enables remote workers to chill in their adult jammies while cranking out a pivot table. It makes life easy for all, including cyber criminals. Fortunately for you, Defender of the Network, there are a few basic security steps you can take to harden RDP.

Use complex passwords + multi-factor authentication to defend against brute-force attacks. Strong passwords greatly increase the time needed to guess a password and multi-factor authentication provides an additional layer of security for accounts.

Enforce user & IP lockout policies when too many failed connection attempts. This prevents an account from being compromised and maintains the system’s integrity. If a specific account is attacked several times it may give insight into the attack.

Log connection attempts (successes and failures). Logging is important to identifying attacks, identifying the source of attacks and mitigating attacks in progress.

Use a VPN to wrap RDP up in a more secure shell. Don’t expose any machines directly to the internet that don’t have to be. Using a VPN provides stronger encryption as well as an excellent audit trail and nonrepudiation.

Remember: your security doesn’t have to (and can’t) be perfect. In many cases it just has to be better than the next guy down the IP block. Taking simple steps to harden your systems, applying the principle of least privilege to user access and looking at your network’s profile from the WAN side of the firewall are the first steps down the road of remote access security.