Fun Reading on Malware

The most moralistic virus? The most sensationalist virus? The most diligent virus? Fun reading from Panda

On Ugly Stuff

So, Mike Murray brings up this fun point: ' My favorite way of asking it: "What, if your company [...], would be a complete deal-breaker for you? What would make you completely disengage?"'

I'll bite, Mike: one of the truly disgusting things (which would make me reach for my resume in a second) would be for a [security] product company to use a competitor's product to protect its own network. Don't laugh (please cry, in fact!), this stuff actually happens...

I am sure that decent companies run their own stuff and Snorts happily protect Sourcefire's network while Proventias guard ISS (and now IBM) from evil attackers, thus telling the world that their stuff is indeed the best for them as well as their customers. However, what in the whole wide world would make you buy security gear from somebody who prefers some other brand to his very own? And what would make you work for such a company [well, maybe a fat salary will :-), but that is a separate story]?

A milder version would be to simply shy away from using its own product, because it is so "enterprise-grade" that a small company (such as its creator) will not benefit from using it internally. It is a bit less disgusting and credibility-busting, but it smells pretty darn bad as well...

Response to Comments on Predictions

So, I got a few fun comments on my recap of my 2006 security predictions.

Specifically, "Gabriel" said that server attacks have not fallen. Indeed, I would agree that a rise in web application attacks more than covered a drop in server platform software attacks so we are kinda both right (I should have said "server platform software attacks dropped" and not "server-side attacks dropped"). Thanks to "Gabriel" for noticing and clarifying it!

Also, he is just as correct in stating that wireless driver attacks have emerged from the underground. However, I would still claim that wireless attacks have not become anywhere near widespread as worms and virii :-) hits of the 1999-2003 or spyware infestations of 2003-2006.

Also, the next step in my track to highly-awaited 2007 security predictions (I am NOT posting them yet!) would be to pick on somebody else's. Maybe it is just my mood today, but I am very eager to call somebody a dumbass for predicting something truly ridiculous... :-) Stand by for that!

My 2006 Security Predictions Review

So, no, you are not getting my predictions yet, but here is something fun: a review of my last year's predictions. They were:

1. Viruses, worms, bots and spyware will remain the main concern; malware commercialization will continue and thus propel more money-making technologies such as spyware (5,5)

STATUS as of 12/22/2006: Correct (but it was a reeeally easy one)! Recent polls still show that malware tops the charts (even though various forms of regulatory compliance, IP theft [as some has us believe] are challenging that)

2. Data/IP theft and especially ID theft will continue and increase in both severity and occurrence (5,5)

STATUS as of 12/22/2006: Correct (at the very least, the buzz levels about this are skyrocketing); phishing and identity theft - as a type of IP theft - were certainly growing and so was the IP loss in the form of laptop loss.

3. At least one major 0-day compromise story will surface, maybe with Oracle software (5,4)

STATUS as of 12/22/2006: Correct (see recent MS Word 0day stories); Oracle bugs were aplenty, but nobody admitted that they were owned thru one ...

4. Application-level vulnerabilities will grow, service-level ones – shrink (5,4)

STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration); the decrease in network-service level vulns was dramatic, but SQL injection, XSS and other stuff grew like mad.

5. Client (web, mail, chat, etc) attacks will rise and server attacks will fall somewhat (4,5)

STATUS as of 12/22/2006: Correct (see recent SANS Top20 for some illustration), but no credit really - this one was trivial to predict.

6. Major wireless and mobile threats will not come (4,3)

STATUS as of 12/22/2006: Correct (but, again, I see this as an easy one)

7. Endpoint security solutions and NAC-like technologies will experience sharper increase in adoption than other security tools (3,4)

STATUS as of 12/22/2006: Correct; again, if we measure by media buzz levels and [late] company launches, NAC and endpoint security is still heating up

8. Finally, I predict that just as one cannot predict the threats of tomorrow today, one still won’t be able to do in 2006 :-) (5,5)

STATUS as of 12/22/2006: but of course! Indeed, there are many things that I am pretty sure we would all love to predict but just as unanimously missed.

So, I officially upgrade myself to Chief Security Nostradamus :-)

Musings on Logs

