New IRS Scam via SMS messages

I got a text message today which said like

From:TAX@internalrefunding.com
------Message-----
Subject: NOTICE
You have .30 IRS
UNITS pending for
refunding, complete
the form using
www.internalrefunding.com ASAP

My first reaction was "What the f***" but then I started thinking "Could it be IRS?", if yes, then "Why send a SMS?"

Then my paranoid mind started working and even though I haven't heard of a scam which involved sending SMS messages before, I decided to look into it. I tried to check the link and see what it does but the site was down. I wish i could have been able to check where the website is located. Then I googled on IRS scam, and the first link took me to IRS website, which talks about Email Scams. Check the link here
http://www.irs.gov/newsroom/article/0,,id=170894,00.html

They email scam had 6 or 7 variants on a period of 8-10 months. The last attempt was as latest as Jan 14, 2008. I guess they got tired of finding new ways of sending emails and instead started sending SMS messages. I am sure a lot of people would have fallen for this trick. What is interesting is that these people are not even trying to go for various web application attacks and instead just using social engineering to fool people into providing their information.

I am sure we will see a lot more (similar) scams in the coming days and there is nothing we can do except for asking for more user awareness and education (i don't know how much will that help).

IETF starts working on security requirements for HTTP

Andre sent me a link on "Security Requirements for HTTP". It is exciting to see at least security issues of HTTP protocol are being addressed by IETF. This is a first draft and they are starting to identify the problems and will address them as a final part of this document.

http://www.ietf.org/internet-drafts/draft-ietf-httpbis-security-properties-00.txt

Recent IESG practice dictates that IETF protocols must specify mandatory-to-implement security mechanisms, so that all conformant implementations share a common baseline. This document examines all widely deployed HTTP security technologies, and analyzes the trade-offs of each.

The internet draft of "Security Requirements of HTTP" addresses the existing security mechanisms of HTTP or its lack thereof :)

Forms and cookies have number of properties that make them an excellent solution for some implementors. However, many of those properties introduce serious security trade-offs.

HTML forms provide a large degree of control over presentation, which is an imperative for many websites. However, this increases user reliance on the appearance of the interface. Many users do not understand the construction of URIs [RFC3986], or their presentation in common clients [[ CITATION NEEDED ]]. As a result, forms are extremely vulnerable to spoofing.

Cookies are susceptible to a large variety of XSS (cross-site scripting) attacks, and measures to prevent such attacks will never be as stringent as necessary for authentication credentials because cookies are used for many purposes. Cookies are also susceptible to a wide variety of attacks from malicious intermediaries and observers. The possible attacks depend on the contents of the cookie data. There is no standard format for most of the data.


Remember this is just the initial draft and is incomplete but the good news is that they have started working on it and sooner then later would be implemented. It may not have all that we want, but at least it will do something more then what we have today.

Do you have to fix XSS vulns to be PCI Compliant? ScanAlert Says No

I was reading Jeremiah's blog about ScanAlert's Response - ScanAlert - XSS is not our problem

I had blogged earlier about Should ScanAlert be revoked of their PCI Scanning abilities?

The interesting thing here is that if Hacker Safe is not detecting XSS attacks and I can bet they would not be detecting SQL injection attacks as well. So, what part of web application attacks are they trying to detect? I guess none. Which is OK as long as they don't claim they do. Oh wait..this is what they mention on their website

http://www.scanalert.com/site/en/security/howwescan/

During this testing phase, all HTTP services and virtual domains are checked for the existence of potentially dangerous modules, configurations settings, CGIs and other scripts, and default installed files. The web site is then "deep crawled," including flash embedded links and password protected pages, to find forms and other potentially dangerous "interactive elements." These are then exercised in specific ways to disclose any application-level vulnerabilities such as code revelation, cross-site scripting and SQL injection. Both generic and software specific tests are performed in order to uncover misconfigurations and coding error vulnerabilities.


Well..I don't know what to say here..Let's assume for a second, that they don't detect these vulns..which is OK. Hey!! I am not going to tell ScanAlert what they should and should not do. Its their business. If they don't want to detect XSS or SQL injection, its fine by me. They can say that "HackerSafe" is not going to detect XSS vulns as they are not considered a serious risk. My question is, if they are not detecting XSS vulns and PCI standard says "Web sites should not have XSS vulnerabilities" then can ScanAlert provide a PCI compliance certificate? If they can, then why penalize the merchants?

On the other hand, Lets say if they do scan and detect XSS and SQL injection vulns, then all the websites mentioned on http://sl.ackers.org and XSSed.com which have hackersafe logo on them should not have a PCI Compliance certificate from ScanAlert. Since PCI requirement Section 6.5.4 and 6.5.6 very clearly mentions that XSS and SQL injection vulnerabilities should be detected and fixed before a website becomes PCI certified.

I don't think ScanAlert team understands web application security properly based on some of the comments made by Joseph Pierini, director of enterprise services for the ScanAlert's Hacker Safe program. Here are a few of them below.

“Pierini dismisses the suggestion that certifying a site as "Hacker Safe" when it remains vulnerable to XSS attacks could be confusing to consumers. "

Forget about consumers for a second and talk about the website owners. Does a site which is certified as Hacker Safe is by default PCI compliant or a site can be hacker safe but not PCI compliant? I don't think they differentiate between the two.


“He insists that the meaning of the certification is clear and notes that his company's scanning service reports the XSS flaws it finds to its clients.”

