Thomas Ptacek | May 30th, 2007 | Filed Under: Gatherings, Uncategorized
Courtesy of Rich Mogull and friends: SunSec, the Phoenix CitySec
meetup. It’s tomorrow, at 7PM, at Four Peaks in Tempe.
The usual endorsements and enticements apply: no membership required,
no RSVP needed, no dues, no minutes, no vendor presentations. Just
show up and get to know the locals in your field. Phoenix has lots of
security people; help them get to know each other by drinking beer
with them.
It’s a hardship, I know, but it’s time you gave something back, isn’t it?
4 Comments
Dave G. | May 25th, 2007 | Filed Under: Apple, Disclosure
Just wanted to quickly get my thoughts out on the latest OS X update. My rating system is sniff test based as well as how I evaluate risk for me. One day I will actually rate these things based on something more concrete. If you disagree with something or I got it wrong, just add a comment.
HIGH-RISK VULNS
iChat
CVE-ID: CVE-2007-2390
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: An attacker on the local network may be able to cause a denial of service or arbitrary code execution
Description: A buffer overflow vulnerability exists in the UPnP IGD (Internet Gateway Device Standardized Device Control Protocol) code used to create Port Mappings on home NAT gateways in iChat. By sending a maliciously crafted packet, an attacker on the local network can trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation when processing UPnP protocol packets in iChat.
mDNSResponder
CVE-ID: CVE-2007-2386
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: An attacker on the local network may be able to cause a denial of service or arbitrary code execution
Description: A buffer overflow vulnerability exists in the UPnP IGD (Internet Gateway Device Standardized Device Control Protocol) code used to create Port Mappings on home NAT gateways in the OS X mDNSResponder implementation. By sending a maliciously crafted packet, an attacker on the local network can trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation when processing UPnP protocol packets. This issue does not affect systems prior to Mac OS X v10.4. Credit to Michael Lynn of Juniper Networks for reporting this issue.
THIS IS THE REASON YOU NEED TO UPGRADE
Especially if you use a laptop and/or associate to non-friendly networks (e.g. Hotels, Coffeeshops, Anywhere within 50 miles of Dino Dai Zovi). These two bugs look related (probably some cut and paste action :)). My bet is Mike Lynn reported the bug after finding it during PWN2OWN, Apple did a quick check and found the bug in iChat as well.
CoreGraphics
CVE-ID: CVE-2007-0750
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Opening a maliciously crafted PDF file may lead to an unexpected application termination or arbitrary code execution
Description: An integer overflow vulnerability exists in the handling of PDF files. By enticing a user to open a maliciously crafted PDF file, an attacker could trigger the overflow which may lead to an unexpected application termination or arbitrary code execution. This update addresses the issue by performing additional validation of PDF files. This issue does not affect systems prior to Mac OS X v10.4.
This looks like a clientside remote. Go to a website and download a PDF and boom.
MEDIUM RISK VULNS
PPP
CVE-ID: CVE-2007-0752
Available for: Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A local user may obtain system privileges
Description: An implementation issue exists in the PPP daemon when loading plugins via the command line, which allows a local user to obtain system privileges. This update addresses the issue through validation of user privileges. This issue does not affect systems prior to Mac OS X v10.4. Credit to an anonymous researcher working with the iDefense VCP for reporting this issue.
VPN
CVE-ID: CVE-2007-0753
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A local user may obtain system privileges
Description: A format string vulnerability exists in vpnd. By running the vpnd command with maliciously crafted arguments, a local user can trigger the vulnerability which may lead to arbitrary code execution with system privileges. This update addresses the issue by performing additional validation of the arguments passed to vpnd. Credit to Chris Anley of NGSSoftware for reporting this issue.
Some solid local (user->root) privilege escalation attacks. Chris Anley is one of those security rockstars that more people should know about. Has one of the best talent to ego ratios in the industry!
LOW RISK VULNS
BIND
CVE-ID: CVE-2007-0493, CVE-2007-0494, CVE-2006-4095, CVE-2006-4096
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Multiple vulnerabilities in BIND, the most serious of which is remote denial of service
Description: BIND is updated to version 9.3.4. Further information is available via the ISC web site at http://www.isc.org/index.pl?/sw/bind/
Yeah… This isn’t going to keep me up at night, but interesting to note that some of these vulnerabilities date back to 01-31-2007 (according to ISC).
Alias Manager
CVE-ID: CVE-2007-0740
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Users may be misled into opening a substituted file
Description: In certain circumstances, an implementation issue in Alias Manager will not show identically-named files contained in identically-named mounted disk images. By enticing a user to mount two identically-named disk images, an attacker could mislead the user into opening a malicious program. This update addresses the issue by performing additional validation of mountpaths. Credit to Greg Bolsinga of Blurb, Inc. for reporting this issue.
crontabs
CVE-ID: CVE-2007-0751
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: The daily /tmp cleanup script may lead to a denial of service
Description: Filesystems mounted in the /tmp directory may be deleted when the daily cleanup script is executed, which may lead to a denial of service. This update addresses the issues by updating the daily cleanup script to prevent find commands from descending into mounted filesystems.
fetchmail
CVE-ID: CVE-2007-1558
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: fetchmail password disclosure may be possible
Description: fetchmail is updated to version 6.3.8 to address a cryptographic weakness that could lead to the disclosure of fetchmail passwords. Further information is available via the fetchmail web site at http://fetchmail.berlios.de/fetchmail-SA-2007-01.txt
file
CVE-ID: CVE-2007-1536
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Running the file command on a maliciously crafted file may lead to an unexpected application termination or arbitrary code execution
Description: A heap buffer overflow vulnerability exists in the file command line tool, which may lead to an unexpected application termination or arbitrary code execution. This update addresses by performing additional validation of files that are passed to the file command.
ruby
CVE-ID: CVE-2006-5467, CVE-2006-6303
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Denial of service vulnerabilities in the Ruby CGI library
Description: Multiple denial of service issues exist in the Ruby CGI library. By sending maliciously crafted HTTP requests to a web application using cgi.rb, an attacker could trigger an issue which may lead to a denial of service. This update addresses the issues by applying the Ruby patches.
screen
CVE-ID: CVE-2006-4573
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: Multiple denial of service vulnerabilities in GNU Screen
Description: The screen command line tool is updated to address multiple denial of service vulnerabilities. Further information is available via the GNU web site at http://lists.gnu.org/archive/html/screen-users/2006-10/msg00028.html
texinfo
CVE-ID: CVE-2005-3011
Available for: Mac OS X v10.3.9, Mac OS X Server v10.3.9, Mac OS X v10.4.9, Mac OS X Server v10.4.9
Impact: A vulnerability in texinfo may allow arbitrary files to be overwritten
Description: A file handling issue exists in texinfo, which may allow a local user to create or overwrite files with the privileges of the user running texinfo. This update addresses the issue through improved handling of temporary files.
A couple of not so interesting local vulns. Unlikely to impact more Mac users as they require you to either use tools not often used by most Mac users, and/or require a malicious file dropped on the filesystem that the victim will have to run said command against.
5 Comments
Dave G. | May 25th, 2007 | Filed Under: Gatherings, Matasano
Just wanted to let everyone know that Tom and I are going to be travelling to Washington DC for the Gartner IT Security Summit. Tom is on the Security Vulnerability Researcher Panel. We will be there on June 4th and 5th, so if anyone is interested in meeting up with us, please email me (daveg@).
Additionally, we will be in Boston from the 6th - 8th, so if you are in beantown, let me know as well.
1 Comment
Dave G. | May 25th, 2007 | Filed Under: Disclosure
I reported a vulnerability on a website developed by a popular Web 2.0 company. As it happens, we are a paying customer, so I really want them to take it seriously.
I will now post an anonymized version of the conversation:
Step #1: I send in a vulnerability report. I explain the vulnerability in a concise email and include repro steps.
They reply:
Thanks for the tip, David. It’s been noted.
I reply:
Can you give me some guidance on your response guidelines to
security vulnerabilities? Is there a timeframe that you try and
have vulnerabilities fixed by?
They reply:
Hi David,
We’re always looking for new ideas and fixes to roll out in future
updates but as as rule we don’t comment on possibilities or
timeframes.
I reply:
How will I know when this vulnerability is fixed?
They reply:
Actually, they don’t reply at all.
16 Comments
Thomas Ptacek | May 24th, 2007 | Filed Under: Defenses, Uncategorized
Fionnbharr Davies at Flying Spaghetti Hypervisor (an Australian
researcher working on virtualized malware) got to see Joanna Rutkowska
live at AusCERT, presenting her “beating DMA forensics devices by
reprogramming the AMD Northbridge” talk. He brought up our blog post!
Read his post. Long story short: Rutkowska acknowledges, if you
have DMA access to a running X86 machine, you can just hijack the
kernel to beat selective NoDMA ranges. No forensics device is
currently this “clever”, but when the market starts to care, the
devices will get there.
Davies is blogging his development of a VT-x hypervisor shim. Go read!
Good stuff!
4 Comments
Thomas Ptacek | May 23rd, 2007 | Filed Under: Uncategorized
Matt is collecting vulnerabilities in dictionary implementations for
Windows, Mac, and Linux for a Month of Dictionary Server Vulnerabilities,
exploiting the complexity of RFC2229 to make Internet
dictionary use “unsafe in any language”.
We wish him luck.
1 Comment
Thomas Ptacek | May 23rd, 2007 | Filed Under: Gatherings, Uncategorized
ChiSec 11 is tomorrow. This post is a shameless rehash. All the light
and heat behind ChiSec has moved, from our blog to CITYSEC.ORG, which
is where all the cool kids hang out now.
The details on the web page are up to date, and you can forward
that URL to your friends and neighbors. There’s a mailing list;
instructions are on the web page. If you join it, you won’t find out
about the next ChiSec any faster than our readers, but you will get a
say in when and where they’re held.
Some things to know about Chisec:
No vendors.
No 45-minute talks.
No RSVPs.
No membership.
No free drinks.
I expect between 20-30 people. You will find:
Operations people dealing with network security in the
trenches
Security product developers
Vulnerability researchers
Consultants and pen-testers
Management and policy guys
Some of them even have CISSPs, and yet I don’t
throw little temper tantrums about it. That’s how cool these meetings are. And all you
have to do to participate is show up.
No Comments
Dave G. | May 23rd, 2007 | Filed Under: Industry Punditry
According to The Washington Times, Chinese hackers are now breaking into Italian fashion houses. Why?
“Once upon a time, the Chinese came to the West to photograph the windows of shoe stores or fashion boutiques to copy the products. Today, instead, they steal projects directly from the servers of producing firms so that they can put counterfeit products on the market before they are distributed commercially,” it says.
Counterfeiting handbags is apparently big business.
Best part of the article:
“[Louis] Vuitton is already the most copied house in the world,” Miss Pisa said. “I would expect the French fashion houses in competition with our Italian companies likely will be targeted by the Chinese as well.
“Of course Italy needs to take steps to neutralize the hackers. But some of the companies have encouraged copying by charging as much 1,500 euros [$1,800] for a simple bag or a scarf. What is happening is not quite poetic justice but almost,” she said.
Luxury retailers of anything just aren’t sympathetic victims. Just ask Chicagoan’s that can’t eat Foie Gras. My big problem with making Foie Gras illegal is, of course, that now we will have underground foie gras restaurants and organized crime control of duck liiver.
4 Comments
Eric Monti | May 21st, 2007 | Filed Under: Bitching About Protocols, Reversing, Uncategorized
We just wrapped up a security assessment on a commercial enterprise server/agent security product. I can’t get too specific here, but we did run into an interesting problem that we thought would be worth a post.
The application we were evaluating had a home-grown network protocol doing some interesting things worth investigating. What we were seeing from our network capture wasn’t too far from this:
00 46414b45 02000000 06060601 5e000000 |FAKE............|
10 dab624ba da73fed5 b9872696 08ea97a5 |..$..s....&.....|
20 2d626160 60c86248 61c86748 65e000b2 |-ba``.bHa.gHe...|
30 bd80ac0c 863c0605 0617b098 3450cc99 |.....<......4P..|
40 c18a2186 21802191 a1042817 c3100294 |..!.!.!...(.....|
50 89610806 92b94015 310c6e0c 990c3940 |.a....@.1.n...9@|
60 961e4332 502c8f21 0dc84f67 0000 |..C2P,.!..Og..|
6e
Just by glancing at the first 16 bytes, you can spot (1) a message signature; (2) some 4-byte little-endian word values, one of which was obviously a length value for the payload; and (3) version number of 1.6.6.6 in the middle.
This looked promising so, we decided to pick it apart some more and see where it got us.
Let me just add at this point: General approaches can vary a lot when it comes to reverse engineering. As you’ll see, what we were doing was not strictly just protocol reversing. We had access to server-side binaries, which we were simultaneously disassembling to guide us at several steps. We could have just gone the strict disassembly route, but in my experience combining the two tends to yield much quicker results.
So, away we went. Or rather, got stuck next. Just past the header of the protocol was a chunk of seemingly meaningless binary data. A bit of disassembling told us that it was something compressed with .NET’s DeflateStream. Here was the real payload and it was time to write our first bit of code.
Since we were working with BlackBag (as regular readers will have noticed — Matasano tends to do) our ideal tools would be small focused ones that could run on Unix. Preferably in the middle of a list of several piped commands so we could say things like:
% cat | _inflate_ | hexdump -C
And if things got interesting, maybe even:
% cat | _inflate_ | bkb sub | _deflate_ | bkb blit
We figured, we should be able to get the “Inflated” stream using Zlib. So, we set out to put together some Ruby to take a “deflated” standard input and dump “inflated” standard output.
#!/usr/bin/env ruby
require 'zlib'
buf = STDIN.read()
zs = Zlib::Inflate.new
out = zs.inflate buf
STDOUT.write(out)
And… Fire!
% cat msg.raw |bkb shf 16 | inflate.rb|hd
./inflate.rb:7:in `inflate': incorrect header check (Zlib::DataError)
from ./inflate.rb:7
Woops… maybe not so simple. We asked the Google! Turned out .NET’s DeflateStream doesn’t use the usual ZLIB header and footer as defined in RFC 1950.
Side note: Obviously this had already been tackled. Even though we didn’t try the IronPython solution linked above, I’d probably recommend using it or something like it unless you need something really quick and dirty as we did. The obvious question, is why didn’t we? We were sticking with ruby for other reasons on this session and didn’t really need a “robust” solution just yet.
So we actually read RFC 1950 at this point. Turned out we just needed to tack on the header (and maybe the footer) ourselves.
#!/usr/bin/env ruby
require 'zlib'
header = "x78x01"
buf = STDIN.read()
zs = Zlib::Inflate.new
# Add the header first
zs << header
out = zs.inflate buf
STDOUT.write(out)
Um.. Fire?
$ cat msg.raw |bkb shf 16 |./inflate.rb |hd
00 b6a45b7b 499fd59d c2917411 2f7666a2 |..[{I.....t./vf.|
10 04000000 6a006400 6f006500 08000000 |....j.d.o.e.....|
20 4a006f00 68006e00 20004400 6f006500 |J.o.h.n. .D.o.e.|
30 1b000000 43003a00 5c005000 61007400 |....C.:..P.a.t.|
40 68005c00 54006f00 5c005300 6f006d00 |h..T.o..S.o.m.|
50 65005c00 46006900 6c006500 2e006300 |e..F.i.l.e...c.|
60 6f006e00 66006900 6700 |o.n.f.i.g.|
6a
Much better.
Those who’ve read the RFC or are already familiar with ZLib may notice we didn’t bother with the ADLER32 checksum footer. Our quick/dirty Ruby ZLib implementation didn’t seem to notice when it was missing. Honestly not sure whether this is expected behavior or not, but it suited us just fine. We really just wanted to get back to picking apart the protocol.
What was “inflated” might also need to get “deflated” again, so we also whipped up a “deflater”.
#!/usr/bin/env ruby
require 'zlib'
buf = STDIN.read()
zs = Zlib::Deflate.new()
out = zs.deflate(buf,Zlib::SYNC_FLUSH)
# Output the deflated chunk without the 2b zlib header and 4b adler32 footer
STDOUT.write(dst[2,(dst.length - 6)])
Turned out we didn’t need to use the “deflate” script much: between protocol decoding and disassembly, we learned one of the original uncompressed 4-bytes in the protocol’s header was for payload *type*, either *deflated* or *raw*. So, even though we confirmed our deflater worked well enough, we usually just changed the type to *raw* whenever we wanted to send something back to the server.
And in conclusion (which I have to speak in vague terms about to protect the guilty - sorry). Now that we could read and compose messages, we learned this protocol was letting the agent do some truly crazy things. Things like, passing entire lists of fields to insert/update directly into SQL. Without authentication.
Identifying and decompressing the protocol’s payload was the only hurdle we had to get over to proceed with other attacks. In the end, these culminated in several findings, including trivial database corruption and even injecting malicious data to capture admin privileges through the product’s console. Again… without authentication.
Moral of the story:
I try to not to speculate too much about what developers’ intentions are or were when I find something like this. Hindsight is 20/20 and it’s generally a lot easier to break than build. But, I couldn’t help but wonder whether they had intended to use DeflateStream as a cheap form of obfuscation here. It’s just as possible they just wanted to keep the payloads small and didn’t even consider the risks faced by the protocol at all.
Zlib is not encryption (I feel dumb even saying it). Even more so if your protocol is wide open. Authentication would have been tricky no matter what. There were inherent trust boundaries invading way into the agent. That was even more reason for this protocol to use encryption. Though frankly it wouldn’t have solved all this protocol’s problems — crypto is not an argent projectile. There were some deeper design issues lurking here.
But at the very least, it would have raised the bar for reversing. Because the ZLib “hurdle” took us all of about 20 minutes to beat.
24 Comments
Thomas Ptacek | May 21st, 2007 | Filed Under: Uncategorized
Readers, meet Eric. Eric, meet readers. Eric brings Matasano Chicago to 3, necessitating our — uh — “swank” new office space on Randolph. You’ll learn more about Eric later.
‘Cuz I’m a turn it in and I’m a turn it out… But now I’ve got to pass the mic to:
No Comments
