Archive for the ‘Malware’ Category
Wes Brown | July 1st, 2008 | Filed Under: Industry Punditry, Malware
Why am I qualified to write about this?
In a former life, I was a malware analyst. It was my job to analyze incoming samples and determine if they were false positives, or false negatives. I also worked on automating the process, and it was a very neat job. Unfortunately for me, economic realities and the precarious nature of startup companies dictated other career paths. I had analyzed literally thousands of samples, and took notes on characteristics to help improve the anti-malware product.
Eventually after a while of doing this, I have some observations on where malware is going, and I’m going to share some of them in this post.
Growing Internationalization
In the past, an anti-malware company could focus on English-targeted samples. But an increasing percentage of malware samples are international in origin and targeting international machines. I saw numerous cases of Chinese malware targeting Chinese software or hosts. This was quite a challenge to determine if it was malware or not for several reasons.
Cultural Impact
One of the most fascinating facets of the increasing internationalization of malware is the cultural assumptions around such software. What is considered malware in the US may be commonly accepted in China or Japan, and this is largely due to the society that it exists in.
Anti-cheating rootkits are very common in games released in these countries. What is considered to be invasive in the North American or European world is acceptable there. These anti-cheating rootkits would hook into the kernel space in a very invasive way, and have the behavioral characteristics of malware such as hooking into the keyboard driver. This made it very difficult from a purely technical standpoint to distinguish them. These kits were attempting to protect the application from being tampered with while running, i.e. to reduce the incidence of bots, or modifications to the presentation layer to allow people to see through walls. They would watch for kernel debuggers, or running processes that did specific characteristic behavior. These very techniques would flag them as malware as many such samples would behave similarly to avoid antivirus or to prevent someone from easily reverse engineering them.
If I applied US standards to these particular samples and declared them a true positive, then we would have many angry international customers when their games no longer worked. This also applied to extremely intrusive adware. But these pieces of software could run on US machines as well, so it was a very tricky balance.
Linguistic Barriers
In the past, if I ran into a piece of malware that had foreign language strings in them, I could muddle through them if they were a Latin-derived language. Spanish or French, I did not have any issues with. But when it comes to languages that come from an entirely different root such as Chinese or Japaense written in hanzi or kanji, I was losing vital clues.
By looking at the behavior of the sample alone, I would declare it malware. But what if it was one of the aforementioned game rootkits? How do I know that the game actually includes it, or if it was indeed a trojan’ed game? With English language samples, I would simply look at the strings, or use Google. But I had to muddle through pages in a writing system that I could not easily begin to comprehend.
So, if you want to be a malware analyst, it would be in your best interest to become conversant or fluent in one or more of the non-Roman languages.
Internationalization of Antimalware Tools
As we are dealing more and more with malware samples that are international in scope, it becomes important that the tools themselves are internationalized. With the growth of samples targeted at other languages, the automatic tools that I wrote primarily dealt with ASCII and were becoming inadequate. String and keyword analysis did not work well. Tools need to be Unicode and multi-lingual.
Hints for International Malware Analysis
- Pay close attention to the signers of samples, whether they are signed or not. Once you have verified a signed application, consider it the baseline.
- Once you have multiple samples of what appears to be the same application but has different checksums, pay close attention to file size, and the version, vendor strings. Interestingly, many trojaned applications do not have the correct version and vendor strings.
- Use entropy to your advantage. Measure the entropy of the binary segments that you have. If they have very similar entropy values, and have a minor increment in version, the probability of it being a trojan is much lower.
- Pay close attention to the vendor and version strings of samples. See if you can get an authoritative version of the application from the vendor’s site and compare it. Once you have a sample that you can declare as as false positive, all other similar samples are much easier to analyze.
- Take note of what binary packers they are using. Certain packers have a higher probability of being used by malware. But there are legitimate use of packers, and some antivirus products will trigger a false positive on a packed application, no matter what.
- Build a library of samples, and understand the cultural context of the country of origin and destination. Categorizing the sample characteristics by these criteria will help you determine if it is a true or a false positive for that particular market.
Conclusion
It is becoming more and more important that entire infrastructure of malware analysis, from anti-malware client to backend infrastructure to the analyst herself become multilingual and multicultural. It is a difficult challenge that is going to crop up more and more in the future.
11 Comments
Mike Tracy | June 26th, 2008 | Filed Under: Defenses, Malware, New Findings
1.
Some of my
favorite
reads (there are
others) have recently written about about Scrawlr and some of what I
have read has been critical. Critical enough? Depending on your level of
pedantry with respect to webapp security and/or free software, probably
not.
Stop that. Right now. Overlook the limitations of the tool that was
released, realize that this is a closely targeted thing designed to help
alleviate a specific problem. Go back and think a little harder about
what is going on and why this is actually A Good Thing(tm).
This scanner, released as part of the advisory, is specifically designed
to help people who run websites that have been targeted by this ongoing
and massive SQL injection attack shore things up. The tool has
limitations. Quoted from a text file included with the Scrawlr package:
This is a free tool and is intended to find SQL Injection
vulnerabilities on pages that hackers can discover using a simple
crawler or google query. This application mimics a search engine
crawler and lacks the advanced crawling and auditing features of tools
such as WebInspect, DevInspect, QAInspect, and AMP. Thus Scrawlr will
only find SQL Injection vulnerabilities on GET Parameters; Scrawler will
not submit forms, nor audit them. The list below summarizes the
limitations:
- 1500 Max Crawled URLs
- No Script parsing during crawl
- No Flash parsing during crawl
- No form submissions during crawl (No POST Parameters)
- Only simple proxy support
- No authentication or login functionality
- Does not check for blind SQL injection
The scanner is built to look for things being indexed by search
engines. If those sites are fixed, 99.999% of the problem should go
away.
Trying to compare Scrawlr to a full blown SQL Injection scanning tool is
like comparing a letter opener to a Swiss Army Knife. Sure, you can do
other things with a letter opener (and some of you probably want to slit
my throat for that simile. That’s fine, use the knife) —- but its stated
purpose is to open letters.
2.
The limitations aren’t that bad. Take the biggest one, authentication. I
tried it. For the vast majority of sites, “authentication” means “HTTP
forms that set cookies”. For those types of sites, it was easy to get
the tool to operate against sites “post authentication”. (I didn’t try
for basic/ntlm/digest —- I don’t have a ready test subject. I’d be
surprised if it worked.)
Using burp suite do the following:
- Login to the application using a web browser
- record the Cookie: header
- in burp go into the Proxy -> Options tabs
- go to the “match and replace” section
- add a new header
- Type: request-header
- Match: ^Accept.*$
- Replace: Cookie:
- point Scrawlr at your running proxy
Basically, just replacing the Accept: */* header that Scrawlr sends
with a Cookie header.
Yay! A free tool that people can use to see if their sites are
vulnerable to mischief. Plus! A free code scanner and a free sort of
maybe web application firewall to help them protect themselves. Your
old ASP sites are now safe from all this ruckus.
3.
I spent some time talking about this with colleagues (colleague n.
drinking buddy) at ChiSec last night [if you weren’t there it was a
blast and you should come to the next one -ed.] and as much as I love
the idea behind this, consternation is bubbling beneath the surface.
What I’m having trouble understanding are the motivations of Microsoft
and HP and their estimation of how effective this will actually be.
This is either Defense In Depth’s red-headed stepchild cum marketing
ploy or… Not sure I actually see an “or”. Half-baked code analyzer
(ok I don’t really know that but…)? Check. Web Application
Firewall Lite? Check. Hey! Get the guys at SPI to throw in a
cripple-ware SQL injection scanner and we’re all set to at least appear
like we are trying in some way to maybe have a chance at helping a
person or two.
Great!
I want a count of the owners of target audience websites who actually
read the advisory, understand it, realize they are affected and then
actually use any of the schwag provided to help them solve their
problems.
Microsoft seems like a good egg for going to all this trouble and HP
gets their name on it. Maybe people will come sniffing around for a
“real” security tool or two. Humbug I say!
In the end, motivations are incidental. I’m really just interested in
seeing how effective this is.
5 Comments
Dave G. | November 24th, 2006 | Filed Under: Malware
Tis the season! Looks like the same fellow who did this chose Thanksgiving Day to strike again. Good timing from an attacker perspective. This was sent to my Yahoo IM:
http://www.geocities.com/isyourfriendneartoyou08/ Find your match
And then it:
- presents a Yahoo! Photos page
- steals credentials on submit
- sends it to: http://www2.fiberbit.net/form/mailto.cgi
- who mails it to “sanchopansas@gmail.com”
- redirects the user to their own Yahoo Photo’s page
- logs into Yahoo IM as the unfortunate sap
- sends the URL to everyone on their buddy list
Have (or hope you had) a Happy Thanksgiving!
2 Comments
Thomas Ptacek | November 20th, 2006 | Filed Under: Apple, Industry Punditry, Malware, Uncategorized
i.
Gruber Hides Behind Reporters and Pundits
Today’s Daring Fireball post has two objectives:
To tar eWeek Security pundit Larry Setzer, and the trade press
in general, as biased, lazy, and incompetent when it comes to
Mac security.
To claim that Mac security is better than Windows security.
We can get behind one of those objectives. But Gruber isn’t going to
let us do that: instead, he borrows support for his defensible argument
to shore up a weak argument. This isn’t a new idea; it’s straight out
of the Mac zealot playbook, and it’s the same tactic Gruber used
during the Mac wireless debacle when he hid behind Brian Krebs’
reporting to throw a smoke screen over OS X kernel wireless vulnerabilities.
Here’s an example from today’s article. Seltzer’s article claims that
a recently released Symantec report on OS X security “revealed a
collection of vulnerabilities and potential attacks that rivaled any
major operating system”, and “in fact things are getting worse.”
Instead of arguing that Seltzer doesn’t (and can’t) support that
argument with facts, which would be boring, Gruber plays to his base:
“nowhere in the report does it indicate that the ‘collection’ as a
whole rivals that of any other operating system.”
But that’s an equally indefensible argument! Seltzer himself names
operating systems that are in positions comparable to OS X: Linux and
Solaris. Gruber’s M.O. is simple and he counts on his audience not to
notice it: when a pundit or reporter overreaches, Daring Fireball
leaps on the opportunity to claim that the opposite argument is
true. It almost never is.
ii.
Gruber Conflates Malware Incidents With Vulnerabilities
Count on Daring Fireball to ask the hard questions: “[…] given that Mac
OS X has about 6 percent total market share in the U.S. and something
like 2 or 3 percent worldwide, how come Mac OS X’s share of actual
security exploits — not just potential vulnerabilities but actual
malicious spyware, viruses, worms, adware, etc. — is effectively zero
percent? That’s the real question.”
No it isn’t. Want an easy way to debunk that argument? Here you go:
MacOS 9 sees a tiny fraction of the malware Windows does. But nobody
seriously argues that OS 9, which doesn’t even have a secure VM
system, is more secure than Windows XP.
Want another? Solaris. Been around for over a decade. Hundred of
published vulnerabilities. How much malware?
Here’s another easy way to debunk the argument: Windows Vista. Has
Microsoft “retaken the lead” in OS security? I can defend that
argument a lot better than Gruber can defend his.
But I don’t have to, because malware is obviously weakly correlated
to OS security. How do we explain that?
6% Market Share Doesn’t Mean 6% Malware Share
Malware authors will target the one platform with critical
mass, because there’s no indication that there’s a “peak oil”
scenario for Windows vulnerabilities that will ever make Mac
malware pay off better. Malware authoring effort doesn’t
divide proportionally to OS share.
The Underground Hasn’t Ramped Up Yet
The Win32 API is over a decade old and is well understood by
attackers. The MacOS X APIs are not. There is a lag between
the publication of the OS and security researchers, and a lag
between research results and malware authorship.
Enterprises Set The Course For Security Research
Research efforts focus on Windows, Linux, and Solaris, because
that’s where the enterprise dollars are. Malware authors feed
on research results, so even their ideal victims are home
users, their supply chain is tied to businesses.
Viruses Don’t Exploit OS Flaws
A huge percentage of malware infections have nothing to do
with OS vulnerabilities. For the vast class of infections that
arise from user complicity, there is no evidence that the
MacOS X design is better.
There Are Existence Proofs To The Contrary
Researchers like Tom Ferris, KF, H.D. Moore, and Matasano do find
MacOS X vulnerabilities, and there is MacOS X malware,
including very viable rootkits.
Gruber retorts, “[but] if Mac OS X is protected because it’s not
primarily used as a server OS, then how do you explain Windows’s
non-server security problems?”. Easy: exploits developed for Windows
servers translate to desktop Windows.
Gruber retorts, “If there’s one firm conclusion to be drawn from the
MacBook Wi-Fi hack fiasco in August, it’s that you can get a hell of a
lot more attention for a Mac OS X exploit […]”. Where are the ego
attackers? I don’t know; what evidence does Gruber have to support the
argument that a significant portion of Windows infections are ego attacks?
iii.
Gruber Jazz-Hands Mac Security
Count on Daring Fireball for ArsTechnica-caliber technical analysis:
“The explanation that makes sense is the obvious one: that Mac OS X
really is more secure and better designed. Not that it’s totally
secure. Not that it’s perfectly designed. Not that it is utterly
impervious to attack because it’s protected by magic leprechauns. Just
that it’s better.”
If Gruber wants to claim that magic leprechauns have nothing to do
with MacOS X security, Daring Fireball should stop appealing to
those magic leprechauns. To date, Gruber hasn’t defended a single
argument in favor of the MacOS X security architecture. What he has
instead are articles of faith.
Article 1: The MacOS X Privilege Model Makes Malware Outbreaks Harder.
No it doesn’t. Here’s why:
Most Macs are single-user machines. On most single-user
machines, that one user has “Administrator”
privilege. “Administrator” is functionally equivalent to
root, even without knowing the user’s password, and that
equivalence is baked into the current architecture.
The idea that malware needs “admin” to propagate is a myth. On
almost all single-user machines, the ability to run code with
that user’s privileges is game-over: I have all the meaningful
data on the machine, I can backdoor the machine, and I can
talk to the network.
The OS privilege model doesn’t mean anything if the OS is
vulnerable to privilege escalation attacks. MacOS X has
been. For example, Matasano discovered that malware can use
the Mach Exception Port feature to load arbitrary code into
SUID-root binaries, deterministically seizing superuser
creds on an infected machine.
Article 2: MacOS X Code Is Better Designed Than Windows Code.
No it isn’t. For example:
(a) Microsoft pioneered the Secure Development Lifecycle. (b) Microsoft
delayed a critical operating system release to scrub integer overflows
out of the codebase. (c) Microsoft invented the Threat Modeling
methodology. (d) Microsoft Visual C builds executables that resist memory
corruption. (e) Virtually every line of Windows Vista has been audited by
third parties.
Does this mean Microsoft is perfect, or that MacOS X has bad code? No,
but where are the Apple counterclaims? Here’s a question for Daring
Fireball: without arguing that Apple somehow employs “better”
OS developers than Microsoft, honestly guess which OS team puts more
effort into code security, and estimate by how much.
Article 3: OS Security Features Don’t Matter.
They can’t, because if they did, Windows Vista has left MacOS X in the
dust. For instance:
Over the objections of the whole industry, Microsoft has
locked their kernel. At Black Hat, Matasano demoed malicious
MacOS X kernel code that
transparently virtualizes the whole operating system out from under itself.
The standard Microsoft libc heap is tripwired so that
malicious pointer overwrites abort the program instead of
handing control over to attackers.
The Microsoft C runtime guards activation records on the stack, so
that overruns in stack variables don’t allow attackers to
overwrite return addresses. The Win32 runtime also defends its
exception handlers. How resilient is the (vastly more complex)
Objective C “Cocoa” runtime against the same attacks?
On supported platforms, Microsoft takes advantage of CPU
“no-execute” memory protection. Apple’s current support for
the same chip features is bypassable.
Win32 has first-class support for managed code (C# and the
CLR), which sandboxes programs and provides a fine-grained
privilege model within individual programs. Apple just
deprecated Java; their high-level development platform has
no runtime security.
The Win32 address space is randomized, so that exploits with
hardcoded addresses (read: virtually all exploits) have a
negligable chance of succeeding. Despite the fact that this is
technology pioneered by BSD, MacOS X does not have address
space randomization.
None of these technologies require end-users to purchase
anything. They’re built into the operating system and the runtime
libraries. Most of them are enabled by default. They address the
same code flaws that MacOS X faces; why doesn’t Apple have them?
iv.
Gruber Holds Grudges.
The Daring Fireball wears its emotions on its sleeve. In several years
of covering MacOS X security, Gruber has only once validated security
findings against MacOS X. In order to downplay Mac threats, Gruber has
claimed:
That “to his eyes”, Tom Ferris’ Safari bugs are “all just
ways to make an application crash”, not ways for attackers
to corrupt the program runtime and upload malicious code.
That security consultant Rodney Thayer is quoted by the AP
only because he has long black hair and a beard.
That the 10.3 “malicious URLs can execute arbitrary code”
debacle was “a vulnerability, not an exploit”.
That the logistical hardship of shipping a fix to those
problems outside of a major OS update was an adequate defense
for shipping an OS update Apple knew was vulnerable to
attack.
That as of September “the only Mac user anyone can find who’s
suffered from Mac-specific malware is one single dipshit who
double-clicked a trojan horse”.
That “there are all sorts of ways that Windows executes
software that don’t have equivalents on MacOS X”, such as
the “labyrinthine” Windows registry.
In today’s post, Daring Fireball can’t just let the new
Symantec report slide; it’s only “mostly” fair, because it cites Maynor and
Ellch’s wireless flaws. Leaving aside the fact that the particulars of
the Black Hat wireless debacle are still totally unresolved, Apple has
already confirmed vulnerabilities in the wireless drivers of every
Mac portable; the MOKB Broadcom wireless vulnerability apparently
even crashes pre-patch Powerbooks.
But that’s all meaningless, because in Gruber’s worldview, who Apple
credits with security findings is more important than what
vulnerabilities are actually present in the platform. Presumably
Gruber will cry foul when someone publishes a weaponized exploit for
those problems; after all, who cares about operating system security
while Dave Maynor is still walking the streets?
v.
Gruber Isn’t Qualified To Make These Arguments
Matasano babbles endlessly about operating system security because we
deal with it for a living. I very, very rarely blog about Mac HIG
inconsistencies, or try to discern how the classic Aqua skin “feels”
about the ascendence of New Brushed Metal. I’m comfortable leaving
that to the experts, like Gruber.
But Gruber’s not content to do the same. So, despite having never
published a single finding, despite having no scholar or citeseer
hits on any security topic, despite having no discernable shipping C
code in his work history, despite having never worked in security,
and despite never sourcing anybody with any of those attributes in his
articles about security, we’re meant to take his opinions about
operating system security at face value.
This would be a low argument to make, but it’s the Mac zealots who
are picking the fight, not the Windows people. As far as I can tell,
there’s no “counter-meme” among Windows users that MacOS X is less
secure than Windows, even though as of 2007 that may very well be the
case.
The sad thing is, Gruber isn’t even doing Apple any favors
here. There’s a perfectly reasonable argument to make about how
resistant MacOS X is to malware. I’m an Apple user. It’s true! I don’t
need antivirus! I never get rootkitted! I need fewer security patches!
But I know why this is: attackers care less about me than about my
grandpa’s Windows login and his bank accounts, which they can get with
almost zero effort. Irrelevance is a meaningful security
feature. As long as MacOS X has it, why can’t Gruber be happy with
it? Why does he have to make stuff up?
52 Comments
Thomas Ptacek | August 22nd, 2006 | Filed Under: Defenses, Malware, Uncategorized
Dave wrote yesterday about the McAfee AVERT lab objections to ISE’s
Consumer Reports test of antivirus engines. I have more to add.
The ISE team manufactured a stream of “new” viruses, in part by
generating semantically-equivalent variants of existing viruses. This
data set showed suprising problems with well-known AV engines.
Igor Muttik, a longtime member of McAfee’s antivirus research group,
complained, writing that the more “scientific” way to approach this
problem is to conduct a “retrospective” test. From his 2001 paper,
which he cited:
Retrospective testing is used to test proactive abilities of
scanners. The idea idea is to take, say, a three-month-old scanner
and compare the detection rates over the viruses that appeared
within the last 3 months. Naturally, as scanners were released
before said viruses appeared, we would measure pure capability to
detect new viruses.
This is more scientific than the ISE test? Nonsense, Igor.
Using currently-known viruses to measure the performance of older AV
engines builds a huge assumption into the test: that viruses known
today, but unknown three months ago, are representative of new viruses
in general. But of course they aren’t. They’re representive of the new
viruses that AV labs and AV engines have learned how to detect in
those last three months.
Even if we’re charitable —- assuming retrospective tests aren’t
simply diffs of the results of different product revisions —- these
tests only sample viruses that AV vendors are bound to detect
anyways. Because if they can’t detect them, they can’t sample them!
Like Igor’s retrospectives, the ISE tests are also built on an assumption. ISE claims you can assess
performance in part by making small variations to
pre-existing viruses. These variant viruses are also a small subset of new
viruses in general. It just so happens that this subset
knocks McAfee into the middle of the pack.
You can make up your own mind about whether a virus born out of
modifications to an existing virus is a more serious threat than any
of the thousands of historical curiousities and QA test lab anomalies
that get replayed during a “retrospective” test. Personally, I look at
the genealogy of other forms of malware —- shellcode, bots, worms,
and exploit tools —- and I notice that the most malicious attackers tend not to write things from scratch, and I think the ISE guys can make a good case
for having designed the most relevant test in the industry.
What part of this test is most embarassing for McAfee?
That they didn’t come in first place?
That a test harness ISE created as a one-off consulting
project clearly outdid over a decade of R&D research by
mainstream AV vendors?
That tests like ISE’s will, over the long term, expose
antivirus products for the freely substitutable commodity
products that they are?
I assume that in 2006 AV purchasing decisions in large enterprises are
made from the “big 3”, and that the decision hinges on price, price,
price, and management offerings. Which over the short term bodes well
for McAfee and Symantec. But it’s cold comfort for the long term, when
the AV product lines that account for the overwhelming majority of
both companies revenue finally come under sustained assault by
Microsoft.
The blogs and trade press is full of sound and fury about ethics and
“objective testing”. I’ll do my best to hold in how little the “virus
ethics” argument signifies. And I’ll stop belaboring the obvious point
that a commoditized AV market will belong to Microsoft. Because what’s
really happening here might be much more annoying.
Is it possible that the AV researchers —- people with doctorates who
are published principally, if not exclusively, in venues like
“Proceedings of the International Virus Prevention Conference” —-
don’t want the new kids playing with their toys, or setting foot in
their sandbox? Is that why universally respected consultancies like
ISE* have to play by the perverse rules of “virus science”? It
wouldn’t be the first time: just look how the old-timer security
people handled eEye.
.* I get to be credible complimenting ISE because we compete with them.
36 Comments
Dino Dai Zovi | August 7th, 2006 | Filed Under: Malware
The slides I presented differed a bit from the printed ones. Get them here, now in black and with more diagrams.
3 Comments
Thomas Ptacek | August 4th, 2006 | Filed Under: Defenses, Disclosure, Industry Punditry, Malware, Matasano, New Findings, Uncategorized
Dave and I had some AV problems at the beginning of our talk that cost
us 20 minutes, threw us off our game a bit, and cost us a few slides.
I’ve posted the slides. And, uh, also wrote out the entire talk, slide
by slide, to go with it. It’s a blogtalk. A blalk! This is going to be revolutionary.
So, what you do is, you open a browser window and look at the slides.
Then you open another one and look at the talk.
And you read side-by-side. And it’s like you were actually there!
Except, the projector works, and the fonts in the slides are correct,
and I’m not talking at 500 words per minute, and you didn’t even have
to get up from your desk to experience it.
Let me know if you like it.
14 Comments
Dave G. | July 17th, 2006 | Filed Under: Defenses, Industry Punditry, Malware
I rarely find myself disagreeing with Greg Hoglund, but I think he needs to put down his Rootkit bible for a minute and consider his latest rootkit commentary.
Rootkits aren’t complicated, I’m sorry to say. The only thing that is complicated is the constant push-pull of the bi-polar security industry. If you want my opinion, my opinion is this: Let Symantec, Kaspersky, F-Secure, and all the others use rootkit technology, it only makes their anti virus products more effective. Let anti-spyware companies like Sunbelt use rootkits against rootkits. Use fire against fire.
Here are my issues:
Subterfuge. This doesn’t have to be fire against fire —- it can be fire against fireworks. Why bother to install a rootkit if one is already there to leverage? And since AV software will have to be aware of the fact that there is ‘Rootkit Enabled’ software on there, attackers can easily go undetected.
Confusion. When the software we trust behaves like the software we don’t trust, we increase the the likelihood that we won’t notice bad software.
Reliability. How many rootkits does one person want/need on their machine? If it’s ok for people to develop software that uses rootkit techniques to hide, it’s natural that multiple pieces of software will try to use similar techniques. We know this has incredibly bad consequences for end users. So I dont want 5 pieces of software mucking with my kernel. And while I might wax nostalgic about the good old days of DOS memory conflicts, or System 7 Extension conflicts, I am not actually looking to relive them. Of course, maybe the logical answer to this is a Rootkit Manager program that can help resolve rootkit gridlock. Greylock, Battery, you listening?
Arms Race. Ok, so this is true of all things security. But, when combined with the above issues, this quickly becomes a losing proposition.
I don’t agree w/ people who say such approaches take away an administrators capability to administer a box. To solve the administrator problem, you only have to do one thing: Treat your rootkit features as a black box and uninstall them with the rest of your product. If an administrator doesn’t want your product, then he can uninstall it. You aren’t taking anything away.
The administrator (or security analyst or forensics investigator) isn’t always given that choice. It is important that organizations understand the software installed on their machines. Especially when they have thousands of them.
Listen to this: THE KERNEL AND THE OPERATING SYSTEM ARE NOT SACRICINT - every product developer has the right to modify the system for the needs of his or her product. If you disagree, perhaps you are a kernel developer who has grown too comfortable with your religion. We aren’t slaves to the machine, even if the software we install enslaves the machine.
The right?! I think that’s a strong statement ;). Beyond that, it’s actually a dangerous attitude. The right to modify my operating system is granted to software by consumers. It can be taken away. Vendors should tell us what they are doing so we can make an informed decision as to whether or not we should buy their software.
The deeper applications go into the operating system, the greater the risk. We should be encouraging developers to not muck with the kernel any more than they absolutely have to. I am tired enough of having vulnerabilities that give attackers SYSTEM privileges, do we really need more ring0 vulnerabilities?
When the software we install hides, or installs rootkits for attackers “in advance”, we then become slaves to that software. Software that installs rootkits that modify the system in a way that is opaque to the administrator is a terrible idea. What happens when one of the many pieces of security software that is ending up on machines these days detects valid software as being a rootkit and quarantines it? Doesn’t that happen enough already?
6 Comments
Thomas Ptacek | June 27th, 2006 | Filed Under: Disclosure, Malware, Matasano, New Findings
There’s a quick piece on our work in Dark Reading:
Tom Ptacek, a researcher for Matasano, a security consulting firm,
says during the past few months he and his colleagues discovered
disturbing vulnerabilities in systems management software while
testing out their thesis that non-Internet applications are ripe for
attack. Ptacek wouldn’t name any specific management products that
fell prey to his firm’s staged attacks, but he says they included
major systems management vendors that handle things like patch
management. This represents a $2 billion to $3 billion market, he
says.
This is as good an opportunity as any to announce our three Black Hat
talks:
I’ll let Jeremy and Dino talk more about their respective
talks. Meanwhile, back to me and Dave’s.
Matasano has a thesis. It’s pretty straightforward: if your
application hasn’t been sitting in front of firewalls for the past 10
years, exposed to Internet attackers, it probably has not been
adequately tested. “It’s 1997 back there”.
Unsurprisingly, it’s looking like our (no-brainer) prediction is
panning out. We did SAN last year. Over the past several months, we’ve
taken an increasingly deep look at management apps. These are the
products that install tiny(-looking) bits of code on your servers
and desktops, and communicate with them from a central management
server. Yep. They have problems.
We’re not in a position to pre-announce vulnerabilities. We have lots
of them. But they follow a pattern:
Agent-Based Management Systems Create A Single Point Of
Failure, which is kind of their whole point. But the same
forces that allow an admin to verify the configurations of
1000 machines with a single button click also allow attackers
to, well, I’ll refer you back to Dino’s talk.
Agent-Based Management Systems Flip The Client/Server
Relationship, which is to say, in both the “agent” and the
“server”, both clientside and serverside attacks are relevant.
That’s because breaking any of the 1000+ agent deployments
on your network gives you a vantage point to talk to to the
management server, when it inevitably calls you up and asks
your status.
These issues, plus a general pattern of 1990s-era C programming in the
software itself, add up to the potential for mass-casualty
attacks. Some of the vulnerabilities we found are not only blind,
remote, serverside, and agent-facing, but also cross-platform, not
requiring customized shellcode to launch.
So, I guess what I’m saying is, you should care about this.
Are you running agent-based management apps? We’d love to talk more
to you about them. Dave and I are going to be spending some time in
July rounding out the menagerie of weirdness we’ve uncovered to date
with whatever new programs we can get our hands on.
No Comments
Thomas Ptacek | May 2nd, 2006 | Filed Under: Defenses, Industry Punditry, Malware
If I was half as good a writer as John Gruber, who just quit his day
job to work on Daring Fireball full-time, I’d be writing this blog
post from the perspective of an anthropomorphized Windows Internet
Connection Firewall (humorous incarnation: giggling teenage girl)
IM’ing the Mac OS X “Sharing” firewall (humorous incarnation: ironically
rearranged syslog output).
But I’m nowhere near as good as he is, and you should buy T-shirts from
Gruber to keep him writing, and all you should do to keep me writing is
buy consulting services from us. Meanwhile, I’m going to un-creatively
shred his most recent point-by-point polemic against an AP story about Mac
malware. In fact, I’m just going to ape his style, going point-by-point
right back at him. The only difference will be, my points will be correct.
Let’s get started:
Oh, and I love the way both the CNN and MSNBC subheads conflate the Mac
[…] with “Apple” […] “Good god, now they’re going after entire
companies”.
Yeah. That never happens to Microsoft. I mean, to look at CNN, you’d
think they had some kind of love affair with Windows security.
Instead, a window opened on the screen and strange commands ran as if the
machine was under the control of someone —- or something —- else. “Or
something”? —- could it be gremlins? Or worse, poltergeists? Spooky.
Computer programs aren’t people, John.
Who exactly is touting the Mac as “immune to such risks”?
Apple, on national TV, and Walt Mossberg.
In theory, malware could be written to target the Mac, but [in practice],
in the real world, they aren’t.
Except this time.
On the other hand, Macs do happen to be immune to Windows viruses
They are also invulnerable to Solaris remote code exec bugs and Commodore 64
diskette boot-block viruses. Why couldn’t the AP guy mention that?
And what does Oompa-Loompa do? It attempts to spread itself via iChat
and Bonjour, and [if you open the file it sends as an attachment] all it
will do is attempt to send itself to other local Macs on iChat.
Devastating and unstoppable.
All the Morris Worm (tagline: devastating and unstoppable) tried to do was spread itself, too. John Gruber is now claiming the incompetence of Mac malware developers as a unique defense for OS X.
Daine’s uninformed opinion [as a 29-year-old British (must be smart!)
chemical engineer] that macs were “invulnerable” to such attacks [etc, etc].
Perhaps someday I’ll have an opportunity [as a popular Mac blogger]
to make equally uninformed statements about chemical engineering
[or computer security] —- a subject about which I am utterly ignorant —-
in an Associated Press report.
Shit, I spent my snarky comments in the quotation.
That’s quite an interesting theory —- that the malware plaguing so
many millions of PC’s running Windows isn’t necessarily the result of
problems with Windows itself, but is rather the result of something
related to their Intel “microprocessors”.
That’s an interesting “straw man argument” —- that the point the AP
reporter was making was that it was “Intel” behind the Windows malware
problem, and not the enormous “market share” Microsoft had obtained,
making it an irresistable “target” for malware authors.
The actual point the AP was making was that adopting Intel made OS X
a more viable target for mainstream malware authors, presumably because
they didn’t need to learn another “instruction set” in order to write
their “viruses”. I happen “not to agree” with this point, and believe
that the PPC instruction set does “nothing to improve the security of OS X”,
but it is not a “crazy” point to make.
The bugs reported by Ferris are legitimate bugs, but to my eyes […],
they’re all just ways to make an application crash […] Ferris reports
that this one, regarding Safari, “causes the application to crash, and or
may allow for an attacker to execute arbitrary code”. Emphasis on the
may in “may allow”, apparently, because the only thing his examples do
is cause Safari to crash.
Advisory authors typically replace the word “may” with “will” when they
accompany the advisory with an exploit. Troll the last N Cisco IOS advisories
for similar weasel words. Then explain to me why a crashing bug in Safari
is less likely to allow remote code execution than a crashing bug in
Firefox or IE.
One of Ferris’s bugs is a NULL pointer dereference. We haven’t yet figured out
how to make a NULL pointer dereference transfer execution to our own code. I
apologize, we’re working on it. The other two flaws (tables with bizarre
cellspacing, framesets with invalid parameters), I have no idea whether
they do or don’t. Neither does John Gruber.
What I do know is, Safari does have remote code exec flaws, like every
other moderately complex piece of software. And that crashers are their
larval stage.
One can only hope that Apple will one day handle security issues as well
as Microsoft does now.
Which might happen if Apple can find a security engineer Microsoft isn’t
paying right now, and if Apple is given the benefit of being beaten upside
the head for 5 years by attackers and researchers to the exclusion of almost
any other target.
[quoting the AP copy] “Blasted” is such a great word. Much more exciting
than something more accurate, such as “sent as an attachment”.
Yeah. I hate that too. Just like this copy, from CNN: The Sasser worm
has raced around the world over the past week, exploiting a flaw in
Microsoft Corp.’s Windows operating system. “Raced” is much more
exciting than something more accurate, such as “made a remote
procedure call connection”.
You can tell [Rodney Thayer] is a genuine computer security expert because
he has long black hair and a beard.
You can tell John Gruber was so pissed off at this AP story that he didn’t
even take the time to Google a name before writing something that implied
that Rodney Thayer isn’t a security expert, or (equally inaccurate) that
John Gruber is qualified to make that assessment.
As a Mac user and a security person, the narrative about OS X vulnerability
drives me up a fucking wall.
There is a valid point to be made about the Mac’s susceptability to
Windows malware, because there is a huge population of malicious code
out there written to targets Windows users —- though just as the reason
the majority of all “good” programs don’t target OS X has nothing to
do with the operating system itself, not all “bad” programs rely on
architectural flaws in Windows either.
But that valid point has nothing whatsoever to do with the vulnerability
of modern Macs compared to that of modern Windows. Serious security people
do not believe that the Mac is inherently and qualitatively less vulnerable
than XPSP2; a single-user machine is a single-user machine whether you call
the superuser “root” or “Administrator”. And in 2006, as a result of being
targeted from every conceivable direction by attackers, Windows ships with
demonstrably more countermeasures than OS X.
I’m sorry that the truth doesn’t make for a pithy sound bite, but if you
bet your business on the security of Windows OR OS X, you’re playing to lose.
There is a 100% chance that both will see game-over vulnerabilities within
the next 18 months.
1 Comment
