Slashdot Mirror
Web Based Turbo Tax Disclosure Vulnerability Found
Anonymous MPLS Coward writes "Looks like the web-based Turbo Tax was allowing some users to look at other user's tax return information. Reports state that things like bank routing information was available as well as SSNs. Turbo Tax software was unaffected; the bug is in the web-based Turbo Tax service."
The synopsis makes it seem like this was a bigger deal than it is. If this was actually in the wild, or exploited, that'll be big -- but as the article is written, one person stumbled across this problem, reported it, and Intuit fixed it.
I am currently holding in my hand a wire transfer request, dating from a few months ago when I sent money to a friend with an unexpected catastrophe. It asks for very few things.
* Date/time of original request
* "Teller ID" (I called them to ask how to do this and they gave me this bit of information)
* Member name
* Member number (this is embedded in the routing number for my savings account)
* Daytime phone
* Amount
* Information on who gets the money
* Signature
The only parts of this which could be used for authentication:
* The fact that I called
* My name
* My member number
* My phone number
* My signature
Given my tax forms, one could easily find my name and phone number, and if I had chosen the option to wire to or from my checking account, my member number as well. (This is why I would have sent a check, although that doesn't help particularly since the number is still written on the check. I got a refund, however, so they'll be sending me a check instead and I don't have to worry about that particular hole.)
Calling them is easily doable by someone who isn't me. My signature, as much as I hate to admit it, is awful and pretty easily forgeable.
So, in summary: the information on a tax return is a significant fraction of what is needed to withdraw money from someone else's account. It may not be enough. But it certainly helps.
Breaking Into the Industry - A development log about starting a game studio.
On-line websites have been a major source of information security breaches. A few years ago I was able to perform reverse-directory lookups on Verizon customers. Their DSL registration website was one such problem. After a customer entered his/her telephone number to verify DSL availability, the website displayed the corresponding customer's name and billing address, asking "is your information correct?"
signature pending slashdot approval
H&R Block had a similar issue with their online tax prep software back in February:
news.com.com article
Businessweek article
"This message is composed of 100% recycled electrons."
They claim to have REMOVED THE LINK.
Removing a link to a web page takes the "feature" away on the server...? Idiots.
In Australia the Government provides software to do your tax online. I've been doing it like this for the past 3 financial years. It is far easier and explains a lot more then the paper return you fill out. If you have a refund it is deposited into your account within 14 days. The paper "Tax-Pack" is utterly useless in comparison.
# cat
Damn, my RAM is full of cats. MEOW!!
Agreed. This is the same kind of crap that I see all of the time from inexperienced developers (especially offshore developers in India). They make all of the classic mistakes, client side javascript for input validation, use of query string parameters with the the SQL command builder on their pages (SQL injections galore), administrative query access to the SQL server directly from the web server, "secret" admin pages, cross-site scripting, you name it and they do it. The problem with a significant portion of the Indian developers is that they are are too busy waving their IIT degree, ISO certs, and other documentation of their extensive education, which taught them everything they needed to know, so they don't need to listen to American devs who have a few lessons left to teach them from school of hard knocks. They suffer from the "not invented here" syndrome, sometimes to an extreme, and thus earn themselves nasty surprises when the attack finally comes and catches them completely flat-footed. The really sad part about all of this is that same types of attacks are used again and again and the same developers keep building vulnerable sites again and again...even long after the attacks are known and proper designs have been presented on many developer forums to avoid these problems (i.e. use stored procedures, limit database permissions to those stored procedures only, don't use the query string for sensitive data, use regular expressions to validate user input data on the server side, etc...)
There's one tax software company doing their programming entirely in America, TaxAct (2nd Story Software. I haven't used their Web version, but their Windows version runs nearly flawlessly under Wine on Linux (there are minor problems with checkbox and drop-down list display on screen while filling out forms, but those show up correctly in the print preview and output). I've used TaxCut and TurboTax in past years; TaxAct doesn't have silly videos included, but it's efficient and effective.
I share the caution about Indian programmers. I just dropped checking and savings accounts with Ameriprise (formerly Amex Bank), because in the several years since they shipped the programming off to India they still haven't gotten their site to work reliably in its basic operations. Even before security is considered, the incompetence is amazing. Now I'm seeing a downgrading in the usability of CitiBank's Website, where there's also been extensive recent offshoring - they can't be bothered to test for obvious JavaScript bugs that block Mozilla, for example, even though previously they'd officially and effectively supported Mozilla/Netscape for years. (Hell, I do work for financial firms in NYC that don't even allow their own people to browse with IE.)
"with their freedom lost all virtue lose" - Milton