Friday, February 28, 2014

WiFi Virus Created

Security researchers have designed a virus that spreads silently through WiFi networks. The "Chameleon" virus replaces access point firmware and masquerades the settings and administrative credentials, which makes it very difficult to detect this virus.

Fortunately, the virus can be blocked by following good WiFi security practices. Unfortunately, many WiFi networks are not set up in a secure way.

Fortunately, the steps to secure a home WiFi network are not particularly difficult:

Beyond securing your own routers, you need to keep in mind that public routers may also have been infected. There are some steps you can take to protect yourself when connecting to public WiFi routers. Be aware that public networks are by definition insecure, whether WiFi or wired. There is little or nothing to stop a miscreant from trying to snoop your connection.

  • Enable built-in firewall features on your computer, especially software firewalls. Deny all incoming connections.
  • Make sure file sharing is turned off.
  • Be aware that passwords may be sniffed by keyboard loggers, pulled from your computer's registry, or simply observed over your shoulder. By using a tool like LastPass or Password Safe, you can avoid having to type passwords while storing them in a secure, encrypted location.
  • Use a VPN if possible.
  • Use https (HTTP over SSL) to connect to vendor sites wherever possible.

Sunday, February 23, 2014

Windows Crash Reports and Intrusion Detection

Websense recently published a whitepaper discussing how to use Windows crash reports to identify intrusions. They took their analysis one extra step past detecting known attack signatures to look for new, unknown attacks.

While researching the whitepaper, Websense used their methodology to identify a new targeted attack against a mobile network provider and a government agency, and a new Zeus-based POS (Point of Sale terminal) attack.

Tuesday, February 11, 2014

CryptoLocker, Ransomware, and the Importance of Good Backups

CryptoLocker attacks have become more frequent and public. CryptoLocker is a type of ransomware that stealthily encrypts all available files on the infected computer or attached shares or devices. Then the computer user is warned that the files can only be decrypted with a key that must be bought and installed within 100 hours.

Of course this is extortion. But Symantec estimates that 3% of victims pay up, which is enough to net the extortionists millions of dollars per month.

Recently, a law firm's entire store of legal files was encrypted and unable to be decrypted. Consider the potential implications of being legally responsible for these documents and being responsible for their destruction through negligence.

Removing the infection from the computer is relatively straightforward. There are free tools, such as this tool from Sophos. Alternatively, you can roll your system back using Windows System Restore, if you had enabled that feature before you were infected. Other, more intrusive methods may be needed, if these do not work. These tools can remove the infection, but decrypting the encrypted user files is not likely to be possible.

If your files have been encrypted, you are going to need to recover from backup. Once your PC has been disinfected, you can attempt to recover files from Shadow Volume Copies (which is part of Windows' System Restore). But you are most likely to be successful if you have been backing up to a system that did not allow the infected PC to overwrite your backups.

Friday, February 7, 2014

Outsourcing, Lax Authentication, and the Target Hack

It turns out that the hackers who broke into Target's POS terminals used credentials from Target's HVAC vendor.

Fazio Mechanical, Target's HVAC vendor, had access to Target's network in order to monitor the temperatures in the stores and the health of the HVAC equipment. It is less clear why access was allowed with weak authentication, and why there was no network segmentation between the HVAC units and the POS terminals.

The only really sophisticated part of the attack was the memory-scraping software actually used in the POS terminals. The rest appears to have been a combination of standard attack methods.

One of the key user accounts used to consolidate and move data around Target's network was the "best1_user" account, which is an account name usually associated with the Performance Assurance for Microsoft Servers agent of BMC Software's Patrol product.

It appears that a SQL injection attack was a key part of compromising servers to place the malware and recover the stolen data.

Target has stated that it intends to invest heavily in chip card technology. This would help with "card present" attacks (ie attacks based on cloning a physical card), but would not do much for "card absent" attacks (where a purchase is made from a remote location).

Thursday, February 6, 2014

Cybersquatting Takes an Unhealthy Turn

Cybersquatters made the news recently, after they noticed some typos in URLs on the British National Health Service's (NHS) web site. But in this case, they were not looking to extort money from someone wanting to use the URL for legitimate purposes. Instead, they used the new URLs to host malware to infect the computers of people following the links from the NHS web site.

The NHS reports that they have fixed the typos.

Sunday, February 2, 2014

Secure Application Deployment in the Cloud

The cloud provides a great way for a company to push infrastructure costs to an external vendor. But things that are minor for a locally hosted application could become a huge security hole when hosted externally.

Some key issues to look at when moving an application to the cloud include:

  • Communication channels to services and systems the software relies on.
  • Communication channels used for necessary communications to clients.
  • Encryption standards for data at rest.
  • Logging, log reviews, and monitoring.
  • Authentication and access control.
  • Privacy policies.

A lot of the security scrutiny surrounding a cloud migration focuses on the security of the cloud provider's infrastructure itself. This is important, but the weaknesses that the software platform brings along with itself are almost certainly a bigger problem.

Communication Channel Security

The key considerations here have to do with the nature of this communication. Certain types of data should not be transmitted unencrypted across an external network. This includes information protected by the privacy policy and relevant regulations, but it may also include information that would tell someone how the application works.

There is really very little incentive not to encrypt all traffic. There is a performance hit, but the only responsible way to avoid it would be do perform a close analysis of all data that would not be encrypted. Even when the analysis was complete, you can't guarantee that the program won't change in a few months (even assuming that nothing was missed in the analysis). There are a number of options for forcing encrypted traffic, including built-in capabilities in both Java and .NET to force use of SSL for web interactions.

Where programs have incorporated hard-coded IP addresses in code, there is some possibility that traffic would be delivered to entirely the wrong place in a hosted environment. This is especially the case for the standard ranges that are commonly used for internal IP addresses.

But the use of hostnames can also be problematic, since name lookup infrastructure is usually controlled by the outside vendor. (In any case, references to specific names should be contained within configuration files, not in the actual code source.)

Where possible, client-side SSL certificates can provide an extra layer of security, by providing assurance that the target side of the connection is actually the system that we are trying to contact.

Data Encryption

Data at rest can be secured using several technologies, some of which overlap. SQL Server and Oracle both provide Transparent Data Encryption (TDE), and DB2 provides similar functionality. Make sure key sizes are in line with current best practices recommendations.

Queries to databases can be encrypted during transmission by specifying SSL as the connection protocol in the JDBC driver or .NET connection.

Keep in mind that existing hard-coded encryption tokens, keys, etc may cause problems during application migration to the cloud. And if the same key is re-used in several contexts, the compromise of a single component can result in a broader compromise through the entire application or environment. It is important that encryption keys, tokens, etc be maintained outside of the code base itself, where they can be changed or updated as needed.

Logging Considerations

Logging streams usually do not use connection-oriented protocols. One concern about logging in the cloud is that logging streams are relatively easy to divert or snoop. Debug-level information might be considered an information leak about how the parts of your application communicate, which could provide the information an attacker needs. While we need to allow an adequate level of logging, we may also want to restrict access that would allow too high a level of logging to be enabled.

At the same time, it is important that logs be maintained and reviewed, just as they should be on an internal network. Given the potentially greater exposure of the data, log review procedures need a careful review as part of any application cloud deployment.