A Forbes.com 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?
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.
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.
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.
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:
- Using a vulnerability in the CA to sign your own certificates.
- Compromising network infrastructure near a CA to forge packets going in and out, thus forcing the CA to generate a certificate for you.
- Forging a DNS entry in a way that makes a domain point to your IP address.
- Spoofing TCP or BGP packets to route traffic for a domain to your IP.
- 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.
A worm is currently affecting older versions of the JBoss enterprise application server. JBoss is a popular implementation of the Java EE enterprise platform owned by Red Hat.
The worm attempts to connect to a JMX console on a JBoss server. JMX is a Java-related standard that aids the management of Java EE applications. Due to a bug in the default JMX configuration file in JBoss, only HTTP GET and POST commands to the JMX server are authenticated. The worm takes advantage of this by sending a HTTP HEAD request with a malicious payload that opens a back door on the management server. Then, the worm uploads a few Perl and Windows Batch files that scan for other vulnerable hosts and infect them as well. The worm also attempts to make the infected machine part of a botnet.
To protect themselves against this worm, JBoss users are urged to immediately upgrade to the newest version. A patch that will fix this vulnerability was released in April 2010. Alternatively, a user can delete two lines in the JMX configuration file which will force authentication for all HTTP requests and thwart the worm.
The relevant security patch can be found here. An analysis of the worm can be found here.
Last Wednesday, two cryptographers at the ACM Conference on Computer and Communications Security demonstrated a successful attack against XML Encryption. XML Encryption is a W3C Standard, which means that for the most part it ought to be well-tested, secure and fairly unbreakable. The W3C name carries no small amount of weight and the fact that XML Encryption is a standard that they endorse means that many companies have implemented it and are using it currently.
XML Encryption is a standard that allows an XML message to contain one or more
elements that can only be read by a trusted party. It is different than Transport Layer Security in that only part of the message is encrypted, not all of the message. The attack that the two researchers, Juraj Somorovsky and Tibor Jager, unveiled involves manipulating the contents of a known cyphertext, passing them to the server, and analyzing the resulting error message enough times to be able to decode the encrypted data. The attack was tested against a number of XML Encryption implementations.
This attack ought to make companies that use XML Encryption as part of their enterprise solution rethink their security methods. It doesn’t seem as though this issue will be “fixed” within the standard any time soon, so companies should be urged to switch to another encryption method.
The press release can be found here.