Archive for February, 2007
Thomas Ptacek | February 26th, 2007 | Filed Under: Defenses, Uncategorized
You probably didn’t notice, dazzled by Dark Reading high point “Top
Ten Admin Passwords To Avoid” (see footnote), but they just did a
quick feature on virtualization security, and this is something I
think you should pay more attention to.
If you’ve been living in a cave: real computers have been
obsoleted. In five years, everything is going to be
virtualized. Hardware is optimizing for it, hypervisor software is
ubiquitous, and it is simply a matter of time before virtualization
becomes a basic OS service on mainstream platforms.
I had two answers for how virtualization complicates life for systems
security people:
You now face the spectre of guest-hopping attacks, which
are vulnerabilities in your hypervisor that allow you to beat
VM protection and gain access to other hosts. The driver for
these attacks is that a hypervisor has to provide at least
the illusion of a “ring 0” for a guest operating system to
run in.
If you’re on the same hardware as your target, you have
significantly improved timing channels to pry encryption
secrets out with.
I have two thoughts on what this implies for security architecture:
I agree wholeheartedly with the product manager at VMWare who says
“… one of the key things about hypervisors is their design
is simpler than the modern operating system. As a result,
they are simpler to harden and lock down…”. With the
exception of device emulation, hypervisors have a smaller
attack surface than operating systems. Code-rewriting
Dynamo-style VM’s like VMWare also have a great degree of
control over their clients built into the architecture. So
guest-hopping doesn’t keep me up at night.
The answer to this problem is very familiar and very
straightforward: segmentation. If you’re a security person in
an enterprise, you have an opportunity now, before everything
shares the same 12-core, SAN-backed “aggregation server”, to
push out a policy that spells out what kinds of applications
can safely share the same hardware resources. Unlike the
VLAN debacle, you might actually have a chance at enforcing
this one, if you start early enough.
A couple other (predictable) comments:
I’d ignore “Hypervisor IPS”. There’s little evidence that
IPS has improved security at the OS or network level, and the
companies that produce those products uncover significant
vulnerabilities in the course of improving their products
every year. Right now there is zero evidence to suggest that
hypervisor IPS is anything but snake oil, and zero hypervisor
research findings to back the concept up.
I’d also ignore “hypervisor malware”; as we asserted earlier,
“ring -1” is actually kind of a crappy place to hide a
rootkit, because you’re a simpler target to look for when
you’ve interposed yourself between the entire OS and the hardware.
Footnote:
(For the record, they include: (username), (username)123, 123456, password,
1234, 12345, passwd, 123, test, 1, along with shockers like changeme, dontforget,
letmein, root, default, system, attack, cisco, tiger, public,
sun123. Damn, they got me! But don’t worry; all “root” gets you is the
raw data, which is easier to read on the web site anyways.)
20 Comments
Thomas Ptacek | February 26th, 2007 | Filed Under: Reversing, Uncategorized
Assume a black-box pen-test with a Win32 target that has perfect
debugger detection (disregarding how hard “perfect” is to
achieve). Arbitrarily, assume no access to the kernel; in fact, no
administrator privilege at all. We simply run in processes alongside
the target with the same credentials.
How much control do we have over the target?
We can get a Win32 handle to the process with OpenProcess.
We can read process memory by virtual offset and length with
ReadProcessMemory
We can enumerate the threads in the target with Toolhelp32
We can suspend or resume individual threads with OpenThread,
SuspendThread, and ResumeThread
We can write process memory by virtual offset and length with
WriteProcessMemory
We can allocate memory within the target with VirtualAlloc
We can change memory protection with VirtualProtectEx
We can enumerate modules and offsets within the target with
Toolhelp32.
We can map out memory regions with VirtualQueryEx.
We can excute code in the context of the process with
CreateRemoteThread (and RtlRemoteCall).
How much control would a debugger have given us?
We’d be able to suspend and resume threads, which we can do anyways.
We’d be able to read and write memory, which we can do anyways.
We’d be able to set breakpoints.
We’d be able to single-step the program.
We’d be able to read register contents.
We’d be able to call functions, which we can do anyways.
We’d be able to search memory for strings, which we can do anyways.
Without anything more interesting than the MSDN man pages, we come
reasonably close to this without invoking the debug interface. In
exchange for not showing up in NtQuerySystemInformation or mucking
with the UEF, we give up easy-to-use breakpoints, single-stepping, and
register access. But:
We can trivially get single-use, nonrecoverable breakpoints;
just inject INT 3 into the text with WriteProcessMemory.
We can potentially get access to registers using
NtSetThreadContext.
We can hook functions, in all the usual ways.
How close can we get to a fully-functional debugger without Windows
knowing about it? I’ve been playing with this for a couple weeks,
using Python and ctypes, turning IDLE into a debugger prompt. And it
seems like the answer is “extremely close”. More later, but if this is
totally obvious, pointers, links, and comments are welcome.
5 Comments
Dave G. | February 26th, 2007 | Filed Under: Disclosure
I read VC blogs. I am not ashamed of it. But I was a little weirded out when I was reading Feld Thoughts and saw a post titled “What’s Special About 2,147,483,649?”.
It actually links to a post about Newsgator’s Inbox product that had an integer overflow in their post id code. It seems the author is unaware of the security implications of integer handling problems.
Why am I telling you the gory details? One - you should know why you need to upgrade. Two - the problems of Y2K aren’t just about dates.
I graduated college in 2001, and though I was very well schooled in the problems of the Y2K bug, I always equated it to a problem with dates and not data in general… and as any developer will tell you, until you get really bitten by a bug like this its not something that’s front of mind.
Hopefully my experience will make other developers more aware!
Sadly, the experiences of every major vendor getting slammed by these bugs hasn’t made more developers aware.
No Comments
Dave G. | February 26th, 2007 | Filed Under: Slashdot Rounddown
Eric Allman wrote an article for the ACM Queue. For those of you that don’t know who Eric is, he is primary author of sendmail, so this is a topic he is well-versed in. He talks about the different approaches, which is pretty complete (from not fixing to announcing without patch), although he doesn’t give very good guidance about which ones to use.
The strongest criticism I have is in the timing section of the article. A choice quote on severity is:
A bug that gives an external user full control of a machine is more critical than one that allows the external user to break into the account of another user who opened an attachment (which that user shouldn’t have opened in the first place).
Another question that he brings up that affects how quickly someone should release a patch for is whether it was found internally or externally. Most (if not all) vendors will use this as the primary factor on whether or not to patch immediately or wait till the next release. It’s a simple gamble. It costs money to patch out of cycle, and most vendors are willing to bet their customer’s security that no one else will find the bug. Every major vendor is constantly rolling the dice on this. I would love to find statistics on patch times for internally discovered security issues (I assure you, you would be horrified).
One part of the article that I was a little surprised about was that he was pretty reasonable on how to work with security researchers. I certainly didn’t hear him call them vulnerability pimps or buckets of warm spit. In fact:
If the group is legitimate (i.e., one that isn’t trying to blackmail you), then you can usually negotiate, but only up to a point. Remember, even if you disagree with them, most of those groups are on the right side. Treat them with respect.
4 Comments
Thomas Ptacek | February 23rd, 2007 | Filed Under: Industry Punditry, Uncategorized
I’m just asking. Two weeks ago, Cisco “Security CTO” and ex-Wheel
Group exec Bob Gleichauf told Paul Roberts at NetworkWorld, regarding
their NAC endpoint plans:
CTA will be something that’s open source. That’s just logically
where it should end up […] We don’t want to be in the CTA
business, so we’re going to just open it up.”
(CTA is Cisco Trust Agent, a small endpoint agent that “certifies”
hosts for admission into a NAC regime in Cisco’s NAC scheme).
Now this week, we get:
“Cisco is not open-sourcing CTA,” said a Cisco spokesperson this
week. “Cisco is taking a different approach to being open via
standards” regarding NAC.
Note the wording; “a Cisco spokesperson”, not Gleichauf, directly
contradicting a major announcement made at RSA. What’s going on here?
Can I be conspiracy-theoretic for a bit? Who’s calling the shots over
there? The whole system’s out of order!
2 Comments
Dave G. | February 22nd, 2007 | Filed Under: Slashdot Rounddown
From the OC Register:
Police caught onto Kline after a Canadian computer whiz hacked into the judge’s Irvine home computer and discovered sexually explicit images of young boys and a diary that revealed Kline’s fantasies involving young boys. A subsequent search of his court computer revealed more images and more Web sites.
While this guy was clearly guilty and deserves to be arrested, I think it’s pretty crazy that the authorities will listen to someone who claims to have broken into someone’s computer, and gives them evidence. How can the possibly validate that this evidence is real? The computer is already known to be compromised by someone who is breaking the law.
BTW, this is what the computer whiz kid actually did:
“I was just playing around with this program I wrote. I wanted to see how it worked. Then I got way more curious about what these people were doing. It’s exciting to see something you build actually work. It means I have actually helped out. It challenges me and makes me work,” said Mr. Willman, now 21.
The program, disguised as an image, allowed him to retrieve anything — undetected — once downloaded. He posted the image on several usenet groups used by pedophiles. In reality, the downloaded image was simply one retrieved from the user’s own hard drive.
Some 3,000 users around the world downloaded the Trojan Horse program— giving him full control of targeted computers.
3 Comments
Dave G. | February 19th, 2007 | Filed Under: Uncategorized
Sorry for the last minute cancel, but the Pound and Pence doesnt appear to be open, I will get another date scheduled ASAP…
1 Comment
Dave G. | February 19th, 2007 | Filed Under: Uncategorized
For all you Boston security professionals out there, go to Beansec now! Ok, not now, but this Wednesday from 6-9PM at the Enormous Room in Cambridge.
BeanSec! is an informal meetup of information security professionals and academics in the Cambridge/Boston area. Unlike other meetings, you will not be expected to pay dues, “join up”, present a zero-day exploit, or defend your dissertation to attend.
[Map]
No Comments
Thomas Ptacek | February 14th, 2007 | Filed Under: Industry Punditry, Uncategorized
Context. Thousand-Dollar-Joel follows up; from Slashdot.
I’m sure that if they’re serious about actually showing that the
statistics are useful then we can find 10 random sites who are
willing to be ‘ethically hacked.’ […]
…But IDG doesn’t have any of those random sites. And neither does
“Opus One”, my IT Consultancy. Or any of my clients…
The astonishing thing is that most people who will read this press
release just don’t get it, and the depths of their not getting it
are even more astonishing…
… as you will see in just a few grafs…
I am challenging the conclusion, not the data. I believe that they
think that they have found vulnerabilities. I suspect they have
found a lot of lousy code. No surprise here. 70%, sure. I’ll bite
off on that number. I’m not arguing with that. […]
… at least, not anymore, now that I’ve been called on it…
But there is a huge difference between turning a vulnerability into
a breach. Let me give you an example. A lot of Cross-Site Scripting
attacks let you steal cookies. So they probably found those. But the
question is: when you have a cookie, what can you do with it? Can
you steal important data? Can you turn that cookie into a breach?
… I’m asking because I have no idea…
Good web sites that use them also tie cookies to your IP address,
which means that if you steal my cookie, you got nothing but crumbs.
… I’m saying this because I’ve never looked at a mainstream web
application, or noticed that when I plug my ThinkPad in to my home
network after coming home from work, many of my web app logins
magically continue to work, as if by magic, magically…
… also I think IP addresses count as authentication…
So the point is not that there are these vulnerabilities, but that
they have done nothing to show whether these vulnerabilities are
truly breachable and able to get an attacker real useful data.
… I, on the other hand, have. That I have not been sued is
testament to the fact that I wasn’t able to carry out these attacks.
Same for things like directory listing. You can do that to my web
site. Is that a security problem? No, in fact, I turned it on
specifically. If I didn’t want people to read it, I wouldn’t have
put it on the friggin’ web server.
… I use the word “same” here in the sense of, “not the same at
all”; directory listing vulnerabilities weren’t included in the
Acunetix number, which was 50% SQL Injection and 43% cross-site
scripting. I have also never found anything useful in a WEB-INF
directory.
Is a web site that’s susceptible to an SQL injection attack
hackable? Depends on where you get to inject the code […]
… on the planet where I come from…
I’m sure that someone who put their mind to it could take a web site
like, say, slashdot, and inject some SQL. Then they might be able to
… well, they could read all those posts that are on the web
site. Except they wouldn’t be nicely formatted, but real men write
HTML with vi anyway.
… yes, I really said this…
Maybe they could store or corrupt data with the injection, and maybe
they couldn’t.
… it would, of course, depend almost entirely on whether the attacker
could spell the word “UPDATE” or read the word “password”…
Maybe (and this is most likely) they could cause the script to blow
up. Is that “hacking” a web site? Hell, I get script explosion
errors from web sites WITHOUT hacking them.
Is being able to view a script a security vulnerability? it
depends. It depends on the web site. The script. The webmaster’s
intentions [, …]
… whether there were debugging methods hidden in the script,
whether passwords or authentication information were stored in the
script, whether the script took arguments that weren’t obvious from
the HTML source code or the request traffic, whether it relied on
vulnerable third-party components, whether I cared about my
intellectual property, and a whole host of other concerns I didn’t
think to write mostly because I only know these things in my
fictionalized portrayal on this blog…
So the point is not that they’ve found a lot of theoretical issues,
but whether they’ve actually found security issues. And the only
way, in my mind, to see whether they have is to see if the issues
can be exploited. If they can, I’ll pay up. If they can’t be
exploited, then all they’ve done is made long lists of things that
don’t matter from a security point of view […]
… and there is no set of circumstances in which I am paying these
people $1,000.
20 Comments
Thomas Ptacek | February 14th, 2007 | Filed Under: Industry Punditry, Uncategorized
Hysterical.
Second-tier web security scanner vendor Acunetix releases a survey,
concluding that 70% of all web applications are “hackable”. On the one
hand: surveys are the ultimate in lazy, content-free marketing; every
bored or boring marketing team does them, and none of them mean
anything. On the other hand, even a stopped clock, etc, etc: most
people in the trenches would say 70% is a lowball estimate.
But Paul McNamara, editor at IDG’s Network World, doesn’t think so. To
him, it sounds “apocalyptic”. So he forwards the survey to his “go-to
guy on all security matters”, Network World product reviewer Joel
Snyder. Snyder picks up the bat-phone, listens, and responds, “let’s
take their list of 3,200 sites, pick 10 at random, and see if they can
steal sensitive data from the sites”.
Snyder: “I’ll bet $1,000 they can’t steal personal data from
three of them.”
Let’s add some context, from the Acunetix press release, which
McNamara and Snyder have both read:
Since January 2006, Acunetix has been offering a free automated web
scan for qualifying websites. Out of a total of 10,000 applications,
Acunetix has scanned 3,200 sites belonging to either businesses or
non-commercial entities.
So, Acunetix has no formal, ongoing business relationship with these
sites. And Snyder and McNamara —- who is, again, an editor at IDG
publication Network World magazine, which you can contact at (508)
460-3333 —- think the best way Acunetix can “back up” this
superficial survey is for them to break in to a random selection of
10 of these companies. It’s such a sensible idea that Snyder will put
up $1,000 of his own money to see them do it.
But, don’t worry: McNamara is being careful with the “ground rules” of
this wager. They’ll need to work out the details with Acunetix,
because McNamara is biased. “But the basics would be that an employee
of the company would need to get valuable personal information - like
a credit card or social security number, not an e-mail or home address
- from at least three of a random 10 of those 3,200 sites they
tested.” Credit cards and social security numbers.
Acunetix responds:
We are willing to accept the challenge. However we feel that the
subject of the challenge should be the Network World Web site,
rather then - as Mr. Snyder suggested - an innocent third-party Web
site. After all, making a wager with someone else’s Web site would
be unfair, and furthermore illegal.
So we will accept the wager and perform a security audit on the
Network World site and attempt to breach any vulnerabilities
found. This should be a fair substitute, since we are assuming that
considering Mr. Snyder’s comments, Network World is confident that
its Web site is secure and any data it holds is unbreachable.
Oh, it’s on now. IDG is not a small company.
They gross over a billion dollars a year, comparable to the largest software vendors, larger by
contrast than any independent information security company, publicly
traded or otherwise. All their sites should be fair game. Their
publications include Computer World, CIO Magazine, CSO Magazine,
InfoWorld, PC World, and MacWorld. They have major operations in
Western Europe, Eastern Europe, South America, China, and Japan. Major
market research firm IDC belongs to IDG. I propose we take a random
sampling of 10 of those sites. I propose we get IDG management to back
up what their editors publish under IDG masthead, and allow Acunetix
to complete this “wager” against their own properties.
I think McNamara is going to have absolutely no problem finding
qualified third-party referees. And of course, for whatever it’s
worth, we volunteer.
4 Comments
