The scale of this incident somehow reminds me of the whole TJ MAXX fiasco a few years back.

Anyway, this whole scheme sounds like a case of people installed VNC with weak passwords and someone finding it by accident – it doesn’t even seem to have been a targeted hack.

For thousands of customers of Subway restaurants around the US over the past few years, paying for their $5 footlong sub was a ticket to having their credit card data stolen. In a scheme dating back at least to 2008, a band of Romanian hackers is alleged to have stolen payment card data from the point-of-sale (POS) systems of hundreds of small businesses, including more than 150 Subway restaurant franchises and at least 50 other small retailers. And those retailers made it possible by practically leaving their cash drawers open to the Internet, letting the hackers ring up over $3 million in fraudulent charges.

In an indictment unsealed in the US District Court of New Hampshire on December 8, the hackers are alleged to have gathered the credit and debit card data from over 80,000 victims.

“This is the crime of the future,” said Dave Marcus, director of security research and communications at McAfee Labs in an interview with Ars. Instead of coming in with guns and robbing the till, he said, criminals can target small businesses, “root them from across the planet, and steal digitally.”

The tools used in the crime are widely available on the Internet for anyone willing to take the risks, and small businesses’ generally poor security practices and reliance on common, inexpensive software packages to run their operations makes them easy pickings for large-scale scams like this one, Marcus said.

While the scale of this particular ring may be significant, the methods used by the attackers were hardly sophisticated. According to the indictment, the systems attacked were discovered through a targeted port scan of blocks of IP addresses to detect systems with a specific type of remote desktop access software running on them. The software provided a ready-made back door for the hackers to gain entry to the POS systems. The PCI Security Standards Council, which governs credit card and debit card payment systems security, requires two-factor authentication for remote access to POS systems—something the applications used by these retailers clearly didn’t have.

It seems like there’s a pretty large ring behind this operation, just due to the sheer number of locations compromised and the amount of time it must have taken to install all the malware and logging software.

Plus the network infrastructure that was build to receive the logs via FTP upload, the criminals were pretty smart too – they even ‘backed up’ their stolen data to sendspace just in case their hosting got taken down.

Once they were in, the hackers then deployed a collection of hacking tools to the POS systems, including logging software that recorded all the input into the systems—including credit card scans. They also installed a trojan, xp.exe, onto the systems to provide a back door to reconnect to the systems to allow the installation of additional malware, and prevent any security software updates.

Collected data from the loggers was posted by the malware to FTP “dump” sites on a number of Web servers in the US created with domains they registered through GoDaddy.com using stolen credit card data. In addition to using the stolen data to register their own domains and pay for hosting service, the hackers periodically rounded up the dumped transaction data and moved it to sendspace.com, a file transfer site. Richard James of sendspace.com says that his company cooperated with the FBI in the investigation of the hack. ” Sendspace [is] a file hosting and transfer site used by millions every single day,” he said in an email to Ars Technica,”and as such can indeed be used for activities which are against our TOS and that we do not condone.”

Some of the data was used to print counterfeit credit cards using blank plastic cards and embossing machines. One of the alleged hackers, Cezar Iulian Butu, was generating counterfeit cards with an embossing machine out of a house in Belgium in October of 2010, and working with a group, used the cards “among other uses [to] place bets at local French ‘tobacco’ shops,” the Justice Department said in its filing. The rest of the stolen data was sold in blocks to other criminals from the Sendspace server.

According to a report by Schuman, Subway’s corporate IT and a credit card company discovered the data breach “almost simultaneously.” Subway Corporate Press Relations Manager Kevin Kane told Ars that “the tech guys who dealt with this moved and put steps in place [to block the theft of data] as soon as they discovered it.” He said the company wouldn’t discuss the measures taken, as “we don’t want to give away the blueprint” to other potential attackers. And Kane added that Subway had been asked by the Justice Department not to comment on other details of the case, as it is part of an ongoing investigation.

It’ll be a pretty interesting case to watch either way, we’ll have to see what else gets discovered (and more importantly released to the public).

Subway corporate IT has taken some measures against this, but as it was franchisee stores that got owned – I don’t honestly see how much they can do. Unless they implement a complete new POS system (which is secure and preferably doesn’t run Windows and connect to the Internet).

POS in this case should well stand for Piece of Shit.

