[SecurityRatty] tag: evil

Is it a virus?

Fri, 03 Oct 2008 20:00:00 +0000

I get a lot of e-mail from people who believe their computer is infected by a virus. In most cases, it's not infected at all - evil software designers are still outnumbered by incompetent ones.

Copycat Web Malware Exploitation Kit Comes with Disclaimer

Wed, 01 Oct 2008 22:58:01 +0000

Such disclaimers make you wonder what's the point of including a notice forwarding the responsibility for the upcoming cybercrime activities to the buyer, when the seller himself is offering daily updates with undetected bots, and is promising to include new exploits within the kit.

For the time being, this recently released copycat web exploitation malware kit, includes two PDF exploits, IE snapshot, and naturally MDAC, with a DIY builder for the binary. Here's the disclaimer, greatly reminding us of Zeus's copyright notice :

"Purchasing this product, you hold the full responsibility for its usage and for consequences which may have been caused by incorrect usage or the usage with some evil intent or violation of the usage rules. The author excludes the placement of the scripts somewhere on the Internet, you can only place them on localhost, virtual machine or on a test botnet (minibotnet). WARNING! The usage of this product with evil intent leads to the criminal responsibility!"

What happens when the buyer tries to resell the kit? - "If you try to resell, decode, remove the boundaries, you will lose all the support, updates and guarantees." which is surreal considering that the kit is open source one, and just like we've seen with a recent modification of Zeus if it were to include unique features -- which it doesn't -- others would build upon its foundations.

Going through the exploitation statistics of a sample campaign, you can clearly see that out of the 859 unique visits 250 got exploited with outdated and already patched vulnerabilities. Therefore, diversifying the exploits set would have increased the number of exploited hosts.

With IE6 visitors exploited at 46% as a whole, it would be hard not to notice that just like Stormy Wormy's historical persistence of using outdated vulnerabilities, a great majority of today's botnets have been aggregated using old exploits.

Trying to enforce the intellectual property of a malware kit means you're claiming ownership, and therefore the disclaimer becomes irrelevant.

Assets Good Until Reached For

Mon, 15 Sep 2008 05:41:43 +0000

A few months back Minyanville wondered whether this subprime mess would end up as a cancer or a car crash. Guess we know the answer now. The question is - should we be at all surprised? Some smart folks have been warning for a long time. Warren Buffett famously called derivatives financial weapons of mass destruction.

Charlie Munger, as he is wont to do, went a bit further (from 2004):

I think a good litmus test of the mental and moral quality at any large institution [with significant derivatives exposure] would be to ask them, "Do you really understand your derivatives book?" Anyone who says yes is either crazy or lying.

They have many other statements in the same direction, based on their own experience from buying companies that used deriviatives where they were unable to to unwind the books and figure out who owed who. At the last Berkshire Hathaway annual meeting someone asked Charlie Munger what we could learn from past blow ups about the present crisis

It was a particularly foolish mess. We talked about an idiot in the credit delivery grocery business, Webvan. Internet based delivery service for groceries -- that was smarter than what happened in mortgage business. I wish we had those Webvan people back.

What can we learn from all this?

Well Dan Geer launched a revolution with his famous speech about risk management. He got the big picture part right on the security industry evolving into more risk management practices, however the examples we assumed that were right at the time, the financial industry are proving wrong. For one thing you can't manage a risk if you don't know the assets (back to Charlie Munger, emphasis added):

It is crazy to allow things to get too big to fail, run with knavery. As an industry, there is a crazy culture of greed and overreaching and overconfidence trading algorithms. It is demented to allow derivative trading such that clearance risks are embedded in system. Assets are all “good until reached for” on balance sheets. We had $400m of that at general re, “good until reached for”. In drug business you must prove it is good. It is a crazy culture, and to some extent an evil culture. Accounting people really failed us. Accounting standards ought to be dealt with like engineering standards.

So, yes it is about risk management, but if you build too many abstractions on top of your assets through derivative accounting and such you may find you don't have any assets when you need them. Don't fall in love with your abstractions, manage your assets.