So, if ScanAlert has notified its clients that they have XSS flaws in their system, and the clients have not fixed them, I am assuming then those clients are not PCI compliant and ScanAlert would not have issued them a PCI certificate. If they did, then why penalize the clients alone and not ScanAlert as they knowingly gave a certificate to the clients when they had open vulnerabilities in their system.


“Cross-site scripting can be used to do a variety of things, but it's all on the client side. And that's an area that we don't have control over."

This is exactly the kind of problems merchants are facing. If the PCI ASV doesn't understand XSS attacks or other web application attacks, then how are they going to educate the merchants and as a result, the vulns are left open and exploited by the bad guys. The ASVs wash their hands and merchants gets penalized. I think its time the ASVs are held liable too for their ignorance or incompetence.


Other suggested readings.

Who are the real culprits for PCI compliance?

Many 'Hacker Safe' Web Sites Found Vulnerable

Group Tags More 'Hacker Safe' Sites

Re: [ISN] Many 'Hacker Safe' Web Sites Found Vulnerable

ScanAlert - XSS is Cool with Us

An open letter to Ken Leonard, CEO ScanAlert

The Fortification Movie

Last week i went to see the documentary by fortify on "The new face of Cybercrime". I went there thinking that it would be something that shows what cybercrime is all about and how bad guys are breaking into websites to steal credit card numbers, SSN, etc. and selling it on the black market to make money. Basically a visual representation of what we deal with, day in, day out. But it turned out that it was nothing like that. All they have done is take interviews from reporters and some key people in the industry and put them together in the form of a movie. I couldn't understand the message, this movie (or documentary) was trying to send and who was the target audience (as it definitely wasn't security professionals). Infact, someone actually asked the same question and the best they could come up with is that it is thought provoking. (LOL). It was thought provoking all right, but the thought definitely wasn't web application security.

About the target audience, well, they said the movie was for C level executives and/or business owners to understand the consequences of (in)security of their websites. I don't know, how this movie is going to help those guys get the message. I mean, if you are trying to sell a product or a service, sure, you can use this movie, instead of doing the explanation verbally. Or at least I think so. Having worked for few financial institutions (including some really big names), and have seen first hand, how business decisions and timelines are driven, let me tell you right now, No matter, how much a business understands the need of web application security, but when it comes to user demand or a competitor coming out with a feature that their web site doesn't have, the primary focus becomes shipping out the feature with or without security.

I would have loved to see the movie targeted towards consumers with a visual representation of how an identity theft occurs, how business's security (or lack thereof) affects them. I don't know, how many security professionals would agree with me on this, but I think unless the security is demanded by the consumers, it will just be treated as compliance.

Nevertheless, you should watch it, just don't get your hopes high. As it has nothing new in it, that you already haven't heard or read somewhere. I am not trying to undermine the effort by Fortify folks but I do think, they could have done a better job. Who knows, maybe in the sequel, they will :)

Calling all web hacks of 2007

Jeremiah Grossman is trying to gather all the neat researches behind web hacks of 2007.

"The hardest part is collecting a rather complete list of references to vote on, they’re all over the place, so that’s the reason for this post. Below is what I’ve gathered so far, and if you know of others, please comment them in with the title and link and I’ll add them. In the next few days the list will be compiled and I’ll create an open survey."

Read the entire post here

I think its a great idea. It will not only help build a repository of all cool hacks of 2007 but also give people a chance to showcase their work. Letting the industry select the top 10 is an impartial way to choose the best. For those who cannot get into top 10, will still get a lot of visibility, appreciation and who knows that might motivate them for the next year.

If you know of something which is not already in the list, please feel free to add it.

It would be really interesting to see who the winners are.

Good Luck to all the participants.

Should ScanAlert be revoked of their PCI Scanning abilities?

I was passed on this link today about "Hacker Safe Website gets hit by Hacker". For those who don't know, Hacker Safe is a service provided by Scan Alert (which is set to be acquired by McAfee). I am not going to go into the details of how safe are the sites displaying the logo "Hacker Safe". I don't even want to go into the details of what level of scanning services are provided by ScanAlert through Hacker Safe. What I do want to talk about is, the PCI Compliance Certificate provided by ScanAlert after their scan.

ScanAlert provides a PCI scanning service for $149.00 a year. Oh and their website claims they work directly with VISA and MasterCard. Personally, I don't care about their pricing model, they could provide their service for free, for all I care. What matters to me is, they are "PCI APPROVED VENDOR".

So, the story today was about one of their clients, Geeks.com. Here is an excerpt from the article

"Geeks.com is a $150 million company specializing in the sale of computer-related excess inventory and manufacturers' closeouts. Its Web site prominently proclaims that it is tested on a daily basis by ScanAlert Inc."

According to the PCI Compliance guidelines, Geeks.com should now become Level 1 merchant and have to pay fines and everything, now that there has been a breach resulting in loss of credit card details. But, what about ScanAlert, shouldn't they be penalized too?

As I mentioned in my last post - Who are the real culprits for PCI Compliance?
Geeks.com hired a PCI approved vendor to scan their site and provide them solutions. ScanAlert scans Geeks.com site everyday and didn't find any vulnerabilities. Now that Geeks.com is hacked, I am sure everyone would blame them about lax security practices and what not but what about ScanAlert? Shouldn't they share a part of the blame too?

In the end, I think the bigger question is - Is this level of service accepted by PCI Council?