Source: Ars Technica

It’s a pretty bumper crop of patches though with 13 bulletins and 19 vulnerabilities fixed, the highest profile one being a patch for the zero-day vulnerability exploited by Duqu.

The pulling of the BEAST patch is good in a way though I guess, it shows that Microsoft are doing comprehensive compatibility testing to ensure the patches don’t cause any problems (including with 3rd party software).

Microsoft released 13 security bulletins addressing 19 vulnerabilities overnight, as part of a bumper final Patch Tuesday of the year.

Highlight of the baker’s dozen is a patch for the the zero-day vulnerability exploited by Duqu (sibling of Stuxnet) worm back in October. Fixing the underlying flaw exploited by Duqu involves the resolution of a problem in how Windows kernel mode driver handles TrueType font files.

Aside from this critical update the batch includes an update to address a critical flaw n Windows Media Player. A cumulative security update of ActiveX kill bits is covered by the third, and final, critical update this month. The other ten bulletins address less severe (important) flaws in Windows, IE and Office. Altogether its a desktop-heavy patch batch, as you can see from Microsoft’s summary here.

Microsoft originally promised 14 bulletins for the December edition of Patch Tuesday but one has been pulled, probably for quality control reasons. The original anticipated 14th bulletin was for the BEAST attack, but did not make it in time for the holidays due to a last minute software incompatibility uncovered during third party testing, security services firm Qualys reports. The absence of this fix means that Microsoft has issued a grand total of 99 bulletins this year, one less than the ton up that might have resulted in adverse headlines.

Both BEAST and Duqu are pretty nasty malware, I’d guess seen as though they’ve already fixed the BEAST problem – they just need to work on compatibility issues – that we’ll definitely be seeing the patch rolled out in the January Patch Tuesday.

It’s good to see a bunch of important patches rolled out pre Christmas though as there’s always an influx of malware, scams, spams and phishing attempts around this period (trying to leverage on people’s good will I guess).

The BEAST attack affects web servers that support SSLv3/TLSv1 encryption. Although a patch will have to wait until January, at least, Microsoft has already published a workaround, which involves using the non affected RC4 cipher in SSL setups.

The Internet Storm Centre has produced a helpful graphical overview of the Black Tuesday updates from Microsoft here. It reckons that some of the flaws are more severe than Redmond’s rating. By the ISC’s count there are EIGHT critical updates. Either way you look at it, this is a lot of patching work even before we think about other security updates doing the rounds.

Google and Adobe are also joining in on the season of giving by releasing updates of their own. Adobe last week issued a critical updates for Adobe Reader and Acrobat. The latest version of Adobe PDF-reading software, Adobe Reader X, is not affected by this vulnerability thanks to the use of sand-boxing technology. So users have the option to either upgrade or apply a patch to the earlier version of the software.

In addition, Google published an update to its Chrome browser that addresses 15 security flaws, including six high-risk vulnerabilities, on Tuesday. More details of what’s fixed inside Chrome 16.0.912.63, the latest cross-platform version of the browser (yes Mac and Linux fans you ought to update too), can be found here.

There has been some other nasty bugs around too with a zero-day for Adobe Reader last week and Google just released a massive update of Chrome including 6 high risk vulnerabilities.

SANS ISC as always gives a great summary of the patches and classifies some of them more seriously than Microsoft does – you can check out the details here:

December 2011 Microsoft Black Tuesday Summary

Source: The Register

It’s not really the smartest move as I’m pretty sure anyone as smart as Charlie Miller still has plenty of options – use another person’s account, sign up another account with a different identity, hack the phone without the developer program access and so on..

Really it’s quite a harsh move from Apple and it’s not going to make them any friends in the security industry.

Apple has banned well-known security researcher Charlie Miller from its developer program, for creating an apparently benign iOS app that was actually designed to exploit a security flaw he had uncovered in the firmware.

Within hours of talking about the exploit with Forbes’ security reporter Andy Greenberg, who published the details, Miller received an email from Apple: “This letter serves as notice of termination of the iOS Developer Program License Agreement … between you and Apple. Effective immediately.”

Based on Greenberg’s follow-up story, Apple was clearly within its rights to do so. Miller created a proof-of-concept application to demonstrate the security flaw and how it could be exploited by malicious code. He then hid it inside an apparently legitimate stock ticker program, an action that, according to Apple, “violated the developer agreement that forbid[s] him to ‘hide, misrepresent or obscure’ any part of his app,” Greenberg wrote.

