14 DAY TRIAL // RBS WorldPay is currently banging heads with a grey hat hacker over the seriousness of SQL injection vulnerabilities that he discovered on its websites. Meanwhile, another web developer exposed a cross-site scripting weakness in a site belonging to the company in order to prove that its efforts to mitigate XSS are not only inefficient, but also misguided.
A prominent grey hat hacker calling himself Unu, who has made a habit of revealing SQL injection vulnerabilities in high profile websites since the beginning of this year, is contesting RBS WorldPay's assertion that a recent flaw he reported could have not been used to access sensitive information.
On September 10, the Romanian hacker published an article on his blog accompanied by partially blotted screen shots, documenting a proof-of-concept SQL injection attack against a website belonging to RBS WorldPay. The hacker noted that he had full access to the database through the vulnerable website, but also remotely because a MySQL user was not password-protected and was not restricted to any specific host, which is a major security oversight.
The company maintained that the database in question contained dummy data and was only used for a test site. Upset with this response, Unu dug further and revealed a new SQLi in a different website belonging to RBS WorldPay, only to have the company downplay the seriousness of his findings again.
"Any information the unauthorised third party found would not provide access to either merchants or cardholder accounts," an RBS WorldPay spokesperson said, according to The Register. The hacker begs to differ and says he had access to a lot more databases this time around. We cannot confirm this claim, but judging by the full list of databases published, it was not just testing data.
In addition to Unu's findings, a web developer and security enthusiast named Philip Clarke has exposed an XSS weakness on an RBS WorldPay website. Mr. Clarke is the maintainer of an WorldPay-related add-on for a popular e-commerce platform called Zen Cart.
Clarke's module allows Zen Cart webmasters to integrate WorldPay's payment gateway into their websites. However, some major modifications recently made by the company to its system have seriously affected his application's functionality.
At the middle of the problems seems to be a tag whitelisting solution, which was implemented to mitigate XSS attacks, but breaks merchant websites built with Zen Cart. According to WorldPay customer support, the changes have been made to strengthen security as part of the company's PCI DSS re-certification efforts.
"What I find remarkable is that I think these modifications are entirely unnecessary," says Mr. Clarke, who in under ten minutes located an XSS weakness on the company's website, despite this protection. "This smacks of somebody not thinking things through, incorrect interpretation of a middle management instruction or misunderstanding the concepts," he concludes.
RBS WorldPay is a division of the Royal Bank of Scotland, which provides payment processing solutions for a large variety of retailers. Back in December 2008, its US branch announced a data breach that affected 1.5 million cardholders. An official investigation later revealed that the incident was part of one of the largest international credit card fraud operation in history.
Sources in the FBI explained that criminals succeeded in removing the normal limits imposed on 100 credit cards whose details were stolen during the RBS WorldPay breach and create fake copies, which were then used to withdraw a jaw-dropping $9 million. The cards were used at over 130 different ATM machines in 49 cities worldwide during a 30-minute period on November 8.
This incident has led to VISA removing RBS WorldPay from its list of providers compliant with the Payment Card Industry's Data Security Standard (PCI DSS). However, despite not being certified, the company has since succeeded in securing a contract with the Internal Revenue Service (IRS) to process tax-return payments beginning on January 20, 2010.
As far as SQL injection attacks go, they are the result of failure to properly sanitize parameters passed through URLs. Such flaws can allow an attacker to execute queries against the underlying database by using the website's credentials, which generally have both read and write permissions.
However, what the various public relations people sent forth to dismiss them as simple programming errors will never say is that they can also serve as the perfect point of entry for much larger attacks. As revealed in the indictments against Albert Gonzales, the hacker charged for hacking into TJX, 7-Eleven, Hannaford Bros. and Heartland Payment Systems, SQL injection was one of his preferred methods of penetrating secure networks.
In this scenario, SQL injection would first be used to hack into an Internet-facing server that hosts a website. This would give the attacker a major advantage, because once they have control of that machine, they can launch attacks against servers located on the internal network.
While these computers would normally be protected by firewalls from remote attacks originating on the Internet, the traffic on the local area network is most of the times trusted by default. This means that an attacker can pretty much run free exploiting other types of vulnerabilities in servers from the inside until they are able to intercept and capture sensitive data; and all of this because of that "simple" SQL injection flaw.