Security myths

Security myths.
http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx


I disagree with number one. That like telling people to throw out
Steve(grc.com) and others advice.

Look at myth number four. I strongly disagree with it. I think
tweaks are needed. Even Microsoft recommended some tweaks

Greg R

Matt
Tue Mar 15 22:07:52 CST 2005

My Take...

1) Splitting hairs. Following a security guide does not make it "Secure",
but it certainly makes it "more secure than it was before". That's like
saying "Since we can't fully secure it, let's just give everyone the
password anyway".

2) Security by obsecurity alone is no security at all, however, proper
security PLUS obsecurity can be nice. In other words, obsecurity on it's
own is of no use, but used as another layer of security is quite handy. For
example: Say there's a worm out there that exploits some mythical 0-day RDP
bug. If your RDP/TS server is running on port 3341, then that worm will
pass you by. Yes, someone else running nmap will find your RDP port in
seconds, but you didn't get that worm did you?

3) This one makes very little sense. Yes, there are a lot of tweaks out
there. Yes, some of them have a lot less "real world" security implications
than others, but that does not make them any less valid. I will agree that
implementing more tweaks does not in and of itself make for a more secure
system, but again, more than likely it was more secure than when you
started.

4) GAH! I don't even know where to start on this one. No where do they
ever define what a "tweak" is, but obviously it isn't "turning off services,
proper network segmentation...". I strongly disagree. Those ARE tweaks.
Those are things you do to make your network more secure.

All in all, I'm very dissapointed with Microsoft on this one. While the
authors mean well, they come off as being bitter and play the semantics game
every chance they get.

Excuse me while I go wash the FUD out of my mouth.

Matt Gibson - GSEC

"Greg R" <webworm12@yes.hotmail.com> wrote in message
news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
> Security myths.
> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>
>
> I disagree with number one. That like telling people to throw out
> Steve(grc.com) and others advice.
>
> Look at myth number four. I strongly disagree with it. I think
> tweaks are needed. Even Microsoft recommended some tweaks
>
> Greg R
>
>
>

S
Wed Mar 16 02:47:14 CST 2005

"Tweaks are necessary" is a good example of a myth. I'll give you an
example. In my life as a system administrator I have learnt a rule: use
defaults where possible. Once I was really surprised to see recommendation
to change TCP port of SQL Server from the default - as a part of security
guidance (myth #1) from a major IT services company that is also in
mainframe business. That is really stupid indeed, considering the fact that
clients and mnitoring tools also require change, support becomes more
complicated and gain in overall security is negligible as the risks are
mitigated by all other - valid - measures.

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-


"Greg R" <webworm12@yes.hotmail.com> wrote in message
news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
> Security myths.
> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>
>
> I disagree with number one. That like telling people to throw out
> Steve(grc.com) and others advice.
>
> Look at myth number four. I strongly disagree with it. I think
> tweaks are needed. Even Microsoft recommended some tweaks
>
> Greg R
>
>
>

Matt
Wed Mar 16 10:49:25 CST 2005

I disagree.

Yes, an increase in security usually results in a decrease in usability, but
with 0-day exploits becoming more and more common, changing common service
port will most often protect against a worm which has no other protecion.

While changing a port is security by obscurity, it's only flawed on its own.
Combined with proper security policies, obscurity is a wonderful tool. :)