There are some clear lessons for us in Information Security, err I mean Information Risk Management.

Margin of safety Its our job to manage risk, but this doesn't mean that we have to build layers and layer of abstraction on top of it. It also means that we help to design, build, deploy, and operate systems with margins of safety. Understanding the failure modes and accounting for this in design. Developers (because they are supposed to) and architects (because they haven't been properly trained) focus on functional requirements, building features, but on security not so much. There are many ways to improve security in a system and they are all inadequate by themselves, but we can help find cost effective improvements.

Don't fall in love with abstractions

If you have a 100,000 dekstops or 100,000 servers it hard to manage. You will need to automate and to do that you need to abstract, but you should also realize that its a drawing on a whiteboard not reality. You need abstraction assurance.

Ian Grigg commented on an earlier post

There are distinct parallels between phishing / retail payments, and the bigger investment mess. In both cases, banks would argue these are core business. In both cases, they have applied risk-based security models, and accepted some loss. In both cases, they have the ability to apply substantial experience to the monitoring, allocating and absorbing risks and losses.

In both cases, they watched and did nothing as the risks started from low, and migrated upwards. Are we at the point where regulation has killed the ability of banks to apply their (arguable) one core skill, to whit, risk-based analysis? Are banks that far out of banking that they no longer have it?

So you have to remember that top down and bottom up need to be combined.

Design for failure

Dan Geer has also told the story that he sat in a large bank's risk management training, and the trainer said "you may wonder why this works so well. it works because there is zero ambiguity over who owns what risk." Dan's thought was - "in my field we have nothing but ambiguity." Turns out the second part was right, we have nothing but ambiguity over who owns what risk; unfortunately the financial people have much more ambiguity than they thought! So we do have a lesson here after all, and it this - when the thing you thought was true isn't, the failure mode is very ugly. Design for failure - add layers of protection.

Keep it simple.

They have some smart engineers at Google to be sure, but even they had incredibly basic errors in their SSO. I have seen other obvious fails like people signing WS-Security messages, and the recipient checks for a signature but not if they trust the signer! There are so many ways to shoot yourself in the foot in a loosely coupled systems, and we have so many abstractions layered on top of each other, part of the mantra of protecting assets has to be keeping it simple.

So that is my list, to do all these things it requires that Infosec get in the game, understand the use cases, understand the business value (it should be abundantly clear that you can't simply rely on "business people" to be "business experts"), and that you not lose sight of the asset amidst all the abstraction. Finally, the systems we build security on are very primitive, a firewall and SSL are fine, a seatbelt was fine in 1935 and its still fine today, but there are lots of other safety controls in cars. ABS, airbags, traction control, they all protect the assets far better than in 1935, that's what we need to build.

Anyone can make bad assumptions (assume you know who owns what risk) and its easy to make bad abstractions (the firewall protects the information system), but when you combine bad assumptions with bad abstractions you'll get assets that are good until reached for sooner or later

UK Police Seize War on Terror Board Game

Fri, 15 Aug 2008 02:50:02 +0000

They said -- and it's almost to stupid to believe -- that:

the balaclava "could be used to conceal someone's identity or could be used in the course of a criminal act".

Don't they realize that balaclavas are for sale everywhere in the UK? Or that scarves, hoods, handkerchiefs, and dark glasses could also be used to conceal someone's identity?

The game sounds like it could be fun, though:

Each player starts as an empire filled with good intentions and a determination to liberate the world from terrorists and from each other.
Then the reality of world politics kicks and terrorist states emerge.

Andrew said: "The terrorists can win and quite often do and it's global anarchy. It sums up the randomness of geo-politics pretty well."

In their cardboard version of realpolitik George Bush's "Axis of Evil" is reduced to a spinner in the middle of the board, which determines which player is designated a terrorist state.

That person then has to wear a balaclava (included in the box set) with the word "Evil" stitched on to it.

Buy yours here; I first blogged about it in 2006.

Twelve billion dollars!

Wed, 13 Aug 2008 10:37:00 +0000

Sounds like a Dr. Evil sound bite :). In fact this could be the potential impact of the 41 million cards stolen - according to security company Jefferson Wells. The amount is a result of simple multiplication - 41 million x $300 for each card lost. On the higher end, no doubt.

