David Litchfield's Weblog

Home
Archives
NGSSoftware
DatabaseSecurity.com


Greymatter Forums

October 2007
SMTWTFS
  1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30 31      

Valid XHTML 1.0!

Powered By Greymatter

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.1
Wednesday, October 31st

0wned by the lowly Oracle rowid pseudo function?


SQL> select rowid,x from test;
ROWID X
------------------ --------------------
AAAM9ZAABAAAO6CAAA Test1
AAAM9ZAABAAAO6CAAB Test2
AAAM9ZAABAAAO6CAAC Test3
AAAM9ZAABAAAO6CAAE Test5

Notice anything odd? That's right there's no "Test4". Notice anything else? Looking at the last letter of the rowid we see they go from A to B to C to E. There's no D. Now, if the "test" table were protected by a virtual private database we could assume that there *is* a "Test4" but we just can't see it because the VPD isn't letting us. (Or it could mean that the "Test4" row has been deleted but forget that for the moment...assume the row is there.) In other words we can infer something about data we're not allowed to see. This can lead to a security risk. In all fairness this probably affects 0 people out there but it's interesting none the less and when designing database applications, especially those that protect critically sensitive information, we need to be wary of things like this. Even the lowly rowid function can punch a hole through the best laid security plans.
David on 10.31.07 @ 11:01 PM GMT [link]


Tuesday, October 30th

Memory-resident backdoors in Oracle / Deepsec conference.


I finished my code for the upcoming Deepsec conference in Vienna (November 20th-23rd). I'm presenting a discussion on memory-resident backdoors in Oracle (I will refrain from calling them "rootkits"). The code I wrote exploits a buffer overflow using ASCII armoured shellcode that dynamically creates a decoder which decodes the backdoor and then executes it. The talk will present this and look at potential defences. As the backdoor never touches the file system or any database objects it's much harder to spot than previously presented Oracle "rootkits". See you in Vienna - be there or be square wink

David on 10.30.07 @ 02:02 PM GMT [link]


Monday, October 29th

Reinventing the wheel... and Oracle passwords


Don't you just hate it when you spend a whole day doing something just to find out someone's already done it and you could've saved yourself a heap of effort? Whilst researching/debugging/disassembling for a chapter for the Oracle Forensics book I'm writing I got held up delving into the guts the 10g authentication mechanism - only to find that someone's already kindly done a lot of the work - thanks Laszlo smile If you're interested in Oracle stuff take a read.
David on 10.29.07 @ 11:24 AM GMT [link]


Sunday, October 28th

UK Data Security Breach Notification law put on ice?


According to the Government's response to the Personal Internet Security report they don't believe a UK Data Security Breach Notification law is justified right now:

"11. We further believe that a data security breach notification law would be
among the most important advances that the United Kingdom could make in
promoting personal internet security. We recommend that the Government,
without waiting for action at European Commission level, accept the principle
of such a law and begin consultation on its scope as a matter or urgency.


The Government provided evidence to the Committee that recognised that the move
towards breach notification laws in other jurisdictions was an interesting
development. We are, however, clearly not so convinced as the Committee that this
would immediately lead to an improvement in performance by business in regard to
protecting personal information and we do not see that it would have any significant
impact on other elements of personal internet safety. The experience in the United
States has yet to be fully analysed but there is a strong body of opinion that doubts
whether there has been significant differences to corporate behaviour and may, in
fact, have desensitised consumers to security issues and undermined confidence in
the internet as a business medium."


David on 10.28.07 @ 08:36 AM GMT [link]


Computer Misuse Act Section 3a clarification


The Police and Justice Bill 2006 made some ammendments to the UK's Computer Misuse Act. Specifically the new Section 3A essentially criminalised the development, ownership or distribution of hacking tools. Such tools have legitimate uses and are used and developed extensively by the IT security industry and it was fear this may lead to unwarranted prosecutions. However, on the 25th of October 2007, the Government released a reply to the report from the House of Lords Science and Technolgy Committee on Personal Internet Security. It contains clarification for Section 3A of the CMA:


"We note, but do not accept, the Committee's view that security researchers are at risk of being criminalised because of the recent amendment to the Computer Misuse Act (CMA), namely the new section 3A offence which criminalises the making, supplying or obtaining of articles for use in offences under section 1 or 3 CMA. We believe that it is right that those in the legitimate IT security sector, who make, adaptand supply tools as part of their daily work should have confidence that the new offence will be used appropriately and be assured that their practices and procedures fall within the law. The CPS is currently drafting guidance on how the new section 3A offence will be dealt with and this will be issued shortly."