Don't you just hate it when you have to parse logs that look like this 'This event contains REPAIR PROCEDURES for the 1084 event which has previously been logged. This message indicates a specific issue with the consistency of the Active Directory database on this replication destination. A database error occurred while applying replicated changes to the following object. The database had unexpected contents, preventing the change from being made."

More on Trends and Predictions, New and Old

So, to throw those waiting for my 2007 predictions off the track, I will post my predictions (sort of) for 2004 :-) It is my old SANS presentation on "What is NOT Working in Security 2004;" yes, old it might be, but it is still a fun read.

My Security Predictions for 2007 .... Not Yet

OK, it looks like I just have to respond to this. The claim was made that one has to unleash his or hers (hmmm...) security predictions for 2007 immediately.
But - guess what- I will be a party pooper and will hold on to mine.

Feel free to see what I collected so far: security predictions 2007 tagged at del.icio.us

So, no, I am not posting my predictions just yet. In this prediciton game, you know that whoever waits the longest (preferably to the end of 2007 :-)) wins (i.e. looks like less of an idiot :-))

Isn't Compliance Cool? :-)

At least, PCI compliance is: where else you can win a large bonus cash prize for doing something that is mandatory (and you'd be fined if you don't do it)

"Earlier this week, the company announced that it has created a new $20 million incentive program under which it will monetarily reward "acquiring" financial institutions if their members are fully compliant with PCI requirements by Aug. 31, 2007. At the same time, acquiring banks that fail to ensure compliance by Sept. 30, 2007, will be assessed fines starting at $5,000 a month for each noncompliant merchant. The fines increase to $25,000 per month for each noncompliant merchant after Dec. 31, 2007."

Database Security ... Not

Isn't embarrassing when someone posts a guide on how to secure a database and doesn't even mention logging and audit logs? It sure it, but at the same time it shows something pretty pervasive and unfortunate: many folks who run database have no idea who does what with the data (and, to a lesser extent, with a database itself) since no logging is enabled, with the possible exception of logging major failures with the database software itself.

DBAs who don't care about data in "their" databases is a sad phenomenon indeed. But then again - somebody got to help the incident response consultants to get rich! And the media needs constant flow of hotter and hotter breaches and data thefts! Go ahead, help these folks, continue to ignore logging on your database and reap generous rewards, such as seeing yourself on CNN (right before you "see yourself" on a pink slip! :-) )

Wireless Network Get More Secure ... Duh

So, this ancient blog post stated that "80% of wifi networks [are] insecure" ( and points to a Slashdot interview with the author of Kismet). The date on the post is 08/20/2004; more than 2 years ago. And a funny thing happened - wireless networks actually gotten more secure! Nowadays one can't be certain that he would see an open wireless network whenever one sees a bunch of wireless networks somewhere...

As similar things happen in other areas of IT, the specter of security being done is being raised once again. But - guess what? - the answer is still NO.

Is Humanity Getting Dumber?

This sure makes one think so, what happened to common sense and basic kindergarten physics ...

“Imagine a plane is sitting on a massive conveyor belt, as wide and as long as a runway. The conveyor belt is designed to exactly match the speed of the wheels, moving in the opposite direction. Can the plane take off?"

Now, how many of you would NOT be able to answer this within, say, 30 seconds (I am being generous here)? Such people should please read Darwin and then try to remove their genes from the humanity gene pool in whatever manner desirable and ASAP!

One piece even called this "a brain-teaser" - yeah, maybe, if you lack the very organ mentioned above :-)

Another Old Presentation: On Log Centralization

Another Old Presentation of Mine: On Log Centralization. My old preso on data ... centralization; note that I might not agree with everything I said back then (more on that in the near future ... )

More Proof that CA = No Brain

As you, my dear readers know, I sometimes like to point at really, really stupid things that I see in our domain. Here is one: "Vista will force need for network forensics."

This security VP from CA (you can start laughing now, but please wait for a punchline) claims that "Encryption by default means that without user credentials it will no longer be possible to investigate user behaviour at a disk level." thus "The result? Network forensics is rapidly becoming the next big thing in IT security."

So, who can name more reasons why this pathetic attempt to sell "CA Network Forensics" product is laughable?