He quoted Miller, who works for security consultancy Acuvant, “I’m mad. I report bugs to them all the time. Being part of the developer program helps me do that. They’re hurting themselves, and making my life harder.”

In a way though, you have to agree that Miller did violate the very specific developer program agreement by hiding the PoC inside a legitimate application. That probably wasn’t his smartest idea, but then again it’s helping Apple and he’s not doing it in a malicious way to infect people – he’s doing it as a security researcher.

Apple should be more proactive on working with people like this, people who are actually fixing bugs in their products for free and improving the user experience.

It’s the way Apple operates though, secretive, exclusive, domineering etc. If you don’t do things their way, screw you.

Miller, a former National Security Agency staffer, is a well-known “white hat” hacker (he made Network World’s recent list of “Security All Stars”), with expertise in Apple’s Mac OS X and iOS platforms, including the Safari browser, and in Android. Miller “has found and reported dozens of bugs to Apple in the last few years,” Greenberg noted. Miller reported the latest one barely three weeks ago, and it was Greenberg’s public account of it yesterday, in advance of a planned public presentation by Miller next week, that got the researcher kicked out of the developer program.

The vulnerability is a fascinating exercise in information security sleuthing. Miller uncovered a flaw introduced in Apple’s restrictions on code signing on iOS devices. Code signing is a process by which only Apple-approved commands run in device memory, according to Greenberg’s account.

Miller began to suspect a flaw when Apple released iOS 4.3 in March. He realized that to boost the speed of the mobile Safari browser, Apple for the first time had allowed javascript code from a website to run at a deeper level in memory. This entailed creating a security exception, allowing the browser to run unapproved code. According to Greenberg’s story, Apple created other security restrictions to block untrusted websites from exploiting this exception, so that only the browser could make use of it.

Miller wasn’t the only one to notice that Apple had done something different with Safari in iOS 4.3, but many didn’t understand what was actually happening. Various news sites and bloggers claimed that Web apps running outside of Safari, and its new Nitro javascript engine, were slower. Some suggested that Apple was deliberately slowing them down to make Web apps less attractive than native ones.

The way in which Miller uncovered the flaw once again shows his technical brilliance – something which Apple really should be harnessing rather than turning away.

A lot of people noticed changes with iOS 4.3, but couldn’t actually figure out what was going on. Well that’s what we know in the public realm anyway, no doubt the bad guys had their eyes on it and were digging in with much more malicious exploits.

It basically seems like a way to bypass any kind of code validation by Apple and execute arbitrary code from an attack server – dangerous indeed.

Source: Network World

REC Studio 4 is a complete rewrite of the original REC decompiler. It uses more powerful analysis techniques such as partial Single Static Assignment (SSA), allows loading Mac OS X files and supports 32 and 64 bit binaries.

Although still under development, it has reached a stage that makes it more useful than the old Rec Studio 2.

Features

• Multihost: Rec Studio runs on Windows XP/Vista/7, Ubuntu Linux, Mac OS X.
• Symbolic information support using Dwarf 2 and partial recognition of Microsoft’s PDB format.
• C++ is partially recognized: mangled names generated by gcc are demangled, as well as inheritance described in dwarf2 is honored. However, C++ is a very broad and difficult language, so some features like templates won’t likely be ever supported.
• Types and function prototype definitions can be specified in text files. Some standard Posix and Windows APIs are already provided in the Rec Studio package.
• Interactivity is supported, limited to definition of sections, labels and function entry points. Will need to improve it to support in-program definition of types and function parameters.

Although REC can read Win32 executable (aka PE) files produced by Visual C++ or Visual Basic 5, there are limitations on the output produced. REC will try to use whatever information is present in the .EXE symbol table. If the .EXE file was compiled without debugging information, if a program data base file (.PDB) or Codeview (C7) format was used, or if the optimization option of the compiler was enabled, the output produced will not be very good. Moreover, Visual Basic 5 executable files are a mix of Subroutine code and Form data. It is almost impossible for REC to determine which is which. The only option is to use a .cmd file and manually specify which area is code and which area is data.

You can download Rec Studio 4 here:

Windows – RecStudioWin.zip
Ubuntu – RecStudioLinux.tgz
Mac – RecStudioMac.tgz

Or read more here.

And well even then, it’s not totally safe as apparently you can farm out your CAPTCHA cracking (those the fail the automated attempts) to India for a few dollars. It does help cut down on sign-ups and bot spam – but it’s certainly not fool proof.

The report just reinforces my stance proving that 13 out of 15 popular captures could be cracked with automated software.

Security researchers have discovered the vast majority of text-based anti-spam tests are easily defeated.

Computer scientists from Stanford University discovered 13 of 15 CAPTCHA schemes from popular websites were vulnerable to automated attacks. The CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) has been used for several years to prevent automated sign-ups to webmail accounts or online forums in order to block spam bots. Surfers are typically asked during a registration process to identify distorted letters as depicted in an image. A variety of other approaches – including pictures of cats, audio clips and calculus puzzles – have been applied to the problem over the years.

Cybercrooks have responded to the challenge posed by CAPTCHAs by devising techniques that typically involve semi-automatically signing up for new accounts, while relying on the human cogs in 21st century sweatshops – typically located in India – to solve the CAPTCHA puzzles themselves.

The Stanford team, by contrast, looked at whether it was possible to fully automate the process of breaking CAPTCHAs. Their techniques including removing deliberately introduced image background noise and breaking text strings into single characters for easier recognition. The team built an automated tool, called Decaptcha, that applied these various tricks. The approach was partially inspired by techniques used to orientate robots in unknown environments.

It’s interesting to see an academic take on this subject though as it’s usually the realm of blackhats and hobbyists. I’m sure with a fair bit of science they did an excellent job at removing the ‘noise’ that most CAPTCHA systems tend to add to the image to try and foil automatic solving.

I’m also glad to see reCAPTCHA once again stood up well to automated cracking, you’d have to rely on the sweatshops to get past that.

The worst seems to be Authorize.net from VISA – which is surprising and also sad as it’s dealing with banking.

Decaptcha was turned against the challenge response CAPTCHAs used by 15 high-profile websites, enjoying excellent bowling figures against the majority.

For example, Visa’s Authorize.net payment gateway CAPTCHA was defeated 66 per cent of the time. eBay’s CAPTCHA was sidestepped 43 per cent of the time. Lower, but still workable, bypass rates were achieved against Wikipedia, Digg and CNN.

Google and reCAPTCHA were the only two CAPTCHA systems that consistently thwarted Decaptcha during the tests.

Authorize.net and Digg have both switched to reCAPTCHA since these tests were run, Computerworld adds.

In a research paper (PDF), the Stanford team suggest several approaches towards making CAPTCHAs harder to beat, including making the length of a text string changeable and randomising character font and size. Lines in the background of CAPTCHAs might also prove effective. In addition, the Stanford team highlighted features that are ineffective against automated attacks but may counter the activities of humans.

The researchers, Elie Bursztein, Matthieu Martin and John C Mitchel, who previously developed techniques for breaking audio CAPTCHAs, presented their latest research at the recent ACM Conference On Computer and Communication Security in Chicago.

Fortunately both Authorize.net and Digg have switched to reCAPTCHA since this report came out making them safer, it’s probably a case of responsible disclosure by the Stanford scientists.

It’s definitely worth a read if you have anything to do with CAPTCHA implementation and especially relevant if you are thinking of developing your own rather than just using something like reCAPTCHA.

You can grab the full report here:

text-based-captcha-strengths-and-weaknesses.pdf

Source: The Register

Well this time the private messaging function has been compromised, you can attach an executable and send it to anyone as long as you put a space after the filename.

It’s not the first time I’ve seen a mime/file/etc parser be owned by a space, but I expected better from Facebook to be honest.

A security penetration tester discovered a major flaw in Facebook that could allow a person to send anyone on the social-networking site malicious applications.

Nathan Power, a senior security penetration tester at technology consultancy CDW, discovered the vulnerability and publicly disclosed it Thursday on his blog. The flaw was reported to Facebook on Sept. 30, which acknowledged the issue on Wednesday, he wrote.

Power, who could not immediately be reached, wrote that Facebook does not normally allow a person to send an executable attachment using the “Message” tab. If you try to do that, it returns the message “Error Uploading: You cannot attach files of that type.”

