Six Deadly Security Blunders Businesses Make

Sometimes it's the unknown or overlooked little mistakes that leave an organization wide open to attack: a missing hash mark in a server configuration, a long-forgotten PBX user account, or an embedded Web server in an office printer.

With compliance pressures, increasingly cagey malware, and the fear of being the next front-page data breach victim, it's no wonder that enterprises might not notice potential problems with their lower-profile devices, or make subtle configuration mistakes.

Even so, ignorance is no excuse when the bad guys hone in on an inconspicuous weakness, like a few older, rarely used desktops that haven't been updated with the latest patches. It takes only one weak link for an attacker to gain a foothold into an organization and steal valuable data, or set up shop for long-term cyberespionage.

Spooked yet? Take a look at some subtle but potentially dangerous mistakes enterprises make that could come back to haunt you. 1. Improperly configuring an SSL server.
SSL has gotten a bad rap lately for some inherent security weaknesses. But many SSL servers aren't configured properly such that they aren't even exploiting the benefits of an encrypted session. Only about one-fifth of SSL websites actually redirect to SSL for authentication, and about 70 percent of SSL servers handle credential logins in plain text. More than half submit passwords in plain text.

That's according to a global SSL survey by SSL Labs, Qualys' community project. But that's not all: Now the bad guys can perform a denial-of-service attack on an SSL server without the help of a botnet. A new hacking tool unleashed this week abuses the SSL renegotiation feature to DoS an SSL server from a single laptop or other machine.

Organizations that mistakenly leave SSL renegotiation enabled are vulnerable to this attack with the so-called THC-SSL-DOS tool now circulating. Security experts say SSL renegotiation on a Web server isn't really necessary, anyway, and recommend disabling it altogether.

But there's still no actual solution to defend against the attack, says Tyler Reguly, manager of security research and development at nCircle. "It's the way the protocol works," he says.

Reguly says the DoS attack is one more piece of evidence that SSL is broken. "We need something better," he says. 2. Overlooking a rarely used account with high-powered privileges.
Many organizations fail to lock down an administrative account, using default logins and passwords that can ultimately give attackers the keys to the kingdom. But there are other lesser-known or used accounts that can easily be forgotten and left open for abuse.

A Fortune 500 financial services firm that was considered highly secured and had protected its admin account recently was caught unaware by a long-forgotten field-manager user account on an old Siemens Rolm PBX: That relatively powerful user account was all penetration testers from Trustwave SpiderLabs needed to set a trap to infiltrate the firm's heavily fortified network. They used the account to establish a cloned help-desk voicemail box, and waited for a caller they could social-engineer for his user credentials. Havelt, posing as an IT help-desk engineer, easily obtained a VPN user's username and two-factor authentication token password when he fixed his VPN connection.

That led the pen testers to the firm's HR finance and wealth management transfer systems, as well as other sensitive information.

"It was a tiny, little thing that snowballed," says Rob Havelt, director of penetration testing for Trustwave SpiderLabs, who worked on the pen-testing engagement for the company's financial services firm client. "It's always the little thing: That's a recurring theme. Leave a default account, default password. It might not seem like a big deal, but it can rapidly [escalate]. ... If you give anyone any level of access, they will find a hole." Havelt says organizations should audit all equipment, even legacy systems like PBXes. "Make sure you are enforcing password policy," he says. In the case of the financial services firm, the PBX systems "belonged" to the telecommunications group rather than IT, and there was a disconnect security-wise. "Ideally, you need somebody to take responsibility for anything that can be plugged in [the network]," he says. 3. Assuming your VPN traffic is always secure.
Just because a user connects to the corporate VPN from a hotel network doesn't necessarily mean remote security. "It's a pretty serious mistake" assuming a remote employee coming in over the VPN is safe and secure traffic, says Nimmy Reichenberg, vice president of marketing and business development for AlgoSec.

"Working from a hotel network, there's a lot of malware they can pick up, and a lot that might not be detected by the endpoint's AV. Then if they are allowed to tunnel in, that malware on the PC is pretty bad stuff coming into the corporate network," he says. "When a typical user working remotely or from home connects to the VPN, they may not have [proper] security controls in place."

So although a VPN session is theoretically authenticated and encrypted, an already-infected user machine can be introducing badness to the corporate network. If the user's machine is bot-infected, the botnet then also has access to the internal network, Reichenberg says.

