The End of Exponential Malware Growth?

For some time, especially the last 2 years, the growth of new malware samples has been huge. Now a McAfee researcher says that growth has flattened out over the last few months.

The number of samples is still growing, but it seems to be growing at a flat rate, meaning that from month to month the growth rate is the same.

It takes a really optimistic outlook on life to declare victory here, but certainly there’s reason for some optimism, It’s just possible, for example, that malware authors and distributors have seen diminishing, or even zero, marginal growth from continuing to open the throttle on the malware engine.

Toralv Dirro, the McAfee researcher, also points out that all this counting is based on the AV-Test approach of using cryptographically unique samples, and that there are many other ways to count malware, also legitimate depending on what you are trying to demonstrate and the specifics of the malware. Should the nature of malware change, as it has in the past, this basis for counting could change too.

Posted in Web Security | No Comments »

Malvertizements

Thanks to the Spyware Sucks Blog for pointing to some “maladvertisements” that have been making the rounds lately.

Malicious advertisements are nothing new. A seemingly innocuous site can turn malicious through the advertisements it offers. The ones in the Spyware Sucks post are tied in with ad networks infamous for this sort of thing.

What can you do? All the usual things: Keep your browser and operating system up to date, run security software that can trap some of the attacks these sites might bring, and use common sense.

Posted in Web Security | 1 Comment »

Another Monster Mac Update

Apple released two security bulletins yesterday and massive updates to OS X.

The first bulletin describes 25 vulnerabilities as measured by CVE number, many of them critical. The updates appear to be named Security Update 2008-004 for Mac OS X and OS X Server v10.4.11 and Mac OS X 10.5.4.

The second bulletin describes the release of Safari 3.1.2 for Mac OS X 10.4.11. This same update was released for Windows a couple of weeks ago and in Mac OS X 10.5.4. (Why was this released as a separate bulletin instead of being part of the larger one above? I can’t tell.)

Posted in Web Security | No Comments »

Google And The Anti-Obama Bloggers

Google shut down a group of anti-Obama blogs last week. Was it a political conspiracy or something even more complicated?

According to the New York Times the bloggers, all affiliated with JustSayNoDeal.com a Web site that opposes Senator Obama, were unable to publish to their sites. The bloggers had received a note from Google saying that they “…will not be able to publish posts to your blog until we review your site and confirm that it is not a spam blog,”

The blogs have all been restored, although some of the bloggers have taken their business elsewhere. They don’t believe Google and they certainly don’t trust it.

How had Google misidentified these blogs as spam blogs? There’s some controversy there. The bloggers claim that a campaign of abuse by opponents using the Google Blogger “flag” button to label the site as spam. Google claims that the flag cannot be so abused: “The Flag button isn’t censorship and it can’t be manipulated by angry mobs. Political dissent? Incendiary opinions? Just plain crazy? Bring it on.”

Google claims that the misjudgment was based on spam filters, perhaps those at GMail, reacting to large amounts of spam that referenced the JustSayNoDeal.com site. It’s a plausible explanation, but it still probably means they were manipulated. Look for more of this sort of “reputation warfare” as the campaign continues.

Posted in Web Security | 2 Comments »

GoDaddy VP Outbidding Their Customers

Thanks to Slashdot for pointing me to the story of the GoDaddy executive bidding against their own customers in their auctions.

The story began with an alert user in a discussion on namepros.com. The user had noticed that the winner in an auction of an expiring domain was one Adam Dicker, “VP of Domain Name Aftermarket (TDNAM)” at GoDaddy. Like many registrars, GoDaddy holds domain auctions, including those of expiring domains.

Domain Name Wire looked into the story further and discovered, unsurprisingly, that GoDaddy has no policy against this sort of thing. The potential is there, of course, for employees to bid up auctions simply to get the prices higher for the company’s benefit. As the reader on Namepros put it:

These employees may or may not have access to more information than the rest of us, and they may or may not have to pay full price for the domains they win. This is particularly insidious at GoDaddy since they are one of very few auction sites which don’t show you who you are bidding against. So I have no idea if any of the names I won that day were inflated in price due to TDNam executives bidding against me.

GoDaddy did tell them that they have controls in place to prevent someone from gaming the system, but it’s not clear if the sort of manipulation discussed in the quote above meets their definition of manipulation.

Domain Name Wire dug further and found out that such non-policies are common. They go on to wonder if it’s hard for such companies to hire talented people if they will then be shut out of the markets right in the middle of a bubble. A further post includes more follow-up from Sedo and Enom.

Something about it all definitely stinks, but the whole aftermarket for domains is skating on the edge of shady anyway. Perhaps it’s not surprising to find players trying to get every edge they can.

[Update: GoDaddy has issued a statement saying that Dicker's actions were not improper, but that from now on employees are prohibited from participating in such transactions.]

Posted in Web Security | 5 Comments »

ICANN Hit With Phishing Attack

A new and different kind of phishing e-mail pretends to come from ICANN, the Internet Corporation For Assigned Names and Numbers, the governing body for much of the infrastructure of the Internet. Most people, even domain name owners, don’t know what ICANN is, which perhaps limits the power of the phishing campaign which is, in any event, down because the web domain it used was taken down. (I bet those registrars listen when ICANN calls about this stuff.)

Because ICANN is most famously associated with regulation of the domain name market, the phish claims that ICANN is upgrading their domain database and that the user need to enter their domain registration details (username and password included, of course) at ICANNresolve.com. This domain is now offline, but Domain Name Wire claims that it was a pretty good spoof of the ICANN home page.

It’s hard to imagine a circumstance under which a normal domain name owner would receive an e-mail from ICANN, although it is possible, Still, nobody needs your registrar account login except your registrar.

Posted in Web Security | 1 Comment »

PCI-DSS references the outdated OWASP Top Ten

I’m sure other people have noticed this, at least I hope so, but never mentioned it publicly. If you read PCI-DSS 1.1 section 6.5, the part that covers “Cover prevention of common coding vulnerabilities in software development processes”, you’ll notice the list is identical to that of the OWASP Top Ten 2004 while the latest version is 2007:

6.5.1 Unvalidated input
6.5.2 Broken access control (for example, malicious use of user IDs)
6.5.3 Broken authentication and session management (use of account credentials and session
cookies)
6.5.4 Cross-site scripting (XSS) attacks
6.5.5 Buffer overflows
6.5.6 Injection flaws (for example, structured query language (SQL) injection)
6.5.7 Improper error handling
6.5.8 Insecure storage
6.5.9 Denial of service
6.5.10 Insecure configuration management

I guess technically speaking anything that’s in v2007 and not v2004 you don’t have to worry about. That means you still have to code against Buffer Overflows and Application DoS, but not Malicious File Execution, Insecure Direct Object Reference, and Cross Site Request Forgery (CSRF). Ahh, fun fun. Gotta love compliance.

Posted in Web Security | No Comments »

Web Application Security Today - Are We All Insane?

CSO magazine was kind enough to publish an opinion piece where I present a top-down view of the current state of web application security. I nervously expect a “spirited” flow of blog comments because it questions the value of certain best-practices and deeply held personal philosophies. Fortunately though our general public discourse has advanced a great deal recently and the community at large is a lot more informed of the challenges at hand. I pulled out a snippet to give a feel.

“It is unreasonable to expect publishers, enterprises and other site owners to restart and reprogram every website securely from scratch. Nor can we fix the hundreds of thousands (maybe millions) of custom Web application vulnerabilities one line at time. The very thought sounds insane to me. It would take too long (probably never finish), cost far too much (billions per year), and the bad guys are already ahead of us. Conservative estimates put the total annual IT security spend in the US at billion and e-crime losses at 0 billion. We’re losing two dollars for every dollar spent.”

Enjoy!

Posted in Web Security | No Comments »

Can WAFs protect against business logic flaws?

“Web Application Firewalls (WAF) are a total waste of time/money because they can’t protect against business logic flaws!,” a common theme among the few, but vocal, seriously anti-WAF zealots out there. While there is some truth it’s also like saying car door locks are useless because criminals can break in by smashing the windows. Or car alarms are a waste because they don’t protect against carjacking. And steering wheel locks are lousy because the car is at risk to thieves with tow trucks. You see where I’m going with this. Every security measure has a particular purpose, limitation, and overall value to the owner considering what it is they’re protecting.

Sure, WAFs don’t defend against every logic flaw, or even every crazy form of SQLi or XSS. Just as white/black box scanners can’t identify every vulnerability and neither can expert pen-testers or source code auditors. A/V products don’t red flag every piece of malware. Anti-spam misses some junk mail. Yet we still utilize these solutions anyway because their value outweighs their limitations. And of course WAFs don’t replace vulnerability assessment (VA) or secure coding practices just as Nessus doesn’t compete with network firewalls or good segmentation practices. Therefore I recommend we ignore rash criticisms and keep an open mind into what WAFs can/can’t do, the value they may provide today, and consider how they made be improved – including being aided by VA intelligence (VA+WAF).

I’m going to keep my comments vendor agnostic. Perhaps some of the features described below are already included in some of the available WAF products. In fact I know they are and claim no novelty of any of these ideas (probably printed elsewhere), but I’ll leave it to the vendors to comment on their specific products capabilities. I think the readers here might be pleasantly surprised. My intent here is to explore a few of the more common business logic flaw examples we’ve all seen, assume we know where their location (VA), and attempt to hypothesize defense measures.

Business Logic Flaw examples

1) Rotating numbers in URLs, the classic case of Insufficient Authentication, Insufficient Authorization and Insufficient Process Validation where an attacker can gain access to data or functionality their user-level should not have. We’ve seen these issues countless times in order tracking systems, bank account screens, and even in online vote registration. I see at least two possible ways to prevent these types of business logic flaws with a WAF.