Facebook has acknowledged the bug (which is a pretty serious one) but it’s unknown if they’ve actually fixed it yet or not.

You can see the original blog post outlining the vulnerability here:

Facebook Attach EXE Vulnerability

Good job Nathan Power!

Power wrote that an analysis of the browser’s “POST” request sent to Facebook’s servers showed that a variable called “filename” is parsed to see if a file should be allowed. But by simply by modifying the POST request with a space just after the file name, an executable could be attached to the message.

“This was enough to trick the parser and allow our executable file to be attached and sent in a message,” Power wrote.

A person would not have to be an approved friend of the sender, as Facebook allows people to send those who are not their friends messages. The danger is that a hacker could use social engineering techniques to coax someone to launched the attachment, which could potentially infect their computer with malicious software.

Facebook representatives contacted in London did not have an immediate response on Thursday afternoon.

The dangerous part I can see here is that Facebook allows users to send messages to anyone (with attachments) even if they are not friends. Which makes me wonder, how many random guys are sending girls they don’t know pictures of their junk as attachments on Faceobok messages…

I don’t want to know really.

Anyway this should be a fairly simple fix for Facebook and I’d imagine they have probably already fixed this or will be doing so fairly soon.

Source: Network World

This attack further exploits the SSL secure Renegotiation feature to trigger thousands of renegotiations via single TCP connection.

Usage

./thc-ssl-dos 127.3.133.7 443
Handshakes 0 [0.00 h/s], 0 Conn, 0 Err
Secure Renegotiation support: yes
Handshakes 0 [0.00 h/s], 97 Conn, 0 Err
Handshakes 68 [67.39 h/s], 97 Conn, 0 Err
Handshakes 148 [79.91 h/s], 97 Conn, 0 Err
Handshakes 228 [80.32 h/s], 100 Conn, 0 Err
Handshakes 308 [80.62 h/s], 100 Conn, 0 Err
Handshakes 390 [81.10 h/s], 100 Conn, 0 Err
Handshakes 470 [80.24 h/s], 100 Conn, 0 Err

Comparing flood DDoS vs. SSL-Exhaustion attack

A traditional flood DDoS attack cannot be mounted from a single DSL connection. This is because the bandwidth of a server is far superior to the bandwidth of a DSL connection: A DSL connection is not an equal opponent to challenge the bandwidth of a server.

This is turned upside down for THC-SSL-DOS: The processing capacity for SSL handshakes is far superior at the client side: A laptop on a DSL connection can challenge a server on a 30Gbit link. Traditional DDoS attacks based on flooding are sub optimal: Servers are prepared to handle large amount of traffic and clients are constantly sending requests to the server even when not under attack.

The SSL-handshake is only done at the beginning of a secure session and only if security is required. Servers are _not_ prepared to handle large amount of SSL Handshakes. The worst attack scenario is an SSL-Exhaustion attack mounted from thousands of clients (SSL-DDoS).

Tips & Tricks for Whitehats

1. The average server can do 300 handshakes per second. This would require 10-25% of your laptops CPU.
2. Use multiple hosts (SSL-DOS) if an SSL Accelerator is used.
3. Be smart in target acquisition: The HTTPS Port (443) is not always the best choice. Other SSL enabled ports are more unlikely to use an SSL Accelerator (like the POP3S, SMTPS, … or the secure database port).

Counter measurements

No real solutions exists. The following steps can mitigate (but not solve) the problem:

1. Disable SSL-Renegotiation
2. Invest into SSL Accelerator

Either of these countermeasures can be circumventing by modifying THC-SSL-DOS. A better solution is desireable. Somebody should fix this.

You can download THC-SSL-DOS here:

Windows: thc-ssl-dos-1.4-win-bin.zip
Linux: thc-ssl-dos-1.4.tar.gz

Or read more here.

winAUTOPWN and bsdAUTOPWN are minimal Interactive Frameworks which act as a frontend for quick systems vulnerability exploitation. It takes inputs like IP address, Hostname, CMS Path, etc. and does a smart multi-threaded portscan for TCP ports 1 to 65535. Exploits capable of giving Remote Shells, which are released publicly over the Internet by active contributors and exploit writers are constantly added to winAUTOPWN/bsdAUTOPWN. A lot of these exploits are written in scripting languages like python, perl and php. Presence of these language interpreters is essential for successful exploitations using winAUTOPWN/bsdAUTOPWN.