Here is one reason to rule them all: network encryption is here NOW, disk encryption is coming in the FUTURE. Thus, if disk encryption will break disk forensics, than network forensics is broken already...

BTW, looking at logs for forensics will always be useful - but that is another story altogether :-)

On Annoyances, Major and Minor

Arrrgh, I just want to kick whoever redesigned the UI look and feel of Google Desktop: from the most useful and neat tool to a hateful annoyance in one quick automated update ;-)

So, maybe Google Desktop is spyware after all?

Oh, What the World Came to: Blocking Word Docs at the Gateway

So, this has been making rounds for a few days already after yet another (and then two more...) 0day in MS Office was discovered, but it got me thinking. The issue is that some orgs (NASA is mentioned here) chose to "block the receipt of Microsoft Word documents coming in to the space agency's core computer network as e-mail attachments" this time.

Would you do this? Or will your business units eat you for lunch and have nothing left for dinner? Now, almost everybody blocks EXE and COM as well as VBS on their gateways and it is seen as a reasonable practice. But DOCs?

So, Are Agents Evil?

I admit I am late to this agent-slamming party started by Matasano folks, but I want to play "kick an agent" as well :-)

So, I've yet to see a person who willingly says "yep, I wonna go and deploy agents on all of my 23,000 servers and desktops" even if he KNOWS that he will get a sizable benefit as a result of doing it (and, sometimes even when said benefit is not achievable without all those agents)

Unfair? And so is life...

Anton Security Tip of the Day #6: The Other Web Log

Following the new "tradition" of posting a security tip of the week (mentioned here, here ; SANS jumped in as well), I decided to go along and join the initiative. One of the bloggers called it "pay it forward" to the community.

So, Anton Security Tip of the Day #6: The Other Web Log

We all know that Apache web server has its access_log log files while IIS has its w3c logs. When people think about web log analysis, they think about the above and only about the above logs, often calling them "the web server logs." However, the other web log - error_log (in case of Apache) - contain a lot of fun and useful info as well. Today's tip is to encourage the review and analysis of this treasure trough - pardon the idiom - of insight.

So, what goes into the error_log? Well, errors, duh! Why errors matter? 'Cause errors often present the only indication that a) you are being 0wned or, worse, that b) you've been 0wned by the attackers. Additionally, apart from the obvious security usage mentioned above, errors matter since they - or rather, some of them - require actions by the user and thus knowing about them is of huge importance. What is even more striking is that many error messages present an interesting tradeoff - do only a little now to correct the reasons (or, "the root cause" as network management people would say) for the error, or do a whole lot later when the system crashes, gets hacked or "misbehaves" in some other truly spectacular way. Now, a grizzled BOFH would surely say "heh, but who would want to do that! surely, dealing with a dramatic world-ending catastrophe later is more fun that making a minor config fix now." Well, I sincerely hope not all of my readers are such people :-)

Now, back to the Apache errors; we are going to show a few examples from a live phishing site, run by the attackers on a compromised server. We will start from the obvious - server restart, which actually happened as a result of an attack, in our case.

[Sun Mar 12 04:02:05 2006] [notice] SIGHUP received. Attempting to restart

Did YOU restart the server? No? Two choices then - someone else did (likely without permission!) or the server got restarted automatically for whatever strange reason. You certainly need to be at least somewhat concerned in both cases - thus: look for the above messages.

Here are a few more fun examples - the relevance of those for your business is left as an exercise for the readers, but all of the messages below

[Mon Mar 13 14:54:11 2006] [error] [client 10.10.10.10] Premature end of script headers: index.htm

Does "index.htm" sound like a script to you? It sure should not; and this error message indicates that somebody is trying to run it as a script - a clear indication of malicious behavior. The next message is also similar in this regard:

[Mon Mar 13 14:54:26 2006] [error] [client 10.10.10.10] attempt to invoke directory as script: /var/www/cgi-bin/tcpsupport/

and so is this one:

[Mon Mar 13 14:54:23 2006] [error] [client 10.10.10.10] (8)Exec format error: exec of '/var/www/cgi-bin/tcpsupport/main.htm' failed

