|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
[ISN] Vulnerabilities in the Media -- who to trust?
From: InfoSec News (isn
c4i.org)
Date: Tue Apr 01 2003 - 03:47:24 CST
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
+------------------------------------------------------------------+
| Linux Security: Tips, Tricks, and Hackery |
| Published by Onsight, Inc. |
| |
| 01-April-2003 |
| http://www.hackinglinuxexposed.com/articles/20030401.html |
+------------------------------------------------------------------+
This issue sponsored by Building Linux VPNs
Building Linux Virtual Private Networks offers concise, step-by-step
instructions for building VPNs based on both standard protocols
(IPSec, SSL, SSH, PPTP) and popular Linux VPN solutions (VTun, cIPe,
tinc). Through numerous examples and proven practices, you will gain
important insights into choosing a VPN solution, installing and
configuring it, setting up routing, configuring firewalls, measuring
performance, and much more.
For more information, visit http://www.buildinglinuxvpns.net/
--------------------------------------------------------------------
Vulnerabilities in the Media -- who to trust?
By Brian Hatch
Summary: There are a variety of people and entities that publish
information about security problems. Who should you trust?
It seems that there are more sources of information about Security
problems every day. The hardest part about trying to keep up with it
all is to figure out who to trust. Let's take a recent example.
Back in mid February, 2003, scientists at a Swiss university were
able to exploit a weakness in an SSL implementation to allow them to
discover the password being repeatedly sent in many SSL-wrapped IMAP
sessions.
The Facts
* This only affected the OpenSSL implementation of SSL
* The vulnerability relied on a timing attack - the SSL server
would not perform all it's number crunching if it found that the
data had been tampered with. By tampering with the inbound data
in a careful manner, they were able to determine how 'valid' it
was by measuring the time it took for the server to complain.[1]
* Any malicious hacker, in order to perform this kind of attack,
would need to be able to rewrite packets as they were
transmitted, man-in-the-middle fashion. One could not sit
passively and listen to perform this attack.
* The data to be decoded needs to be in a predictable location, and
sent frequently enough[2] times that they can discover the
plaintext.
* Each time they try to attack an SSL session, the client and
server will notice the error. You'd not successfully get your
email while you were being attacked, and you'd probably stop
trying after a while, or ask the administrator to check things
out. by their
The Hype
Shortly after the announcement, every website with a readership of
three or more seemed to be saying that SSL had been broken -- the end
of the Internet was near -- all your passwords are belong to us. In
the huge noise some amazingly erroneous statements were made:
* "Hackers can read all your data now"
No, they can only try to manipulate your transmissions to decode
a particular section of it. This sensitive info needs to be in a
predictable place each time.
* "The attack only affects webmail"
No idea where they came up with this one - the attack was tried
out on IMAP over SSL. Webmail is usually straight HTTPS, and the
password may only be sent once, and cookies used thereafter.
Additionally, the sensitive data could move around for subsequent
connections making it impossible to be sure what to attempt to
decrypt.
* "SSL has been broken!"
No, just one particular SSL implementation - OpenSSL - had the
vulnerability, and it was fixed shortly thereafter.
* "The flaw is in SSL, not a particular implementation!"
No, didn't you just listen to me?
* "Old SSL sessions you've used can now be decrypted! Change your
passwords!"
No, the attacker needed to attack you at the time you were using
SSL. But you should change your password anyway -- "Linus" was
too easy to guess.
* "You'd never know you'd been hacked!"
No, any manipulation by the attacker destroys the SSL connection,
so you'd get obvious errors and know something was amiss.
* "It only affects (Outlook/Hotmail/Yahoo)"
The tests were done against Outlook, true, but any client
software that sends a password frequently in a predictable
location would have been vulnerable. Hotmail and Yahoo don't.
* "It only affects IMAP"
No, it could affect anything where a password or something else
'secret' is in a predictable place, for example if you're using
HTTP Basic authentication. The location will vary a lot more -
it's not nearly as defined as an IMAP connection which always
begins with login/password right up front.
The voices of authority All sorts of places reported and
sensationalized the problem. It was a mad rush to have the first
story.
Then came the experts.
The security geeks and cryptographers came out and tried to shed some
light on the actual cause and likely attack scenarios. They explained
what was actually broken, how it was being fixed, and how the "end of
the Internet" was going to need to wait for another day. Some sites
updated their articles to reflect this 'new' data. Others left the
articles untouched, while others removed them but posted no
retractions.
The analysis
With all the hubbub, rumours, and apocalyptic warnings, who are you
to believe when news about a new vulnerability comes to light? Here's
a very quick list:
* The folks to avoid:
+ Open Source Vendors
These guys clearly have something to hide, and should not be
trusted. The guys who develop OpenSSL keep everything about
their product under lock and key - in order to see the actual
source code, you need to use esoteric commands like gunzip or
tar. Some Open Source developers even use the GPL license,
which is equivalent to a virus according to a reputable and
impartial software development firm based in Redmond, WA. I
don't think you should trust Open Source vendors - far to
shifty, those folks are. You can never really know what
they're up to.
+ Scientists
These guys take the time to provide a well written
description of the problem, how they exploited it, and what
needs to be fixed. They are obviously not worth listening to.
They use drab, boring, unintelligible "science speak" not
because it's the most effective way of communicating without
colouring the data with emotion, but because they did not
have enough training in bad computer lingo. Had they spent
their time in college learning to write exclusively using
words and phrases like "cyberwarrior", "hack attack" and
"Internet superhighway", do you think they'd use the language
of mathematics and science? I think not. Somehow that drab
language is supposed to be sensationalistic and generate lots
of hype by average joes. I don't quite know how, but it's
some sort of plot.
+ Independent Experts
It is well known that independent security experts are merely
individuals that didn't have enough luck to land a
high-paying job at a big anti-virus or managed security
company, and will lie, cheat, and do anything they can to be
noticed in hopes that they can get one. Don't let that whole
"independent" part confuse you - they answer to somebody, by
not being an obvious lackey of a big security firm, you don't
know who it is! Experts? How can they be? Only megacorps can
have experts, it's a law or something. If you take out
"independent" and "expert" from "independent experts" what
are you left with anyway? Just the letter "s", and what good
is that?
* The folks to trust:
+ Online Media
These guys know that you can surf to any other site just as
easily as theirs. They know that you don't need to wait a
week to get a paper publication, you want your information
now. To assure technical accuracy of all their articles, they
keep a staff of at least seventy trained professionals from
each area that they may cover in their stories. Yep, those
"SSL is broken" articles went through some really strict
scrutiny by trained staff cryptologists before being
published far and wide moments after the original scientific
publication was announced. They also have a huge Artificial
Intelligence program that helps check sources in the off
hours when the editors are sleeping.
+ Slashdot Users
One of the requirements before you sign up for a Slashdot
account is that you show proof of expertise in certain areas,
and you are only allowed to post in those areas you are
qualified for. You must also have continuing educational
credits to maintain your right to post.
+ Al Gore
The only slashdot user who doesn't need to take the
continuing educational credits is Al Gore. He's been
grandfathered on slashdot, since he created the Internet. He
has exclusive right to the slashdot handle "Anonymous
Coward", and he posts very frequently.
+ George W. Bush
Come on, if Al Gore is on this list, and more than 50% of US
voters think Bush is smarter than Al, clearly GWB should be
trustworthy. And what's this "electoral college" thing I kept
hearing about in 2000?
+ Steve Gibson
Sure, he didn't pipe up about this vulnerability at all, but
he's the single voice that told us how awful raw sockets in
Windows XP are, and how the Internet would melt shortly after
it was released. And he independently created a new form of
SYN cookies to save us all from the frequent denial of
service attacks he seems to constantly be attacked with.
Sure, all that work by Bernstein and Schenk back in 1995 to
create SYN cookies was wasted. "SYN cookies"? Come on, that's
not marketable. But Gibson's "GENESIS" - now that has a ring
to it. Who cares if it doesn't work.
+ Columnists/Authors
Anyone who writes a column on April Fool's day is certainly
trustworthy - wouldn't you agree?[3]
Ok, all April Fool's kidding asside, here are some links that discuss
the OpenSSL bug that I talked about. It's been fixed for a while, and
the Linux distros have had new OpenSSL library packages available
since the end of February at the latest.
http://lasecwww.epfl.ch/memo_ssl.shtml
The actual writeup about the attack
http://www.openssl.org/news/secadv_20030219.txt
OpenSSL's advisory about the problem, announcing the fixed
versions.
http://news.bbc.co.uk/1/hi/technology/2785145.stm
The BBC's version of the story. They've edited it heavily to make
it more accurate than the first version.
http://slashdot.org/article.pl?sid=03/02/20/1956229
The Slashdot discussion about the vulnerability
http://www.cnn.com/....
I can't find the CNN page any more, but it was an absolute gold
mine for erroneous information.
http://zdnet.com.com/2100-1105-985460.html
ZDNet's "experts discredit e-mail security cracks" followup
article.
NOTES:
[1] The solution was to perform all the number crunching, even if the
data was invalid, and then send back an error, thus eliminating the
difference in timing results.
[2] They claimed to be able to decrypt an IMAP password by
interfering with the connection 160 times.
[3] Ok, so I had a little fun with the "who's trustworthy" part of
this article. But all the OpenSSL timing vulnerability stuff is
accurate, including the degree of erroneous information portrayed in
the media.
-------------
Brian Hatch has been developing Open Source Linux products since
1985, created the RedFishBlueFish block cipher used by default in SSL
4.0 servers, raises prize-winning alpacas in his back yard, and has
an annual bake off that raises over 500 million dollars to be donated
to needy Microsoft execs. Brian can be reached at
brian
hackinglinuxexposed.com.
--------------------------------------------------------------------
This newsletter is distributed by Onsight, Inc.
The list is managed with MailMan (http://www.list.org). You can
subscribe, unsubscribe, or change your password by visiting
http://lists.onsight.com/ or by sending email to
linux_security-request
lists.onsight.com.
Archives of this and previous newsletters are available at
http://www.hackinglinuxexposed.com/articles/
--------------------------------------------------------------------
Copyright 2003, Brian Hatch.
-
ISN is currently hosted by Attrition.org
To unsubscribe email majordomo
attrition.org with 'unsubscribe isn'
in the BODY of the mail.
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]