Matt Gibson - GSEC

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:%234ITDTgKFHA.732@TK2MSFTNGP12.phx.gbl...
> "Tweaks are necessary" is a good example of a myth. I'll give you an
> example. In my life as a system administrator I have learnt a rule: use
> defaults where possible. Once I was really surprised to see recommendation
> to change TCP port of SQL Server from the default - as a part of security
> guidance (myth #1) from a major IT services company that is also in
> mainframe business. That is really stupid indeed, considering the fact
> that
> clients and mnitoring tools also require change, support becomes more
> complicated and gain in overall security is negligible as the risks are
> mitigated by all other - valid - measures.
>
> --
> Svyatoslav Pidgorny, MS MVP - Security, MCSE
> -= F1 is the key =-
>
>
> "Greg R" <webworm12@yes.hotmail.com> wrote in message
> news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
>> Security myths.
>> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>>
>>
>> I disagree with number one. That like telling people to throw out
>> Steve(grc.com) and others advice.
>>
>> Look at myth number four. I strongly disagree with it. I think
>> tweaks are needed. Even Microsoft recommended some tweaks
>>
>> Greg R
>>
>>
>>
>
>

Alun
Wed Mar 16 12:56:14 CST 2005

"Greg R" <webworm12@yes.hotmail.com> wrote in message
news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
> Security myths.
> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>
>
> I disagree with number one. That like telling people to throw out
> Steve(grc.com) and others advice.

It's nothing of the sort. It's saying that a guide is, at best, valid for
the risks that were present, and known to the author, at the time of
writing. [Personally, I wish you'd picked someone less controversial than
Steve Gibson to hold out as a shining example of security knowledge.] As a
result, a security guide can tell you how to protect against some attacks -
it is not a prescription for total security. You can't just apply the guide
without thinking, and believe yourself to be secure.

Worse, a guide may suggest applying settings that are counter-productive to
your business, which may be adequately secured against the threats addressed
in the guide through other mechanisms. Killing a line-of-business tool
because a guide says to disable some functionality is often a bad idea,
especially when that tool is already protected in some other fashion and
could safely be left running.

> Look at myth number four. I strongly disagree with it. I think
> tweaks are needed. Even Microsoft recommended some tweaks

Again, you're being a little too narrowly-focussed here. I think Steve and
Jesper are talking about parts of SD3+C - "Secure By Default, Secure By
Deployment, Secure By Design, and Communication". If you design your
network and your systems in a thoughtful way, there is no need to
significantly alter the default settings, or modify the system so that it's
no longer significantly the same operating system that we tested. Make only
those tweaks that are necessary - too many tweaks, and it's a sign that your
overall design may need a change to mitigate the attacks you're protecting
against.

I think that the article is not about saying that these myths _never_ have
any truth to them, it is saying that these myths are more frequently
overapplied than they are appropriately applied. That's pretty obvious,
when you look at each myth in turn:

* security guides offer information that you might not have had, and if you
consider them before applying their recommendations, you can pick those
measures that protect your systems while leaving the required operations
open. But they don't make your systems "secure", because you can only make a
system "more secure than it was".
* hiding functionality (by moving servers to different ports, renaming
accounts, etc) really doesn't do a whole lot to protect you. I write FTP
servers, and I've seen plenty of them get tried with _web_ exploits.
Clearly, moving a server to a different port and changing its banner is no
security.
* "the more tweaks the better" - also known as "these go up to eleven". The
more you tweak a system, the further you go from the default configuration,
and the more you head into territory that is unlikely to be usable or
fully-tested with your selected applications.
* "tweaks are necessary" - you may need to change a setting here or there,
but there has been a lot of work put in to make systems and software run
with security by default. You should check that you are not tweaking _away_
from the secure settings, and that you are applying tweaks because of a
threat model that needs to be addressed.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

S
Thu Mar 17 02:07:35 CST 2005

I haven't seen a worm based on a 0-day exploit for ages.

I have good security measures in place. NIDS wil alert about suspicious
traffic splashes that characterise worm activity. That makes both security
administator and system administrator in me comfortable.

regards

Slav

"Matt Gibson" <mattg@blueedgetech.ca> wrote in message
news:et7QdgkKFHA.3916@TK2MSFTNGP14.phx.gbl...
> I disagree.
>
> Yes, an increase in security usually results in a decrease in usability,
but
> with 0-day exploits becoming more and more common, changing common service
> port will most often protect against a worm which has no other protecion.

Matt
Thu Mar 17 02:56:29 CST 2005

Oh, I agree I haven't seen one yet...but if one's out there? *shudder*

Matt Gibson - GSEC

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:%2380okhsKFHA.1620@TK2MSFTNGP14.phx.gbl...
>I haven't seen a worm based on a 0-day exploit for ages.
>
> I have good security measures in place. NIDS wil alert about suspicious
> traffic splashes that characterise worm activity. That makes both security
> administator and system administrator in me comfortable.
>
> regards
>
> Slav
>
> "Matt Gibson" <mattg@blueedgetech.ca> wrote in message
> news:et7QdgkKFHA.3916@TK2MSFTNGP14.phx.gbl...
>> I disagree.
>>
>> Yes, an increase in security usually results in a decrease in usability,
> but
>> with 0-day exploits becoming more and more common, changing common
>> service
>> port will most often protect against a worm which has no other protecion.
>
>

S
Fri Mar 18 03:19:44 CST 2005

It's already 18 March around here - 17th finished without 0-day worms.
There's nothing out there. There never will be - I'm confident.

"Matt Gibson" <mattg@blueedgetech.ca> wrote in message
news:OtU038sKFHA.3132@TK2MSFTNGP12.phx.gbl...
> Oh, I agree I haven't seen one yet...but if one's out there? *shudder*
>
> Matt Gibson - GSEC
>
> "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
> news:%2380okhsKFHA.1620@TK2MSFTNGP14.phx.gbl...
> >I haven't seen a worm based on a 0-day exploit for ages.

Karl
Fri Mar 18 07:01:15 CST 2005

Don't forget about the Download.ject Trojan.

Also, while there was a patch for the Slammer worm that took down the
Internet for hours by attacking SQL and MSDE workstations, it wasn't a very
good patch installation program, and people didn't know that application X
installed MSDE on their workstations and that their workstations needed
patching.

While there may never be a zero-day worm, there are zero-day vulnerabilities
like NTDLL.DLL via WebDAV or the various IE vulnerabilities, and a
determined attacker can do an awful lot of damage to you, your employer who
pays your bills or your government's defenses. I don't really see the
existence or non-existence of a zero-day worm as being necessarily a
rebuttal to the topic of tweaks.


"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:%239O4ku5KFHA.3484@TK2MSFTNGP12.phx.gbl...
> It's already 18 March around here - 17th finished without 0-day worms.
> There's nothing out there. There never will be - I'm confident.
>
> "Matt Gibson" <mattg@blueedgetech.ca> wrote in message
> news:OtU038sKFHA.3132@TK2MSFTNGP12.phx.gbl...
> > Oh, I agree I haven't seen one yet...but if one's out there? *shudder*
> >
> > Matt Gibson - GSEC
> >
> > "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
> > news:%2380okhsKFHA.1620@TK2MSFTNGP14.phx.gbl...
> > >I haven't seen a worm based on a 0-day exploit for ages.
>
>

Karl
Fri Mar 18 06:53:16 CST 2005



"Greg R" <webworm12@yes.hotmail.com> wrote in message
news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
> Security myths.
> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>
> I disagree with number one. That like telling people to throw out
> Steve(grc.com) and others advice.

Steve Gibson isn't perfect. He does makes mistakes and gives bad advice in
places.

I think it is interesting that you mention Steve Gibson, because both Steve
and the article you linked above make statements that run counter to many
security experts and commonly recognized best practices. I think it is good
to counter the experts some of the time, if you're right and can defend your
decision, but if you do it too much and too often, you're probably in the
wrong.

> Look at myth number four. I strongly disagree with it. I think
> tweaks are needed. Even Microsoft recommended some tweaks

Tweaks have always been necessary in the past because MS software by default
has had insecure settings in the past. [Microsoft says this is because
that is what most customers wanted, and they do have a point.] The need for
tweaks may have changed now that their most modern software releases have
settings that are pretty secure by default. It is useful to note that they
successfully hardened a Windows box for a hacking contest using only four
registry changes, I think that is the point to take away here, that some
tweaks do nothing for security but waste your valuable time that could be
spent really securing things. On the other hand, making registry tweaks
takes relatively little time and is relatively harmless, and some of those
tweaks do have a small effect on security, so arguing too strongly against
tweaks could be making a mountain out of a molehill.

Alun
Fri Mar 18 09:16:51 CST 2005

The version of Windows that you are describing was Windows 2000 Server - and
Windows Server 2003 is even more secure out of the box (a similar design
today might have to 'tweak' by enabling features, rather than tweak security
settings on). More details on the OpenHack competition's Windows
configuration can be found at
http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

"Karl Levinson, mvp" <levinson_k@despammed.com> wrote in message
news:OKid9m7KFHA.484@TK2MSFTNGP15.phx.gbl...
>
>
> "Greg R" <webworm12@yes.hotmail.com> wrote in message
> news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
>> Security myths.
>> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>>
>> I disagree with number one. That like telling people to throw out
>> Steve(grc.com) and others advice.
>
> Steve Gibson isn't perfect. He does makes mistakes and gives bad advice
> in
> places.
>
> I think it is interesting that you mention Steve Gibson, because both
> Steve
> and the article you linked above make statements that run counter to many
> security experts and commonly recognized best practices. I think it is
> good
> to counter the experts some of the time, if you're right and can defend
> your
> decision, but if you do it too much and too often, you're probably in the
> wrong.
>
>> Look at myth number four. I strongly disagree with it. I think
>> tweaks are needed. Even Microsoft recommended some tweaks
>
> Tweaks have always been necessary in the past because MS software by
> default
> has had insecure settings in the past. [Microsoft says this is because
> that is what most customers wanted, and they do have a point.] The need
> for
> tweaks may have changed now that their most modern software releases have
> settings that are pretty secure by default. It is useful to note that
> they
> successfully hardened a Windows box for a hacking contest using only four
> registry changes, I think that is the point to take away here, that some
> tweaks do nothing for security but waste your valuable time that could be
> spent really securing things. On the other hand, making registry tweaks
> takes relatively little time and is relatively harmless, and some of those
> tweaks do have a small effect on security, so arguing too strongly against
> tweaks could be making a mountain out of a molehill.
>
>

Matt
Fri Mar 18 10:57:11 CST 2005

You might want to look up logical fallicies.

Just because something's never happened, doesn't mean it won't.

If you suscribe to bugtraq, you'll see the massive amount of vulns that are
being published. All it takes is one person finding one, and deciding not
to be nice about it.

Matt Gibson - GSEC

"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:%239O4ku5KFHA.3484@TK2MSFTNGP12.phx.gbl...
> It's already 18 March around here - 17th finished without 0-day worms.
> There's nothing out there. There never will be - I'm confident.
>
> "Matt Gibson" <mattg@blueedgetech.ca> wrote in message
> news:OtU038sKFHA.3132@TK2MSFTNGP12.phx.gbl...
>> Oh, I agree I haven't seen one yet...but if one's out there? *shudder*
>>
>> Matt Gibson - GSEC
>>
>> "S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
>> news:%2380okhsKFHA.1620@TK2MSFTNGP14.phx.gbl...
>> >I haven't seen a worm based on a 0-day exploit for ages.
>
>

S
Fri Mar 18 17:28:46 CST 2005

I'm not saying 0-day worms didn't happen - I just have feeling that it won't
happen (at least, on Windows platform) again. Even if one emerges, we have
means to have the worm detected - by behaviour - and contained.

And I'd much rather require certificate-based authentication to a service
port (which I'm often doing) than change the default port :)

regards

Slav

"Matt Gibson" <mattg@blueedgetech.ca> wrote in message
news:exrkIu9KFHA.3184@TK2MSFTNGP09.phx.gbl...

> Just because something's never happened, doesn't mean it won't.
>
> If you suscribe to bugtraq, you'll see the massive amount of vulns that
are
> being published. All it takes is one person finding one, and deciding not
> to be nice about it.

Matt
Sat Mar 19 00:18:18 CST 2005

I'm curious as to what you mean by "we have means to have the worm
detected...". Are you talking for youself, or for the community in general?

As for the whole certificate based thing, I highly agree. However, with the
recent MD5/SHA-1 collisions, I'm becoming leery of certificates in general.

Matt Gibson - GSEC


"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:etVgBJBLFHA.3500@TK2MSFTNGP14.phx.gbl...
> I'm not saying 0-day worms didn't happen - I just have feeling that it
> won't
> happen (at least, on Windows platform) again. Even if one emerges, we have
> means to have the worm detected - by behaviour - and contained.
>
> And I'd much rather require certificate-based authentication to a service
> port (which I'm often doing) than change the default port :)
>
> regards
>
> Slav
>
> "Matt Gibson" <mattg@blueedgetech.ca> wrote in message
> news:exrkIu9KFHA.3184@TK2MSFTNGP09.phx.gbl...
>
>> Just because something's never happened, doesn't mean it won't.
>>
>> If you suscribe to bugtraq, you'll see the massive amount of vulns that
> are
>> being published. All it takes is one person finding one, and deciding
>> not
>> to be nice about it.
>
>

S
Sat Mar 19 01:28:19 CST 2005

I'm a part of community in general. As long as worms try to connect to
arbitrary systems, they will cause suspicious traffic patterns and hit
firewalls - they will be detected by behaviour.

SHA-1 isn't too bad for now. I have yet to see a conterfeit certificate ;)

--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-

"Matt Gibson" <mattg@blueedgetech.ca> wrote in message
news:uEU8ztELFHA.3336@TK2MSFTNGP09.phx.gbl...
> I'm curious as to what you mean by "we have means to have the worm
> detected...". Are you talking for youself, or for the community in
general?
>
> As for the whole certificate based thing, I highly agree. However, with
the
> recent MD5/SHA-1 collisions, I'm becoming leery of certificates in
general.
>
> Matt Gibson - GSEC
>

Matt
Sat Mar 19 01:35:12 CST 2005

The problem is the speed of worms lately. Look at slammer/sapphire; took
over the net in under 30 minutes. If there's a malicious 0-day out there,
and it's written properly the first time, no one will be able to react fast
enough.

I'm waiting for the NSA to release their recommendation for the replacement
for the entire SHA family. The fact that there's a pair of identical (yet
different) certs out there scares the *@($ out of me.

Matt Gibson - GSEC


"S. Pidgorny <MVP>" <slavickp@yahoo.com> wrote in message
news:OVke$UFLFHA.2540@TK2MSFTNGP10.phx.gbl...
> I'm a part of community in general. As long as worms try to connect to
> arbitrary systems, they will cause suspicious traffic patterns and hit
> firewalls - they will be detected by behaviour.
>
> SHA-1 isn't too bad for now. I have yet to see a conterfeit certificate ;)
>
> --
> Svyatoslav Pidgorny, MS MVP - Security, MCSE
> -= F1 is the key =-
>
> "Matt Gibson" <mattg@blueedgetech.ca> wrote in message
> news:uEU8ztELFHA.3336@TK2MSFTNGP09.phx.gbl...
>> I'm curious as to what you mean by "we have means to have the worm
>> detected...". Are you talking for youself, or for the community in
> general?
>>
>> As for the whole certificate based thing, I highly agree. However, with
> the
>> recent MD5/SHA-1 collisions, I'm becoming leery of certificates in
> general.
>>
>> Matt Gibson - GSEC
>>
>
>

Paul
Sat Mar 19 02:06:44 CST 2005

In article <uz5GyYFLFHA.1948@TK2MSFTNGP14.phx.gbl>, in the
microsoft.public.security news group, Matt Gibson
<mattg@blueedgetech.ca> says...

> I'm waiting for the NSA to release their recommendation for the replacement
> for the entire SHA family. The fact that there's a pair of identical (yet
> different) certs out there scares the *@($ out of me.
>

There isn't a pair of identical (yet different) certs out there. To
state otherwise is simply contributing to the FUD surrounding the
collision issue involving MD5 and SHA-1. To make the leap from "we can
now produce SHA-! collisions more easily than was previously thought",
which is all the current research out of China shows, to "not only can
we produce collisions faster than we thought, we can take a certificate
and magically not only create a collision, but that that collision will
produce a valid certificate that can be used by a bad guy" is simply
ridiculous.
Hash collisions are nothing new. All hash algorithms by definition are
susceptible to collisions. Any operation that takes an infinite input
set and produces a finite output set is by definition open to
collisions. The potential you're worried about has always been a fact of
life when dealing with hashes, in theory. In practice, it just isn't
going to happen anytime soon.
Do we need to start looking at new hash algorithms? Absolutely. Do we
need them in place tomorrow? No, and to state otherwise is a joke.
There's a huge difference between cryptographically broken and broken in
such a way that a blackhat can take advantage of it.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

Matt
Sat Mar 19 02:53:32 CST 2005

Yes there ARE a pair of different certs with identical hashes.

http://eprint.iacr.org/2005/067

Matt Gibson - GSEC

"Paul Adare" <padare@newsguy.com> wrote in message
news:MPG.1ca5a7a29ba9677b989c20@msnews.microsoft.com...
> In article <uz5GyYFLFHA.1948@TK2MSFTNGP14.phx.gbl>, in the
> microsoft.public.security news group, Matt Gibson
> <mattg@blueedgetech.ca> says...
>
>> I'm waiting for the NSA to release their recommendation for the
>> replacement
>> for the entire SHA family. The fact that there's a pair of identical
>> (yet
>> different) certs out there scares the *@($ out of me.
>>
>
> There isn't a pair of identical (yet different) certs out there. To
> state otherwise is simply contributing to the FUD surrounding the
> collision issue involving MD5 and SHA-1. To make the leap from "we can
> now produce SHA-! collisions more easily than was previously thought",
> which is all the current research out of China shows, to "not only can
> we produce collisions faster than we thought, we can take a certificate
> and magically not only create a collision, but that that collision will
> produce a valid certificate that can be used by a bad guy" is simply
> ridiculous.
> Hash collisions are nothing new. All hash algorithms by definition are
> susceptible to collisions. Any operation that takes an infinite input
> set and produces a finite output set is by definition open to
> collisions. The potential you're worried about has always been a fact of
> life when dealing with hashes, in theory. In practice, it just isn't
> going to happen anytime soon.
> Do we need to start looking at new hash algorithms? Absolutely. Do we
> need them in place tomorrow? No, and to state otherwise is a joke.
> There's a huge difference between cryptographically broken and broken in
> such a way that a blackhat can take advantage of it.
>
> --
> Paul Adare
> "On two occasions, I have been asked [by members of Parliament],
> 'Pray, Mr. Babbage, if you put into the machine wrong figures,
> will the right answers come out?' I am not able to rightly apprehend
> the kind of confusion of ideas that could provoke such a question."
> -- Charles Babbage (1791-1871)

Paul
Sat Mar 19 03:03:47 CST 2005

In article <eH14jEGLFHA.3340@TK2MSFTNGP14.phx.gbl>, in the
microsoft.public.security news group, Matt Gibson
<mattg@blueedgetech.ca> says...

> Yes there ARE a pair of different certs with identical hashes.
>

"this does not constitute a realistic
vulnerability, as far as we know."

As I said, FUD.

--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

Karl
Sat Mar 19 07:01:44 CST 2005


"Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
news:esirNA9KFHA.2804@TK2MSFTNGP10.phx.gbl...
> The version of Windows that you are describing was Windows 2000 Server -
and
> Windows Server 2003 is even more secure out of the box (a similar design
> today might have to 'tweak' by enabling features, rather than tweak
security
> settings on). More details on the OpenHack competition's Windows
> configuration can be found at
> http://msdn.microsoft.com/library/en-us/dnnetsec/html/openhack.asp

Yes, I know, I had read that article, although more hacks would almost
certainly be necessary for a real live server that needs to remain secure
for years, not days, and isn't just serving up TCP port 80 with every other
port closed off.

The conclusion of the openhack article says several things that I strongly
agree with and that seem to somewhat counter the Riley / Jesper article on
less tweaks:

"Nor do these steps represent the full range of measures developers and
administrators should take in securing their own solutions...
Reduce the surface area exposed to attack by turning of all unnecessary
functionality.
Adhere to the principal of "least privilege." Never grant more privileges
than are absolutely necessary.
Anticipate failures and always practice "defense in depth," to minimize
their impact."

Earl
Sat Mar 19 10:16:31 CST 2005

We could've skipped all but the summary and got just as much out of it. The
article devotes itself to obsolete operating systems, settings, and
otherwise useless information and trivia (it would've been more illuminating
to see a discussion of black holes and such). One part I do agree on is not
making a bunch of useless "tweaks" to improve security. However, I don't see
how the article relates to GRC in any way.

"Greg R" <webworm12@yes.hotmail.com> wrote in message
news:7l9f31pf530msf4fkfl08k4moqj3lks86e@4ax.com...
> Security myths.
> http://www.microsoft.com/technet/community/columns/secmgmt/sm0305_2.mspx
>
>
> I disagree with number one. That like telling people to throw out
> Steve(grc.com) and others advice.
>
> Look at myth number four. I strongly disagree with it. I think
> tweaks are needed. Even Microsoft recommended some tweaks
>
> Greg R
>
>
>

Alun
Sat Mar 19 11:18:30 CST 2005

Note, too, that this is about creating two certificates with identical
information and signatures, but with different keys.

You can already create two certificates with identical information, but
different signatures and keys - you just have to get a CA to sign them.
That is not a problem - that there may be two certificates that say
"www.example.com" indicates only that one or two people created a
certificate request and convinced a CA to grant the certificate. Ideally,
of course, the public CAs are going to grant certificates only to those
people that can prove that they represent the www.example.com web site.

Creating two certificates by the method outlined in the linked paper
requires that the two certificates be created as part of a single process -
rather like creating entwined particles in quanum physics, one alone will do
you no good, you have to have a pair (or, presumably, a triplet, etc). You
cannot take an existing certificate and create one that matches it, with a
different key (which is what you would have to do to exploit this flaw).

If I were to come up with a flaw that exploits this work, I would create a
pair of colliding certificates while at a trusted position within the
example.com company, submit them for signing and keep one secret. I would
then depart the example.com company and use my second certificate on a faked
website that I then injected somehow between my victims and the real
www.example.com website.

But wait... I can already do that. I can already create two certificates,
get them signed, and keep one secret for my own later use - as long as the
CA will let me. I don't need colliding hashes to do that.

So, really, where is the attack possibility from this?

All that the work on SHA-1 to date has done is to follow the predictable
course of a hash function. Any hash function has a limited life-span, and
mathematical discoveries such as these are part of what limits that
lifespan. If hash functions expired solely due to Moore's law, we'd simply
add another bit to the hash function every eighteen months, and still use
the same function.

The really scary prospect with any of these hash functions is that someone
will come up with a startling observation, or a new branch of mathematics
that turns the number of operations required to break them from 2^N (where N
is a relatively big number - two or three digits) to just a few hundred - or
a few thousand. If that ever happens (and you can't predict whether it will
or not), things get very scary indeed. But even then, you have to create a
collision that is believable and matches the "hidden hash function" of "this
document has this structure". The more structure that is in the document
you sign, the harder it is to find a collision of the explicit hash and the
hidden hash (unless the hidden hash and the explicit hash accidentally
interfere to weaken each other - a structure, for example, that has a large
amount of space that you can fill with random data).

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

"Paul Adare" <padare@newsguy.com> wrote in message
news:MPG.1ca5b50361930c12989c21@msnews.microsoft.com...
> In article <eH14jEGLFHA.3340@TK2MSFTNGP14.phx.gbl>, in the
> microsoft.public.security news group, Matt Gibson
> <mattg@blueedgetech.ca> says...
>
>> Yes there ARE a pair of different certs with identical hashes.
>>
>
> "this does not constitute a realistic
> vulnerability, as far as we know."
>
> As I said, FUD.
>
> --
> Paul Adare
> "On two occasions, I have been asked [by members of Parliament],
> 'Pray, Mr. Babbage, if you put into the machine wrong figures,
> will the right answers come out?' I am not able to rightly apprehend
> the kind of confusion of ideas that could provoke such a question."
> -- Charles Babbage (1791-1871)

Matt
Sat Mar 19 11:24:25 CST 2005

I realize this isn't something we should be worried about right now, but
it's the beginning of the end for MD5 and SHA-1 (Perhaps even the whole SHA
family).

You're also backtracking. You first claimed that there were no certificate
collisions out there, I proved you wrong, and now you're brushing that off
because the authors of the collision don't see the real world implications
of it. Some other people do however.

http://lair.xent.com/pipermail/fork/Week-of-Mon-20050228/034048.html

Don't say that I'm wrong, then turn around and throw a straw man argument at
me. The fact of the matter is, there is a valid certificate collision out
there. Yes, in it's current form it's rather uninteresting, but it is
there.

Matt Gibson - GSEC

William
Sat Mar 19 13:40:46 CST 2005

Agreed. It would seem easier to spoof the DNS and create your own MITM cert
verifier service. Hand out your own certs and redirect any trust chain
requests to your own service. Naturally, this could only work with clients
within your own LAN.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
news:#e1YDgKLFHA.2648@TK2MSFTNGP14.phx.gbl...
> Note, too, that this is about creating two certificates with identical
> information and signatures, but with different keys.
>
> You can already create two certificates with identical information, but
> different signatures and keys - you just have to get a CA to sign them.
> That is not a problem - that there may be two certificates that say
> "www.example.com" indicates only that one or two people created a
> certificate request and convinced a CA to grant the certificate. Ideally,
> of course, the public CAs are going to grant certificates only to those
> people that can prove that they represent the www.example.com web site.
>
> Creating two certificates by the method outlined in the linked paper
> requires that the two certificates be created as part of a single
process -
> rather like creating entwined particles in quanum physics, one alone will
do
> you no good, you have to have a pair (or, presumably, a triplet, etc).
You
> cannot take an existing certificate and create one that matches it, with a
> different key (which is what you would have to do to exploit this flaw).
>
> If I were to come up with a flaw that exploits this work, I would create a
> pair of colliding certificates while at a trusted position within the
> example.com company, submit them for signing and keep one secret. I would
> then depart the example.com company and use my second certificate on a
faked
> website that I then injected somehow between my victims and the real
> www.example.com website.
>
> But wait... I can already do that. I can already create two certificates,
> get them signed, and keep one secret for my own later use - as long as the
> CA will let me. I don't need colliding hashes to do that.
>
> So, really, where is the attack possibility from this?
>
> All that the work on SHA-1 to date has done is to follow the predictable
> course of a hash function. Any hash function has a limited life-span, and
> mathematical discoveries such as these are part of what limits that
> lifespan. If hash functions expired solely due to Moore's law, we'd
simply
> add another bit to the hash function every eighteen months, and still use
> the same function.
>
> The really scary prospect with any of these hash functions is that someone
> will come up with a startling observation, or a new branch of mathematics
> that turns the number of operations required to break them from 2^N (where
N
> is a relatively big number - two or three digits) to just a few hundred -
or
> a few thousand. If that ever happens (and you can't predict whether it
will
> or not), things get very scary indeed. But even then, you have to create
a
> collision that is believable and matches the "hidden hash function" of
"this
> document has this structure". The more structure that is in the document
> you sign, the harder it is to find a collision of the explicit hash and
the
> hidden hash (unless the hidden hash and the explicit hash accidentally
> interfere to weaken each other - a structure, for example, that has a
large
> amount of space that you can fill with random data).
>
> Alun.
> ~~~~
> --
> Software Design Engineer, Internet Information Server (FTP)
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> "Paul Adare" <padare@newsguy.com> wrote in message
> news:MPG.1ca5b50361930c12989c21@msnews.microsoft.com...
> > In article <eH14jEGLFHA.3340@TK2MSFTNGP14.phx.gbl>, in the
> > microsoft.public.security news group, Matt Gibson
> > <mattg@blueedgetech.ca> says...
> >
> >> Yes there ARE a pair of different certs with identical hashes.
> >>
> >
> > "this does not constitute a realistic
> > vulnerability, as far as we know."
> >
> > As I said, FUD.
> >
> > --
> > Paul Adare
> > "On two occasions, I have been asked [by members of Parliament],
> > 'Pray, Mr. Babbage, if you put into the machine wrong figures,
> > will the right answers come out?' I am not able to rightly apprehend
> > the kind of confusion of ideas that could provoke such a question."
> > -- Charles Babbage (1791-1871)
>
>

Paul
Sat Mar 19 14:47:26 CST 2005

In article <Op4JBiKLFHA.3992@TK2MSFTNGP15.phx.gbl>, in the
microsoft.public.security news group, Matt Gibson
<mattg@blueedgetech.ca> says...

>
> You're also backtracking. You first claimed that there were no certificate
> collisions out there, I proved you wrong, and now you're brushing that off
> because the authors of the collision don't see the real world implications
> of it. Some other people do however.
>
> http://lair.xent.com/pipermail/fork/Week-of-Mon-20050228/034048.html

There still isn't an exploit, as I originally said, and even your own
references are proving that out. Also, both of these are based upon MD5
and not SHA.
>
> Don't say that I'm wrong, then turn around and throw a straw man argument at
> me. The fact of the matter is, there is a valid certificate collision out
> there. Yes, in it's current form it's rather uninteresting, but it is
> there.

You've done exactly the same thing. You're trying to prove that there is
some kind of exploit out there and both of your cites have done nothing
but prove the exact opposite.


--
Paul Adare
"On two occasions, I have been asked [by members of Parliament],
'Pray, Mr. Babbage, if you put into the machine wrong figures,
will the right answers come out?' I am not able to rightly apprehend
the kind of confusion of ideas that could provoke such a question."
-- Charles Babbage (1791-1871)

Alun
Mon Mar 21 10:31:09 CST 2005

...and this would only work if you could sign certificates as a trusted CA -
most users don't go around installing random CAs as Trusted, they stay with
the ones listed in the Windows installation, so even there, you'd have to
subvert a CA, or persuade the user to install a new CA certificate. CA
certificates should be locked up tighter than a drum, so subverting them
should be next to impossible.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

"William Stacey [MVP]" <staceywREMOVE@mvps.org> wrote in message
news:Ou8K1yLLFHA.1176@TK2MSFTNGP15.phx.gbl...
> Agreed. It would seem easier to spoof the DNS and create your own MITM
> cert
> verifier service. Hand out your own certs and redirect any trust chain
> requests to your own service. Naturally, this could only work with
> clients
> within your own LAN.
>
> --
> William Stacey, MVP
> http://mvp.support.microsoft.com
>
> "Alun Jones [MSFT]" <alunj@online.microsoft.com> wrote in message
> news:#e1YDgKLFHA.2648@TK2MSFTNGP14.phx.gbl...
>> Note, too, that this is about creating two certificates with identical
>> information and signatures, but with different keys.
>>
>> You can already create two certificates with identical information, but
>> different signatures and keys - you just have to get a CA to sign them.
>> That is not a problem - that there may be two certificates that say
>> "www.example.com" indicates only that one or two people created a
>> certificate request and convinced a CA to grant the certificate.
>> Ideally,
>> of course, the public CAs are going to grant certificates only to those
>> people that can prove that they represent the www.example.com web site.
>>
>> Creating two certificates by the method outlined in the linked paper
>> requires that the two certificates be created as part of a single
> process -
>> rather like creating entwined particles in quanum physics, one alone will
> do
>> you no good, you have to have a pair (or, presumably, a triplet, etc).
> You
>> cannot take an existing certificate and create one that matches it, with
>> a
>> different key (which is what you would have to do to exploit this flaw).
>>
>> If I were to come up with a flaw that exploits this work, I would create
>> a
>> pair of colliding certificates while at a trusted position within the
>> example.com company, submit them for signing and keep one secret. I
>> would
>> then depart the example.com company and use my second certificate on a
> faked
>> website that I then injected somehow between my victims and the real
>> www.example.com website.
>>
>> But wait... I can already do that. I can already create two
>> certificates,
>> get them signed, and keep one secret for my own later use - as long as
>> the
>> CA will let me. I don't need colliding hashes to do that.
>>
>> So, really, where is the attack possibility from this?
>>
>> All that the work on SHA-1 to date has done is to follow the predictable
>> course of a hash function. Any hash function has a limited life-span,
>> and
>> mathematical discoveries such as these are part of what limits that
>> lifespan. If hash functions expired solely due to Moore's law, we'd
> simply
>> add another bit to the hash function every eighteen months, and still use
>> the same function.
>>
>> The really scary prospect with any of these hash functions is that
>> someone
>> will come up with a startling observation, or a new branch of mathematics
>> that turns the number of operations required to break them from 2^N
>> (where
> N
>> is a relatively big number - two or three digits) to just a few hundred -
> or
>> a few thousand. If that ever happens (and you can't predict whether it
> will
>> or not), things get very scary indeed. But even then, you have to create
> a
>> collision that is believable and matches the "hidden hash function" of
> "this
>> document has this structure". The more structure that is in the document
>> you sign, the harder it is to find a collision of the explicit hash and
> the
>> hidden hash (unless the hidden hash and the explicit hash accidentally
>> interfere to weaken each other - a structure, for example, that has a
> large
>> amount of space that you can fill with random data).
>>
>> Alun.
>> ~~~~
>> --
>> Software Design Engineer, Internet Information Server (FTP)
>> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>>
>> "Paul Adare" <padare@newsguy.com> wrote in message
>> news:MPG.1ca5b50361930c12989c21@msnews.microsoft.com...
>> > In article <eH14jEGLFHA.3340@TK2MSFTNGP14.phx.gbl>, in the
>> > microsoft.public.security news group, Matt Gibson
>> > <mattg@blueedgetech.ca> says...
>> >
>> >> Yes there ARE a pair of different certs with identical hashes.
>> >>
>> >
>> > "this does not constitute a realistic
>> > vulnerability, as far as we know."
>> >
>> > As I said, FUD.
>> >
>> > --
>> > Paul Adare
>> > "On two occasions, I have been asked [by members of Parliament],
>> > 'Pray, Mr. Babbage, if you put into the machine wrong figures,
>> > will the right answers come out?' I am not able to rightly apprehend
>> > the kind of confusion of ideas that could provoke such a question."
>> > -- Charles Babbage (1791-1871)
>>
>>
>

Alun
Mon Mar 21 10:48:18 CST 2005

No, it's not the beginning of the end. The beginning of the end happened
right at the beginning - every time someone writes a faster implementation
of the hash algorithm, or finds a shortcut, the lifespan of the hash
function's output gets just a little bit shorter. The projected lifespan of
a hash function itself, on the other hand, is a rough guess of how long
it'll take before the data it protects becomes more valuable and long-lived
than the cost and time to crack the hash. Mathematical and processing
advances are taken into account in that guess, so while the lifespan may be
adjusted in minor ways, I don't see this as affecting the overall projected
lifespan of the hash function.

As for "backtracking", let's please keep the personal epithets out of this.
You've brought up some information that was new to Paul, and he's asserting
that, even so, it doesn't invalidate the thrust of his argument. As for
your link, do look out for people throwing around phrases like "the entire
digital signature trust model goes out the window". They're vague, and
explain nothing.

The best attack idea I've yet to come up with for this is that you could
sign something with certificate A, and then produce your bogus certificate
A' to allege "no, I didn't sign it". Sounds like non-repudiation is
suddenly lost, yes? No, because the person who verified your signature as a
necessary part of checking it has downloaded and stored a copy of your
signature A, which they then produce and say "ah, but you did sign it, the
only way to create these two certificates is to create them simultaneously,
therefore the owner of certificate A' must also be the owner of certificate
A - hence, you did sign it." So it's still not a good attack idea.

Only when it is possible (within cost and time constraints) to produce a
certificate that matches an existing certificate, without having to
concurrently create them, will you find that this model breaks down.

If I'm missing something obvious, you will let us know, right? In specific
detail, without the rhetoric, please? [Same goes for all participants in
this conversation - the emotive level here isn't really contributing to good
debate.] I like your end line - "The fact of the matter is, there is a
valid certificate collision out there. Yes, in it's current form it's
rather uninteresting, but it is there." It is interesting by its mere
presence, and it's another milestone on the road towards the eventual
expiration of these particular algorithms. It is uninteresting because it
does not completely void the usefulness of the algorithms for the problems
they are intended to address.

Alun.
~~~~
--
Software Design Engineer, Internet Information Server (FTP)
This posting is provided "AS IS" with no warranties, and confers no rights.

"Matt Gibson" <mattg@blueedgetech.ca> wrote in message
news:Op4JBiKLFHA.3992@TK2MSFTNGP15.phx.gbl...
>I realize this isn't something we should be worried about right now, but
>it's the beginning of the end for MD5 and SHA-1 (Perhaps even the whole SHA
>family).
>
> You're also backtracking. You first claimed that there were no
> certificate collisions out there, I proved you wrong, and now you're
> brushing that off because the authors of the collision don't see the real
> world implications of it. Some other people do however.
>
> http://lair.xent.com/pipermail/fork/Week-of-Mon-20050228/034048.html
>
> Don't say that I'm wrong, then turn around and throw a straw man argument
> at me. The fact of the matter is, there is a valid certificate collision
> out there. Yes, in it's current form it's rather uninteresting, but it is
> there.
>
> Matt Gibson - GSEC
>