While I don't think the real cost is anywhere close to that (even by an order of magnitude), it is still a large number. Even at street price of $2 per card, someone must be making 41 million x $2 = $82M!

More scary to imagine, is where this stolen data is going, what kind of money they are making and what illegal stuff is being done with it.

76Service - Cybercrime as a Service Going Mainstream

Wed, 13 Aug 2008 04:08:43 +0000

Disintermediating the intermediaries in the cybercrime ecosystem, ultimately results in more profitable operations. Controversial to the concept of outsourcing, some cybercriminals are in fact so self-sufficient, that the stereotype of a mysterious 76service server offered for rent could in fact easily cease to exist in an ecosystem so vibrant that literally everyone can partion their botnet and start offering access to it on a multi-user basis. Evil? Obviously. Extending the lifecycle of a proprietary malware tool? Definitely.

The infamous 76service, a cybercrime as a service web interface where customers basically collect the final output out of the banking malware botnet during the specific period of time for which they've purchases access to the service, is going mainstream, with 76Service's Spring Edition apparently leaking out, and cybercriminals enjoying its interoperability potential by introducing different banking trojans in their campaigns.

In this post, I'll discuss the 76service's spring.edition that has been combined with a Metaphisher banking malware, an a popular web malware exploitation kit, with two campaigns currently hosting 5.51GB of stolen banking data based on over 1 million compromised hosts 59% of which are based in Russia. Screenshots courtesy of an egocentric underground show-off.

Some general info on the 76service :

"Subscribers could log in with their assigned user name and password any time during the 30-day project. They’d be met with a screen that told them which of their bots was currently active, and a side bar of management options. For example, they could pull down the latest drops—data deposits that the Gozi-infected machines they subscribed to sent to the servers, like the 3.3 GB one Jackson had found. A project was like an investment portfolio. Individual Gozi-infected machines were like stocks and subscribers bought a group of them, betting they could gain enough personal information from their portfolio of infected machines to make a profit, mostly by turning around and selling credentials on the black market. (In some cases, subscribers would use a few of the credentials themselves). Some machines, like some stocks, would under perform and provide little private information. But others would land the subscriber a windfall of private data. The point was to subscribe to several infected machines to balance that risk, the way Wall Street fund managers invest in many stocks to offset losses in one company with gains in another."

The 76service empowers everyone who is either not willing to spend time and resources for building and maintaining a botnet, launching campaigns, and SQL injecting hundreds of thousands of sites in order to take advantage of the long tail of malware infected sites that theoretically can outpace the traffic that could come from a SQL injected high-profile site.

Next to the spring.edition, the winter edition's price starts from $1000 and goes to $2000, which is all a matter of who you're buying it from, unless of course you haven't come across leaked copies :

"Assuming that the dealer offering what he claimed was the 76service kit was correct, the profit is not only in the kit, but in selling value added services like exploitation, compromised servers/accounts, database configuration, and customization of the interface. Prices start between $1000 to $2000 and go up based on added services. The underground payment methods generally involve hard-to-track virtual currencies, whose central authority is in a jurisdiction where regulation is liberal to non-existent, and feature non-reversible transactions. The individual or group called "76service" was easy to track down on the Web, but not in person."

It's interesting to monitor how services aiming to provide specific malicious services are vertically integrating by expanding their portfolio of related services -- taka a spamming vendor that will offer the segmented email databases, the advanced metrics, and the localization of the spam messages to different languages -- or letting the buyer have full control of anything that comes out of a particular botnet for a specific period of time in which he has bought access to it. For instance, DDoS for hire matured into botnet for hire, which evolved into today's "What type of stolen data do you want?" for hire mentality I'm starting to see emerging, next to the usual interest in improving the metrics and thereby the probability for a more succesful campaign.