Exploits written in languages like C, Delphi, ASM which can be compiled are pre-compiled and added along-with others. On successful exploitation winAUTOPWN/bsdAUTOPWN gives a remote shell and waits for the attacker to use the shell before trying other exploits. This way the attacker can count and check the number of exploits which actually worked on a Target System.

This version covers almost all remote exploits up-till September 2011 and a few older ones as well. Also added in this release are a few ruby exploits which require ‘socket’ alone for interpretation. Gee-Hence, winAUTOPWN now requires ruby installed as well, just like perl, python and php.

This version incorporates a new command-line parameters: -targetOS to allow selection of the target Operating System. This is essential for a few exploits to work perfectly. The List of OS and the corresponding OS codes are available and asked when winAUTOPWN OR bsdAUTOPWN is executed.

Untill the last release there was only a bind_shell TCP shellcode available in the exploits. This release brings yet another feature which gives the freedom to choose from a variety of shellcodes. You can now select reverse_tcp for Windows cmd and other shellcodes for Solaris, Linux, FreeBSD, etc. This is all done by mod_shellcode which has been created and added to WINDOWS AUTOPWN and BSD AUTOPWN as well. mod_shellcode gets automatically invoked by WINDOWS AUTOPWN for every scripted exploit code whose shellcode can be manually changed. Note that there are a few exploits in a compiled binary form which lack reverse shell and other shellcode features.

mod_shellcode is available as a separate binary in the exploits/ directory for Windows, FreeBSD x86, FreeBSD x64 and DragonFly BSD platforms (just like the main BSD AUTOPWN and other exploit binaries) and hence can also be manually used by exploit writers and exploiters to quickly change shellcodes in their exploit files.

You can download winAUTOPWn v2.8 here:

winAUTOPWN_2.8.7z

And well because the site is always down, I’ve uploaded a mirror copy here:

winAUTOPWN_2.8.7z (FileSonic)

Or read more here.

It’s basically a HTTP referer detection system for the Facebook URL scanner (the thing that generates the preview/thumbnail etc for links posted to Facebook). By detecting it, you can feed it something benign – but when a normal user comes – feed them some malware.

So be careful what you click in Facebook, or Google+ or anything else that gives you a preview but doesn’t really show you the URL or what is on the page.

Members of a hacking think-tank called Blackhat Academy claim that Facebook’s URL scanning systems can be tricked into thinking malicious pages are clean by using simple content cloaking techniques.

Such attacks involve Web pages filtering out requests that come from specific clients and feeding them content that is different from what is displayed to regular users.

Attackers have been using this method to poison search results on Google for years now by serving keyword-filled pages to its indexing robot, but redirecting visitors to malware when they click on the links. However, it turns out that Facebook is also vulnerable to this type of content forging. “Hatter,” one of the Blackhat Academy members, provided a live demonstration, which involved posting the URL to a JPEG file on a wall.

Facebook crawled the URL and added a thumbnail image to the wall post, however, clicking on its corresponding link actually redirected users to YouTube. This happened because the destination page was able to identify Facebook’s original request and served a JPEG file.

“While most major sites that allow link submission are vulnerable to this method, sites including Websense, Google+ and Facebook make the requests easily identifiable,” the Blackhat Academy hackers said.

This kind of technique is VERY popular in the Blackhat SEO world, or at least it was back in the day – you could feed pages to the search engines that weren’t really human readable, but they were perfect in terms of link density, keywords and so on for Google and other search engines.

When humans visited, they’d get the normal page – when search bots visited they’d get a specially tailored version to hike the page up in the rankings. I’m not sure if it goes on (Google is a hell of a lot smarter now) – but I’d be surprised if it’s totally gone.

Websense of course are claiming that it doesn’t really effect them due to the all the l33t techniques they use to filter URLs…cool story bro.

“These sites send an initial request to the link in order to store a mirror thumbnail of the image, or a snapshot of the website being linked to. In doing so, many use a custom user agent, or have IP addresses that resolve to a consistent domain name,” they explained.