When the CPS release these guidelines I'll post the details.
David on 10.28.07 @ 08:27 AM GMT [link]


Saturday, October 27th

4000 Breaches!!!


I read a story the other day reporting that the Office of Management and Budget issued a memo in July 2006 requiring agencies to report all security incidents that may involve PII within an hour. A year later 4000 incidents had been reported. 4000. Ok, even if as Karen Evans says that only a small percentage turned out to be "real" incidents that's still a huge amount - even just 1 percent is 40. The figures coming through the Privacy Right Clearing House / Attrition must be just the tip of the iceberg of known breaches - let alone of course the unkown.
David on 10.27.07 @ 04:42 PM GMT [link]

Friday, October 26th

SQL Injection and Data Security Breaches


A while ago, Adam Shostack and I had a conversation about data security breaches that could be pinned on SQL injection vulnerabilities or database compromise. Over the past few days I've been looking for more cases and came up with these.

Guess?, Inc, 3rd March 2002

In the February of 2002 a security aware customer, Jeremiah Jacks, whilst using Guess Inc's website discovered it was vulnerable to SQL injection [1]. He found that he could trivially gain unauthorized access to 200,000 customers' credit card details. After failing to get Guess to fix the problem Jacks contacted SecurityFocus.com to enlist their help. Within an hour Guess had resolved the problem with company spokeswoman Jennifer Munakash claiming, "It was an easy fix." [1] Indeed, when the Federal Trade Commission filed a complaint on 18th of June, 2003 it stated that "the risk of web-based application attacks is commonly known in the information technology industry, as are simple, publicly available measures to prevent such attacks." [2]. Guess settled the FTC charges on August the 5th, 2003.

[1] http://www.securityfocus.com/news/346
[2] http://www.ftc.gov/os/2003/06/guesscmp.htm

Tower Records, 4th December 2002

During the November and early December of 2002, in a parameter tampering attack, hackers could gain access to orders purchased on the Tower Records website. The vulnerability (in the orderstatus.asp [1] page of the web application) allowed attackers to cycle through order numbers in their web brower's URL address bar and, if the order number was valid, details of the purchaser, such as name, address, phone number, etc were exposed. This vulnerability was actively exploited and details of the flaw appeared in two Internet chat rooms [2]. On the 21st of April, 2004, Tower Records settled Federal Trade Commission charges [3].

[1] http://news.zdnet.co.uk/internet/0,1000000097,2127128,00.htm
[2] http://www.ftc.gov/os/caselist/0323209/040421comp0323209.pdf
[3] http://www.ftc.gov/opa/2004/04/towerrecords.shtm

Petco Animal Supplies, 30th June 2003

Jeremiah Jacks, emboldened by the Guess? hack, struck again, this time at Petco whom he discovered via a Google search of ASP pages [1]. Locating pages with parameters that could be manipulated, Jacks gained access to 500,000 credit card details via a SQL injection flaw that took "less than a minute to find". He reported the flaws to SecurityFocus.com who then alerted Petco to the issues. Petco moved to close the holes in less than an hour. Not long after this on the 5th of December the Federal Trade Commission started an investigation and issued a "Civil Investigative Demand". The case was settled just under a year later on the 17th November 2004.

[1] http://www.securityfocus.com/news/6194
[2] http://www.securityfocus.com/news/7581
[3] http://www.ftc.gov/opa/2004/11/petco.shtm

CardSystems Solutions, Inc, 17th June 2005

On the 17th of June 2005, Mastecard alerted some its customers to a breach in the security of CardSystems Solutions, that had taken place between the end of 2004 and the May of 2005. At the time, it was the largest known breach of its kind. By exploiting a SQL injection flaw [1] in the company's website a hacker gained access to 40 million credit card details, of which they downloaded 264,000. In addition to the fact that CardSystems failed to take simple steps to secure the data, another problem with this breach that made it so egregious was that, in violation of the PCI Data Security Standards, data from each cards' magnetic strip was saved for research purposes. Although CardSystems were PCI certified by Cable and Wireless in June 2004 it seems that this practice was overlooked and not reported to the auditors. Due to this violation, on July the 18th, VISA said it would drop CardSystems [2] and Mastecard soon followed suit. This was the first time in the industry that a processor had been dropped. This effectively spelt the end of CardSystems Solutions. In October 2005 the assets of CardSystems were acquired by "Pay by Touch" [3] and on the 23rd of February 2006 they settled Federal Trade Commission charges [4].