Ironically, this cybercrime model is so efficient that the people behind it cannot seem to be able to process all of the stolen data, which like a great deal of underground assets loses its value if not sold as fast as possible. The result of this oversupply of stolen data are the increasing number of services selling raw logs segmented based on a particular country for a specific period of time.

Time for a remotely exploitable vulnerability in yet another malware kit about to go mainstream? Definitely, unless of course backdooring it and releasing it doesn't achieve the obvious results of controlling someone else's cybercrime ecosystem.

Related posts:
The Underground Economy's Supply of Goods and Services
The Dynamics of the Malware Industry - Proprietary Malware Tools
Using Market Forces to Disrupt Botnets
Multiple Firewalls Bypassing Verification on Demand
Managed Spamming Appliances - The Future of Spam
Localizing Cybercrime - Cultural Diversity on Demand
E-crime and Socioeconomic Factors
Malware as a Web Service
Coding Spyware and Malware for Hire
Are Stolen Credit Card Details Getting Cheaper?
Neosploit Team Leaving the IT Underground
The Zeus Crimeware Kit Vulnerable to Remotely Exploitable Flaw
Pinch Vulnerable to Remotely Exploitable Flaw
Dissecting a Managed Spamming Service
Managed "Spamming Appliances" - The Future of Spam

The Attack of the Spiders from the Clouds

Thu, 31 Jul 2008 11:09:19 +0000

We have seen a lot of discussions of cloud computing in the news recently, as a technology to permit “users to access technology-enabled serviceswithout knowledge of, expertise with, nor control over the technology infrastructure that supports them.” This sound great doesn’t it?! Users with little to no IT expertise can log into the cloud and launch 8 instances of a server with the equivalence of 16 high performance CPU cores. However, as we all know, all things, including cool technologies have the potential for both good and evil, opportunity or threat; and cloud computing is no different.

It just so happens that I have been experimenting with Amazon Elastic Computing Services (EC2), documented in Computing in the Clouds with AWS over at The CEP Blog. The server over at The UNIX and Linux Forums has been experiencing some very hardware-limited, high load averages recently. We thought we should take a look at moving the forum server up to the clouds.

Then, a fellow system admin over at the forums suggested that maybe some rogue bots were causing high server loads; so I wrote a one-line command to do a bit of real-time spider hunting in the Apache2 logfiles. Surprise! I found there were a number of rogue, hungry spiders that would not follow our robots.txt directive not to crawl the site. One of the bots was from Russia, one was from China, and another one was from Korea. There were spiders from places I never heard of, all consuming precious resources and denying our users!

So, I did what any Linux admin would do. I used iptables to block the networks of these rogue, hungry, spiders (sorry I was not very kind to these cyber creatures). It probally comes to no surprise at this point in the story that four of the spiders were from the Amazon EC2 cloud. Here is a sample of the output from iptables -L:

root@www:~# iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP all — ec2-67-202-45-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-243-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-197-0.compute-1.amazonaws.com/24
DROP all — ec2-75-101-213-0.compute-1.amazonaws.com/24

Well, imagine a not-so-distant future dystopian world where criminals or terrorists want to launch a massive denial-of-service attack against some critical infrastructure, like the root DNS servers, or an attack against major financial institutions, military or e-commerce sites.

First, the bad guys create an instance of powerful operating system with a malicious network application, they test it, and they place it the cloud (without invoking the instance, paying a very small storage fee, no computing time fee) and they wait. Then, at the precise moment of their planned attack, they launch 128 instances each with the equivalence of whatever is the mega-platform at the time, and just blast away at their attack target(s). Even more damaging, they do this from many cloud computing infrastructures. (Note: The cost of the attack is minimal because the criminals are only charged a few pennies an hour for each running instance and the attack runs an hour or two.)