Other interesting things spotted on the same server -this one looks like an overflow attack attempt (and, no, the NIDS did not make a squeak about it)

[Thu Mar 19 07:16:11 2006] [error] [client 10.10.10.10] request failed: URI too long (longer than 8190)

So, to conclude, the tips is: when doing web server log analysis, make sure you look at the error logs as well as the access logs.

Also, I am tagging all the tips on my del.icio.us feed. Here is the link: All Security Tips of the Day.

Does the Word "Content-Free" Rings a Bell? :-) More on Logging

This piece, even though it borders on being content-free at times :-), has a few fun insights on logging and audits (some painfully obvious to us logging people :-))

For example: "Does the fact that audit logging is enabled satisfy all the different regulatory compliance requirements? [...] In all but the most generic cases, the clear answer to this is no." But of course! Having logs is great, but looking at them is awesome (and sometimes required - see PCI Requirement 10)!

Or this "gem" - "The problem is no one looks at these logs unless something bad happens" which goes straight back to my famous (and old) "Five Mistakes of Log Analysis" paper (an update, called "Six Mistakes of Log Management" is to be published soon) Having a log management solution solves this one nicely.

Or this one: "Audit logging is not just for compliance reasons." Guess what, every sysadmin worth his salt have known this for, say, 20 years :-)

Overall, the piece is much better at asking questions than giving answers. Seriously, is this true: "What do you log? Do you look at successes and failures? How vulnerable are your logs once they've been written? How long do you keep your logs? Only you can answer those questions." No, there are pretty good answers already given to the questions above. Such answers are given in various regulations (some mentioned in the article) as well as "best practice" and IT governance frameworks, such as COBIT, ITIL and various ISO docs.

Mike Rothman kicks it as well by saying "Kevin Beaver beats the horse a bit too much about why you should log (providing the regulatory context) and not enough perspective on how you should do it."

In any case, I liked the blurb since it helps to bring awareness of log management to those still hiding from it under their desks...

Today is My Birthday ...

... feel free to send gifts NOW!

UPDATE (based on a comment below) - my Amazon wishlist

Yet Another Not So Old Presentation on Linux Intrusion Discovery

Here is one more of my old gems: a presentation on Linux Intrusion Discovery.... This presentation from a couple of years ago covers how to discover the common signs that your Linux system is compromised by attackers (yes, it has stuff on logs as well, of course, but not as much as I wanted - maybe I will create something separate in the future)

ISP Have to Preserve and Destroy Logs, Both at the Same Time

Here is a bizarre story, related to log management. "The highest appeal court in Germany has decided that T-Online, one of the largest German ISPs has to delete all IP logs to guarantee the privacy of their customers."

Obviously, all I know is the press story, but it sounds weird enough to mention. Moreover, here is how it works, reportedly.

"The decision (German) does not mean that T-Online is now obliged to delete all their IP-logs, the customers first need to complain. "

So, lemme understand, the logic is "surf to an illegal website -> complain to an ISP -> have the proof of that removed." Neato! The only thing that mitigates it is the fact that many ISPs would not have retained the logs anyway ...

And it ends with: "After the district court and the regional court, now the federal appeal court decided that T-Online has no right to store the IP-logs without a legal reason." [whatever such reason might be]

It also seems directly related to this piece of mine on "Access vs Access + Audit." I also wonder what happens if some regulations call for log retentions while others for log destruction and you are subject to both. Aaaah, compliance is so much fun!

On Cyberterrorism and ROI, Kind Of

"What would the ROI be for a terrorist organization wanting to take advantage of cyberterrorism, and how would they measure it?"

Read it; I won't spoil the conclusion for you here, but it is pretty much what you'd think :-)

Not New, But Interesting: Anti-Virus is "Dead"

Just a fun read - here is quote: "Bottom Line: By the end of 2007 stand-alone AV will be dead, d-e-a-d, dead! Organizations need to evolve their client security programs or expect to see increased costs as the number of agents continues to rise."

Another Fun Old Preso: "FTP Server Intrusion Investigation"

Here is another fun old preso of mine: "FTP Server Intrusion Investigation." Now famous FTP server intrusion investigation, including log analysis, disk forensics as well as lessons learned; all still fun and useful, but circa 2002.