Earlier this week, Facebook signed a partnership with Websense to use the security vendor’s cloud-based, real-time Web scanner for malicious URL detection. Blackhat Academy has now provided proof-of-concept code, which, according to its advisory, can be used to bypass it.

Websense doesn’t believe that to be the case. “This is nothing new. We use numerous methodologies and systems to ensure that our analysis of content (in real time) is not manipulated by malware authors, including using IP addresses not attributable to Websense so that malware authors are unaware that it is Websense analyzing the content,” the company said.

“Also, the Websense ThreatSeeker Network is fed via an opt-in feedback loop from tens of thousands of customers distributed globally. These IPs are also not attributable to Websense.com. It is because of technologies like this that Facebook chose Websense to provide protection for their growing user base of more than 750 million users,” it added.

That could well be true, but it’s worth keeping in mind that Websense primarily sells security solutions to businesses and Facebook is usually blocked on many corporate networks. It would be logical to assume that relying on its customers’ appliances to scan URLs on the social networking website might not have an immediate impact.

I know Facebook have signed the agreement, but have they started using Websense filtering yet? We did write something about their collaboration last year – Websense Offers Facebook Users Free ‘Firewall’ Service.

Well if it keeps Facebook users safe from malware, and stops us having to fix more computers for our friends and relatives – it’s good in my books.

We will have to wait and see though until it’s fully implemented if it stops the next round of Facebook malware from sprouting and running riot.

Source: Network World

It appears to be in the clear now though and it’s accessible again via Google. It seems to be a similar case with that of the recent Linux.com and Kernel.org hacks – in which the sites were compromised via developers who had access.

In this case it seems MySQL.com was compromised by malware that spreads itself via FTP from client machines, it then uploads malicious JavaScript to any sites the client machine has access to and propagates malware using those sites.

Hackers recently compromised the website hosting the open-source MySQL database management system and caused it to infect the PCs of visitors who used unpatched browsers and plug-ins, security researchers said.

MySQL.com was infected with mwjs159, website malware that often spreads when compromised machines are used to access restricted FTP clients, a blog post from Sucuri Security reported. The hack caused people visiting the site to be redirected to a site that attempted to install malware on visitors’ computers using code from the Blackhole exploit kit, separate researchers from Armorize said.

“It exploits the visitor’s browsing platform (the browser, the browser plugins like Adobe Flash, Adobe PDF, etc, Java, …), and upon successful exploitation, permanently installs a piece of malware into the visitor’s machine, without the visitor’s knowledge,” Armorize researchers warned. “The visitor doesn’t need to click or agree to anything; simply visiting mysql.com with a vulnerable browsing platform will result in an infection.”

Officials with the Oracle-owned MySQL didn’t respond to email seeking comment for this post.

I would say MySQL.com is a fairly high traffic site so this attack may have triggered a fair amount of infections – especially if the people visiting were using outdated versions of Windows or old versions of Internet Explorer.

But then again, I’d find that fairly unlikely – people browsing to the site of the #1 Open Source RDBMS would most likely be using Linux, or fully updated Windows systems with Chrome or Firefox.

That’s what I’d like to think anyway…

The reported breach is the latest to affect the distribution system for a widely used piece of open-source software. The kernel.org and Linux.com websites used to develop and distribute the Linux operating system remain inaccessible four weeks after it was infected with malware that gained root access, modified system software, and logged passwords and transactions of the people who used them. Representatives haven’t said when they expect the sites to be operational again.

Besides sullying the reputation of open-source software as more secure alternative to competing applications from Microsoft and other for-profit companies, the compromises have sparked concerns about the purity of the code the sites host. If attackers were able to secretly alter the code with backdoors, they could potentially surveil or gain control over sensitive networks that rely on the applications.

In the MySQL.com hack, the attackers appear to have aimed for the less ambitious goal of infecting the desktop machines of those who visited the site. At time of writing, just five of the top 44 antivirus providers were detecting the threat, according to this analysis from VirusTotal.

Sucuri speculated the site was infected after a MySQL developer was compromised and had his password stolen.

It doesn’t seem to be as serious as the Linux.com/Kernel.org compromises as in this case it’s simply JavaScript uploaded via FTP from a developer account – the actual server hosting MySQL.com wasn’t really hacked and there was no root access gained.

It seems like they have cleared the infection up now, I wonder if they have any stats on how many people were effected by the malware?

Source: The Register