My experience with cloud computing, which is still maturing, is that cloud computing has great promise for both good and evil. The very real example of the “spiders from the clouds” is a harmless enough story of folks using a cloud computing infrastructure for web crawling, perhaps hoping to be the next Google billionaires.

One the other hand, cloud computing brings with it an emerging and growing danger for the misuse of the power of cloud computing infrastructures. The misuse could be malicious, or accidental, but never-the-less, the danger is real.

What an interesting world we have created! Would would have ever dreamed 10 years ago that we could be attacked by ……

#include

…. Spiders from the Clouds.

Reprinted by permission from The Attack of the Spiders from the Clouds by Tim Bass, CISSP

Silver Bullet Talks with Adam Shostack

Thu, 31 Jul 2008 09:30:21 +0000

Gary McGraw interviews Adam Shostack. Shostack is a member of Microsoft's Secure Development Lifecycle Team. He's worked for Zero Knowledge as Most Evil Genius and Reflective where, as CTO, he focused on static analysis for software security. Shostack recently coauthored The New School of Information Security with Andrew Stewart.

Admins , Good Guys or "I am NOT an Idiot!"

Tue, 29 Jul 2008 11:19:00 +0000

This is a follow-up to this ("On Doomsaying (Terry Childs case)") and this ("So ... Am I? Maybe I Am!"), both related to Terry Child case, as well as a response to this post by Paul Venezia ("The anti-admin stance and the Childs case").

First, let me disclose something - my frantic efforts with the Paint allow me to proudly proclaim: I am a certified, trusted "Good Guy":

Good guys, let me tell you, do not need any controls placed on them; they are "trusted." Don't you have to trust somebody? Why not trust a sysadmin, for example?

So, what about controls? Ah, glad that you asked! "Controls" are for the bad guys; they are in place to prevent the bad guys from doing "an unspeakable evil" (tm) :-) on you. On the other hand, good guys are doing "the right thing" every time - why monitor them? It goes without saying that nobody ever moves between these groups, especially, not from "good guys" to "bad guys."

As I am rambling about this, many of my security-minded readers are wondering "what is Anton up to? Isn't it kind of OBVIOUS that controls are for everybody?" Controls know no good/bad! For example, a network control, say a NIPS, will block malicious web access due to a typo in a URL (by - gasp! - a good guy) or due to determined malicious hacking.

I think a few of my readers have watched one too many "Batman" movies and have acquired the dark side of the "IT hero" mentality." How about getting an "IT employee" mentality? If your boss is an idiot (and Terry's managers definitely seem pretty far gone in that direction...), than your "heroic duty" is to let them impale themselves on a sword of their idiocy, not to commit crimes (even if cybercrimes) to prevent that idiocy. Really, go find another job if you do not like the environment; good admins are needed in many places. For example, if your boss insists on posting all VPN passwords for all users publicly out of his sheer and unfathomable stupidity, it is your duty to tell him that it is "a very bad idea" - and not to change all passwords and not let him see it. "Doing you job" despite your boss and despite the law just doesn't work...

In other words, I want a banker making policy decisions at a bank, not a sysadmin. If a banker makes a wrong decision, his will suffer. If he is an idiot, he will most likely make the wrong decision. However, it is NOT the admin's decision to make - he does not "own" the business. BTW, the fact that it is a city, not a bank, and it is taxpayer funded, does not change it.

Am I "anti-admin" for saying that admins should not run the business? Am I "anti-admin" for saying controls (at least logging/auditing) on administrator activities are needed? You call it "anti-admin", I call it common sense!! Pray tell me, what makes admins float above accountability, control and IT governance?

Please also read what Randy Smith said about this issue; a lot of good thoughts that I agree with.

Now I would like to respond to specific comments from my readers:

"What rankles your readers is how blithely you imply this problem has a simple or effective solution. It doesn't, all the processes or tools you advocate can do is speed up the time it takes to detect the lock-out, but not actually prevent it - i.e. they are ineffective at tackling the primary problem."