This case is interesting for the class-action suit brought on June 27th by Ira Rothken on behalf of California credit card holders and merchants [5]. It sought to discover who, under California civil code section 1798.82, the data breach notification law, had the responsibility to notify the customers. Should it be CardSystems, or Visa and Mastercard or Merrick, the issuing bank? Or all of them? The judge, Richard Kramer, ruled that neither Visa nor Mastercard were required to alert individual customers [6].

[1] http://www.ftc.gov/os/caselist/0523148/0523148complaint.pdf
[2] http://www.nytimes.com/2005/07/19/business/19visa.html
[3] http://www.finextra.com/fullstory.asp?id=14395
[4] http://www.ftc.gov/opa/2006/02/cardsystems_r.shtm
[5] http://www.techfirm.com/cardsystems.pdf
[6] http://www.emergentchaos.com/archives/2005/09/cardsystems_bre.html

Guidance Software, Inc, 20th December 2005

It is perhaps with some irony that Guidance Software found itself requiring the use of their own computer forensics software products in the early days of December 2005. Guidance, the developers of EnCase, discovered on the 7th of December that a hacker had compromised their database server via a SQL injection [1] flaw exposing the financial records of 3,800 customers. It is known that some of these records were abused. For example, one customer received a bill from Google for $20,000 worth of pay-per-click advertising [2]. As well as having an insecure web application, Guidance had failed to encrypt their customers records in the database and had also stored each credit card's CVV number, both being contrary to the PCI DSS standards. A Federal Trade Commission investigation into the compromise was conlcuded on the 17th of November 2006 when Guidance settled the FTC charges [3].

[1] http://www.ftc.gov/os/caselist/0623057/0623057complaint.pdf
[2] http://www.washingtonpost.com/wp-dyn/content/article/2005/12/19/AR2005121900928.html
[3] http://www.ftc.gov/opa/2006/11/guidance.shtm

Ohio State University, April 17th 2007

Ohio State University has the largest enrolment of students in the United States; it also seems to be vying to get the largest number of entries, so far eight, in the Privacy Rights Clearinghouse breach database [1]. One of the more recent attacks that took place on the 31st of March 2007 involved a SQL injection attack originating from China against a server in the Office of Research [2]. The hacker was able to access 14,000 records of current and former staff members [3].

[1] http://www.privacyrights.org/ar/ChronDataBreaches.htm
[2] http://209.85.129.104/search?q=cache:bKgj9Tx-CSAJ:www.infosec.ohio-state.edu/Main/Recent+ohio+sql+injection&hl=en&ct=clnk&cd=3&gl=uk
[3] http://www.osu.edu/news/newsitem1673

Certegy Check Services, 3rd July 2007

In a classic case of an insider job, Certegy, a subsidiary of Fidelity National Information Services, became the victim of data theft by one of its senior database administrators [1]. Named in a suit brought by Certegy, William Sullivan [2], allegedly stole 8.5 million consumer records [3] and sold them to various marketing companies. The investigation was started after one of Certegy’s customers linked unsolicited telephone calls and mails to cheque transactions. After finding no evidence of an external compromise the company alerted the U.S. Secret Service who contacted the marketers in order to discover the source. The trail led back to a company called S&S Computer Services owned and operated by Sullivan. By all accounts the data was exfiltrated by physical means. On one hand this could have been physical backup tapes or on the other hidden in an iPod.

[1] http://www.fidelityinfoservices.com/FNFIS/NewsRoom/20070703.htm
[2]http://pubtitlet.co.pinellas.fl.us/servlet/civil.docket.KEAD?CS__CASE=07006271CI&CS__RESULTS__KNT=10
[3] http://www.sec.gov/Archives/edgar/data/1136893/000089256907000950/a32114e8vk.htm


TD Ameritrade, 14th September 2007

TD Ameritrade, a Nebraska based online trading company, announced on September 14th 2007 that one of its database servers had been compromised by a hacker exposing 6.3 million customer records. The breach came to light when a large number of TD Ameritrade's customers started complaining about receiving investment based spam ("pump and dump" stock scams) causing the company to start an investigation [1]. The investigation revealed that a hacker gained access to customer information such as their names, email addresses, snail mail addresses and phone numbers. The investigation concluded that no social security numbers, account numbers or dates of birth were taken despited the fact that such details were stored and available in the same database server. This case is interesting as it clearly shows a targetted attack with a specific agenda. The hacker didn't go after SSNs, etc (which would enable them to commit ID theft); they didn't go after the clients' assets (which could enable them to commit financial theft); they harvested email addresses of people known to engage in buying and selling stocks to target them with their spam stock scam program.

[1] http://www.amtd.com/newsroom/releasedetail.cfm?ReleaseID=264044

David on 10.26.07 @ 03:00 PM GMT [link]