URL encryption
The WAF inspects outbound Web page content, dynamically encrypts and replaces every URL directed to the website, and by extension decrypts them on the way back in – completely transparent to the web server or application. For example:

<* a href=”http://website/app.cgi?foo=bar”>action<* /a>

becomes…

<* a href=”http://website/06ad47d8e64bd28de537…”>action<* /a>

or

<* a href=”http://website/app.cgi?foo=bar&t=1fad47d…”>action<* /a>

URL encryption is powerful as it prevents URL parameter tampering and by extension protects against a wide range of attacks (XSS, SQLi, CSRF, etc.). No parameter tampering, no number rotation, no business logic flaw. Implementation is really tricky though because the HTML parser has to be perfect otherwise requests will be blocked when links are missed. Bookmarks and search engine indexing is also potentially disrupted. However, websites where most functionality is behind a login screen, such as banking sites, might not mind. Its also possible these side effects could be reduced by only focusing on the URLs known to be vulnerable (VA) instead of pursuing global enforcement. There is no need to encrypt URLs that aren’t vulnerable.

Session-State tracking
Users can be tracked from one page to the next so it’s technically possible for a WAF to know where they are in a particular flow and where they should be able to get to, or not. If an attacker were to rotate a number in a URL the WAF could be capable of determining if they should have been able to get it (UI-wise) from where they are. If they shouldn’t be able to, deny! Or perhaps a more forgiving threshold is in order so the may try 1, 2, or even 10 illegal URLs, but not more because that would surely be abnormal behavior. Scalability is biggest drawback here as increasingly large state tables are required for tracking. However, if you know a particular URL or parameter name has a problem with number rotation, WAFs can again be configured to focus and enforce controls only there.