That is correct; the rogue admin problem has NO simple solution. You might prevent some (few, really) things, you might log some of them and then figure what happened, but there is no simple solution (it goes without saying that "just trust them" is NOT a solution...)

"We all know companies run without sane risk management all the time and are rarely held accountable in America. What makes you think anyone is "screwed"?"

Well, this is a good point; maybe I let my idealistic side take over. But, come on, just the fact that bad IT governance is somewhat common, doesn't make it right!

"Now ask yourself who is "screwed" by one person at a small company having all access and no accountability on a network. That's how I run my home network. Big deal."

Nobody is. I addressed it here. The risk is acceptable for smaller environments, usually. I don't have an overseeing body set up to control my home passwords :-)

"You seem to forget that sometimes the management just has to trust somebody. "

Addressed above.

"Chuvakin, you're a tool. Given the recent idiocy of the releasing of the VPN names and codes, it obviously shows that any sort of detest that Childs had against his superiors at the city were justified."

The fact that his bosses are idiots (which seems fairly well established!) does not make him right!

Bad boss + admin out of control =/= right :-)

"This is not a private organization. His superiors don't own the company and are NOT entitled to the data. We are, the taxpayers. And as a California taxpayer I fully support someone with the paranoia and technical skill of Terry Childs over a group of bureaucrats who release secure information to the public."

Properly evaluating this statement requires a law degree. Thus, no comment. Bureaucrats suck, but rogue admins are not a solution to that. Really!

"The guy was doing his job and doing it incredibly well, and keeping it out of the hands of those who, given their most recent choices, would bring potential disaster to the city."

He was NOT, unless crime is part of his job :-) Also, see comments on "IT heroes" above. If your boss is an idiot AND you don't like it, quit.

"Anton Chuvakin seems to think that all admins should be kept underneath management's boot at all times. [...] Managers can't and don't understand what we do, and thus eventually come to the conclusion that we can't be trusted with our own knowledge. [...] Perhaps it's human nature to fear what you don't know or understand -- and that's why management can develop a fear of their own employees."

You say 'fear of employees', I say "insider risk management." You say "trust employees", I say "trust but [be able to] verify (=log)"

"his blog leads the casual reader to infer that their businesses are in danger of being hijacked by disgruntled Sys Admins and that isn’t the case." (from here)

Eh, not all businesses, but some businesses - definitely (hmm, see Terry Childs story or other published insider attack cases, all the way back to Omega Engineering case and maybe all the way back to ancient history)

"I despise people like Terry Childs, but despise Chicken Little’s like Anton Chuvakin even more." (from here)

You say I am 'chicken little', I say "if your boss ignores insider risk management, he is stupid and deserves his business to fail." I also add "if you think admins are 'above the law', you have a good chance of 'turning rogue' yourself AND then ending in jail."

Finally, this and my other posts about the case are inspired by on the media reporting; I possess no "insider knowledge" on this case whatsoever.

Possibly related posts:

Your 3 Favorite Linux Commands?

Fri, 25 Jul 2008 10:02:41 +0000

Here’s a fun Friday post…

Some of you may know I’ve been preparing to brush up on my *nix skills. A couple of our new solutions are running on Linux platforms and I feel compelled to understand any platform I’m working with inside and out… I know, it’s a bit OCD.

But to be honest, I haven’t really touched a Linux platform for about 10 years, since I was one of the three students running the Sun network over at NCSSM. I still remember the humorous ‘root’ ‘of all evil’ admin name that we used and the password, iaceo (in mixed caps), which was a Latin word for (I think) to lie dead. (Please correct me if you know what it means). When you’re 17, these things are amusing.

I’ve kept my ls-ing and cd-ing over the years, but will be brushing up on the grep-ing and tail-ing ;)

So with any system, I think we all have our favourite commands that we use daily and are part of our daily arsenal. I’m working out mine but wanted to hear from you…

What are your 3 favorite Linux commands?

And is there 1 obscure one you really love (or hate)?

# # #