Internet profile passwords exchanged as divorce court evidence

A article points out a recent and possibly disturbing trend in divorce proceedings: the exchange of Facebook and dating website passwords as part of the discovery process. Typically in a proceeding, evidence is allowed to be collected from public online profiles, but this case goes above and beyond that.

The article examines a recent Connecticut divorce case, in which the presiding judge issued an injunction against a woman who asked a friend to delete sensitive information on her Facebook, Match and EHarmony accounts. The injunction followed a private matter in which the husband in question, Stephen Gallion, was given his wife Courtney’s passwords on the advice of her lawyer.

The injunction prohibits her from deleting any information from her accounts. The judge also admonished the two to not post anything to the other’s accounts.

What do you think about this idea? Is it necessary to establish in a divorce proceeding, or is it an egregious breach of privacy?

Watch out for WordPress plugin vulnerabilities

A vulnerable plugin in WordPress has become the recent target of automated attacks by hackers. WordPress plugins are unfortunately a common vulnerability source, because they are sometimes written by inexperienced PHP developers who are not necessarily security-minded, and this can lead to some embarrassing security mistakes.

The plugin in question is called Timthumb, which is a plugin for resizing images in WordPress. Timthumb has a gaping vulnerability in its file upload script that allows for arbitrary PHP code execution, and since it does not validate its upload form, the code could come from any source, including a malicious remote server.

The SpiderLabs blog has an in-depth analysis of an example payload culled from a honeypot machine loaded with a stock version of WordPress with the Timthumb plugin installed. The payload contains a forged GIF image header (to pass simple image validators), and then a PHP script which installs a backdoor application on the infected host. The backdoor can then be used to steal information from the machine, or force it to participate in a botnet.

If you use WordPress, it is imperative that you identify and uninstall any vulnerable plugins immediately using WPScan. Be on the lookout for security flaws in WordPress plugins, because they are a common target for hackers.

Critical security flaw in Windows 7, Vista, Server 2008

On November 8, a security bulletin was posted to the Microsoft Security TechCenter website. The bulletin, MS11-083, concerns a flaw in the way certain UDP packets are handled in the native Windows TCP/IP stack. The vulnerability is marked “Critical” because it could potentially open up a computer to Remote code execution, and it affects Windows 7, Windows Vista, and Windows Server 2008. However, the bulletin does not provide much information about the supposed security flaw. We will have to examine a relevant post to the Microsoft Security Research & Defense blog to determine the extent of this vulnerability.

“Assessing the exploitability of MS11-083” reveals the details of the security hole. The idea is as follows: If enough UDP packets are flooded to a closed port on a Windows host, it could cause an integer overflow in the reference counter in a part of the TCP/IP stack. Should such an overflow occur, the memory for the counter will be erroneously freed by the operating system. This could result in a crash of the operating system. It could also, in a worst-case scenario, cause the operating system to reference memory which has been overwritten with arbitrary instructions. However, this attack was determined to the Microsoft researchers to be “difficult to achieve.” Still, it is worth keeping in mind that some of the most cripping security holes have stemmed from the compound use of several smaller, innocuous flaws in the operating system and software.

A patch for MS11-083 is available to Windows users right now, and it is strongly suggested that those affected download and install the patch immediately.

Charlie Miller releases iPhone exploit

Security researcher Charlie Miller has released a proof-of-concept app for Apple iOS which is able to pull unsigned and untrusted code from a remote source and run it.

The reason this is troubling is: All apps that get published to the Apple store must be verified by Apple to not contain any malicious code. This is done through a process called Code signing. In the exploit Miller unveiled, an attacker would be able to pass a rogue app through the Apple store, then use it to contact a remote server and download and execute any arbitrary code from the server. A flaw such as this could result in a user’s private information being stolen by an Apple-approved app. This would decrease overall consumer confidence in Apple and might affect their stock price.

After the proof-of-concept was revealed to be an exploit, Apple responded by revoking Miller’s developer status. This is a controversial move, as Apple had three weeks after Miller disclosed the vulnerability to them to fix it. However, Miller’s app, Instastock, was in clear violation of the Terms of Service.

View the exploit in action here.

EFF Concerned About Security of HTTPS

Tuesday on the Deeplinks Blog on the Electronic Frontier Foundation website, an article titled “How secure is HTTPS today? How often is it attacked?” was published.

The EFF post doesn’t focus on bugs in specific implemenations of TLS that could allow forged certificates to be accepted in only a subset of vulnerable browsers. Rather, it tackles the number of ways a Certificate Authority (CA) could be compromised. A Certificate Authority publishes digital certificates, which are documents that assert that a public key indeed belongs to a given host. A modern web browser will trust certificates handed out by any one of over 600 CAs, and the compromisation of even one CA means that a malicious entity could pose as a trusted host, even if the trusted host has configured everything correctly.

The article lists the following ways a CA could be compromised:

  1. Using a vulnerability in the CA to sign your own certificates.
  2. Compromising network infrastructure near a CA to forge packets going in and out, thus forcing the CA to generate a certificate for you.
  3. Forging a DNS entry in a way that makes a domain point to your IP address.
  4. Spoofing TCP or BGP packets to route traffic for a domain to your IP.
  5. Having a government intervene on your behalf and ordering a CA to issue a certificate. (Trusted CAs, as a side note, are located in over 52 countries.)

This article should be a powerful wake-up call to anyone who thinks that HTTPS is a completely secure method for transporting data. SSL, when implemented and configured correctly, is fairly foolproof, but there is still no comprehensive way to verify the integrity of a DNS record or digital certificate. The article is part 1 of a series that promises to examine “the security of HTTPS and TLS/SSL.” It is definitely a series of posts to keep your eye on if you are concerned about security on the Web.