2) Session hijacking by way of cookie tampering is another old school hack that has implications for Credential/Session Prediction, Insufficient Session Expiration, and Session Fixation. This issue doesn’t show up as much as it once did because most developers are using the native session handling APIs in their development frameworks as opposed to rolling their own. A very good thing.

Just like the previous example we can utilize some good ol’ on-the-fly cookie encryption/decryption that can be easily performed with a WAF. If an attacker is unable to modify their cookie to a valid value, and the WAF would know cryptographically, then session handling issues go away. You could even add some httpOnly, secure, and non-persistent flags if you want. You’d still probably have issues with Insufficient Session Expiration or Session Fixation, but we’re getting somewhere. The only drawback I can think of is if JavaScript or some other client-side language needed to read/write the original cookies values.

3) WAFs could also potentially be used to stop login brute force attacks or Insufficient Anti-Automation by including CAPTCHAs on-the-fly at various choke points. Again, thresholds would be neat. We could explore other examples, but I think you get the idea and this post is long enough. Well at least I don’t want to write anymore.

Its important to understand that we’re at the very beginning of WAFs (or website VA for that matter), their deployments, which is also why there is so little field experience posted anywhere. We need an open community dialog so we can see where this technology can go and how it can be improved. - independent of the PCI 6.6 mandate. My point is I don’t think WAFs will be able to solve all of our web application security problems, or even all business logic flaws, and I don’t know of anyone who does. It certainly would be nice though to see what WAFs can do or be made to do. We won’t know unless we keep and open mind and try.

“Any fool can criticize, condemn, and complain, and most fools do.”
Benjamin Franklin

Posted in Web Security | No Comments »

Microsoft announces Black Box, White Box, and WAF

Apparently the mass SQL Injection attacks have really woken people up and they’re probably flooding the MS blogs and inboxes with pleas for assistance. No doubt a lot of them use Twitter. Site owners are desperate to protect their old legacy ASP classic code. To help the situation Microsoft has just announced 3 free new toys specifically targeted at SQLi.

1) The Microsoft Source Code Analyzer for SQL Injection (MSCASI) is a static code analysis tool that identifies SQL Injection vulnerabilities in ASP code. In order to run MSCASI you will need source code access and MSCASI will output areas vulnerable to SQL injection (i.e. the root cause and vulnerable path is identified).

Cool. If anyone wants to provide feedback on effectiveness, I’d really like to know!

2) Microsoft worked with the HP Web Security Research group to release the Scrawlr tool. The tool will crawl a website, simultaneously analyzing the parameters of each individual web page for SQL Injection vulnerabilities.

This is nice of HP to offer, but the product limitations seem somewhat onerous to me…

* Will only crawls up to 1500 pages
* Does not support sites requiring authentication
* Does not perform Blind SQL injection
* Cannot retrieve database contents
* Does not support JavaScript or flash parsing
Will not test forms for SQL Injection (POST Parameters)

Hmm, if used MSCASI and Scrawlr are used at the same time, can we call this Hybrid Analysis?

3) In order to block and mitigate SQL injection attacks (while the root cause is being fixed), you can also deploy SQL filters using a new release of URLScan 3.0. This tool restricts the types of HTTP requests that Internet Information Services (IIS) will process. By blocking specific HTTP requests, UrlScan helps prevent potentially harmful requests from being executed on the server. It uses a set of keywords to block certain requests. If a bad request is detected, the filter will drop the request and it will not be processed by SQL.

IIS’s equivalent to ModSecurity on Apache. Cool stuff, first used it a LOONG time ago and no doubt solid improvements have been made. From the description it appears to still be using a black list negative security model approach to protection. How about that!? Looks like the only thing they left out is some kind of DB or system clean up for those who have already suffered an incident. I’m hearing that the hacked count is up to 2 million sites now. Ouch.

Posted in Web Security | No Comments »