Snapchat images stolen from third-party Web app using hacked API

A screenshot of the log-in for, a failed (or perhaps malicious) web-based front end for Snapchat that saved users' private images and allowed them to be hacked.

A cache of about 13 gigabytes of stolen images from Snapchat—some of them apparently of nude, underage users of the “ephemeral” messaging platform—was posted online Thursday night, many of them to the image-sharing site 4chan’s /b/ discussion board. However, the threads linking to the images have largely been shut down by 4Chan over concerns of trafficking in what could be considered child pornography. Over 100,000 user images and videos were in the cache, according to 4chan discussions.

The images are apparently not from Snapchat’s own network but from the database of a third-party application that allows Snapchat users to save images and videos sent over the service online. In an official statement to the press, a Snapchat spokesperson said, “We can confirm that Snapchat’s servers were never breached, and were not the source of these leaks. Snapchatters were victimized by their use of third-party apps to send and receive Snaps, a practice that we expressly prohibit in our Terms of Service precisely because they compromise our users’ security.”

According to a report by Business Insider, 4chan users who gained access to the images downloaded them and started to create a searchable database indexed by the usernames associated with the images. The files were also briefly hosted on a Web server that hosted Web exploits and malware.

Read 6 remaining paragraphs | Comments

6Scan Is Bad At Detecting Malicious Code

From dealing with lots of hacked websites one of things that we know is that detecting malicious code through automated processes isn’t very effective. The variety of code makes it difficult, but what makes it much more difficult is that often the code appears to be designed to be able to avoid detection from these automated processes (which in turn usually makes it easy for a human to spot). Unfortunately other companies dealing hacked website haven’t figured this out or are not interested in making sure the websites they deal with get fully cleaned and secured, leading to many instances where we are hired to re-clean up hacked websites after they have failed to get the job done. One of the latest examples we saw was of a web host using 6Scan on a hacked website. 6Scan describes their services as “Powerful Automated Website Protection” and they describe their ability find malicious code with the following, “You might not be aware if your site has already been compromised, but our scanner will recognize the traces hackers leave behind. You’ll see immediate results—as comprehensive as they are easy to understand—displayed on our dashboard.”. Though, from what we saw it is at least a rather poor malicious code scanning tool.

At the point we were brought what had happened is that the web host for the website would detect the website was sending spam emails, suspend it, run 6Scan on it and remove the files they detected as malicious, and then after some amount of time spam email would get sent out again and the process would start over. What a quick check of the website’s files showed was that 6Scan was not detecting much of the malicious code and that meant the hacker still had access after the code they were detecting was removed. Considering that the web host in question is touted on 6Scan’s homepage as one of their “Trusted Partners” we don’t think that they were doing something wrong in use of the tool that lead to the poor detection.

The 6Scan scan that was run right before we did our clean up detected 54 files with malicious code and missed the malicious code in 40 other files, so their detection rate was not very good at only 57 percent. What was more surprising is how easy to spot most of the files they missed were. Many of the files were stored in the wp-admin and wp-includes directories of a WordPress website. Since those two directories generally should only contain files that come with WordPress any additional files would be a red flag. In other cases malicious code was added to core WordPress files that shouldn’t be modified, which also would be a red flag. In both cases someone reviewing the results of a file comparison with a clean install of WordPress would have easily noticed the malicious code, while 6Scan’s automated processes did not.

There are a few of important takeaways from this. First, if someone says they are going to clean up a hacked website with automated tools, you are going to want to find someone else to do it. You might get lucky with a hack that is rather simple and the malicious code gets fully detected, but if you don’t then it is going to mean multiple cleanups and in some cases more problems. It also important to hire someone that will determine how the website was hacked in the first place, as doing that and fixing the vulnerability is the way to protect against the hack happening again (that was certainly important for us to fully clean up the website in this instance). The final one is that you should avoid 6Scan as they either don’t understand that the service they provide can’t do what they claim or they know that it can’t don’t care. Instead you should spend your time and money on making sure you do things that will actually protect your website from being hacked in the first place, so someone like us doesn’t have to clean up after it gets hacked.

Poor punctuation leads to Windows shell vulnerability

A class of coding vulnerabilities could allow attackers to fool Windows system administrators into running malicious code because of a simple omission: quotation marks.

The attack relies on scripts or batch files that use the command-line interface, or "shell," on a Windows system but contain a simple coding error—allowing untrusted input to be run as a command. In the current incarnation of the exploit, an attacker appends a valid command onto the end of the name of a directory using the ampersand character. A script with the coding error then reads the input and executes the command with administrator rights.

"The scenario... requires a ‘standard’ user with access rights to create a directory to a fileserver and an administrator executing a vulnerable script," Frank Lycops and Raf Cox, security researchers with The Security Factory, said in an e-mail interview. "This allows the attacker to gain the privileges of the user running the script, thus becoming an administrator."

Read 5 remaining paragraphs | Comments

HP accidentally signed malware, will revoke certificate

Hewlett-Packard has alerted some customers that it will be revoking a digital certificate used to sign a huge swath of software—including hardware drivers and other software essential to running on older HP computers. The certificate is being revoked because the company learned it had been used to digitally sign malware that had infected a developer’s PC.

An HP executive told security reporter Brian Krebs that that the certificate itself wasn’t compromised. HP Global Chief Information Security Officer Brett Wahlin said that HP had recently been alerted to the signed malware—a four-year old Windows Trojan—by Symantec. Wahlin said that it appears the malware, which had infected an HP employee's computer, accidentally got digitally signed as part of a separate software package—and then sent a signed copy of itself back to its point of origin. Though the malware has since been distributed over the Internet while bearing HP's certificate, Wahlin noted that the Trojan was never shipped to HP customers as part of the software package.

“When people hear this, many will automatically assume we had some sort of compromise within our code signing infrastructure, and that is not the case,” Wahlin told Krebs. “We can show that we’ve never had a breach on our [certificate authority] and that our code-signing infrastructure is 100 percent intact.”

Read 1 remaining paragraphs | Comments