The key is to stop even VPN traffic at the DMZ first for inspection, he says. "Most companies don't do that," he says. "They inspect traffic from untrusted external sources, but if traffic is over a VPN, it isn't perceived as a risk."

That could be accomplished with a firewall policy, for instance, he says.

"A lot of people believe traffic over the VPN is secure. We argue that this is not the case," he says. 4. Ignorance of embedded systems.
Copiers, scanners, and VoIP phones contain embedded Web servers that typically aren't secured or are misconfigured such that they are exposed to the Web when they are installed. " Virtually none of these should be exposed to the Internet. There's not a good reason that an HP scanner should be exposed to the Net," says Michael Sutton, vice president of security research for Zscaler Labs, who shared his findings about the breadth of the problem at Black Hat USA this summer.

Sutton found Ricoh and Sharp copiers, HP scanners, and Snom VoIP phones most commonly accessible via the Internet. And it's likely they belong to companies that have no idea the devices are showing up online.

Digital archives of photocopies could be lifted by attackers, who also can eavesdrop on the embedded VoIP systems via a packet capture feature, for instance. "If [the VoIP system is] accessible, you can log in, turn it on, capture traffic, download PCAPs ... and with Wireshark, you can eavesdrop on organizations," Sutton says.

The key is to scan for these types of vulnerable devices before the bad guys find them. Sutton built a free tool called BREWS that automates the scan.

Other network equipment also comes with misconfigurations that leave unknowing customers at risk. HD Moore last year revealed how he found hundreds of DSL concentrators, SCADA systems, VoIP equipment, and switches that contained a diagnostics service for feature from VxWorks. It's a feature that should not be enabled in production mode, warned Moore, chief security officer at Rapid7 and chief architect of Metasploit, because it would allow access to read and write memory and power-cycle the device.

A related problem comes with today's consumer devices that come equipped with GSM or cellular access. Don Bailey, a security consultant with iSec Partners, says GPS tracking devices, car alarms, and even SCADA sensors are vulnerable to attack via the network. Once an attacker finds one of these devices on the network, he can abuse them.

Bailey successfully hacked into a popular car alarm system and started the car remotely by sending it a text message. Even more chilling is the potential for abuse for a SCADA sensor. 5. Typos in source code or configuration files.
A missing forward-slash symbol in Apache Web servers -- and possibly other Web platforms -- could lead attackers to databases, firewalls, routers, and other internal network devices. The recently revealed reverse-proxy bypass attack on Apache servers demonstrated how a single character in a configuration file can make or break security.

Michael Jordon, research and development manager at Context Information Security, which discovered the problem, says it's more of a misconfiguration issue that users didn't know about: that a forward slash was required in a so-called "rewrite rule" for an Apache Web proxy

"It's a classic case of functionality lying around that people didn't know was there, and didn't know the misconfigurations are," Jordon says.

Apache released a patch for the issue earlier this month, but Jordon says it's a problem that likely affects other Web platforms as well. "The patch reduces the likelihood of misconfiguring it," he says.

"Any other URL-rewriting reverse proxy would potentially have the same issue. We have contacted other Web server providers to inform them of this," he says. 6. The obvious -- but still common -- problem of leaving obscure systems unpatched.
Patching is an obligatory best practice, but that doesn't mean organizations do it right, on time, or even at all for some systems deemed low-risk.

Take the U.S. Department of Energy, which this week was called out for poor patching practices. According to the DoE Inspector General's office, 15 different DoE locations were found running desktop systems, network systems, and network devices running apps that hadn't been patched for known vulnerabilities. About 46 percent of the desktop systems were running operating systems or apps without the most current patches, for example, according to the IG's report.

"These applications were missing security patches for known vulnerabilities that had been released more than 3 months prior to our testing," the report (PDF) says.

But the federal agency is far from alone in leaving systems unpatched: Many organizations struggle to get a handle on the vulnerabilities in their environments. Recent research from Secunia suggests that enterprises could realize big-time security improvements if they prioritize their patches by the severity of the vulnerability instead of the prevalence of the application.

Marc Maiffret, CTO and co-founder of eEye Digital Security, says it comes down to not knowing what you don't know. "Companies ... don't have the visibility, so they don't have a handle on where the weaknesses are in their environment. Or they don't know where to start, and they give up," Maiffret says.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.