Re: [Full-disclosure] PayPal.com XSS Vulnerability

[Dan Kaminsky]

Heya Robert,

   So there's this pile of law around the world around work and kids; it's
a rather recent development that <18 year olds can find problems that
multibillion dollar interests are willing to pay bounties for.   The laws
are all trying to protect you from being made to pick berries or sew
t-shirts instead of going to class and playing outside.

   Law may be code, but it compiles VERY slowly.

   In general, you can talk to people and things'll work out.  Lawyerspeak
may look daunting, but seriously, send some friendly emails, there's real
people on the other side of those security@ addresses and they can usually
figure out some way around pesky things like birthdays.

--Dan



On Fri, May 24, 2013 at 9:38 AM, Robert Kugler wrote:

> Hello all!
>
> I'm Robert Kugler a 17 years old German student who's interested in
> securing computer systems.
>
> I would like to warn you that PayPal.com is vulnerable to a Cross-Site
> Scripting vulnerability!
> PayPal Inc. is running a bug bounty program for professional security
> researchers.
>
> https://www.paypal.com/us/webapps/mpp/security/reporting-security-issues
>
> XSS vulnerabilities are in scope. So I tried to take part and sent my find
> to PayPal Site Security.
>
> The vulnerability is located in the search function and can be triggered
> with the following javascript code:
>
>
> ';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";
>
> alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--
> >">'>alert(String.fromCharCode(88,83,83))
>
> https://www.paypal.com/de/cgi-bin/searchscr?cmd=_sitewide-search
>
> Screenshot: http://picturepush.com/public/13144090
>
> Unfortunately PayPal disqualified me from receiving any bounty payment
> because of being 17 years old...
>
> PayPal Site Security:
>
> "To be eligible for the Bug Bounty Program, you *must not*:
> ... Be less than 18 years of age.If PayPal discovers that a researcher
> does not meet any of the criteria above, PayPal will remove that researcher
> from the Bug Bounty Program and disqualify them from receiving any bounty
> payments."
>
> I don’t want to allege PayPal a kind of bug bounty cost saving, but it’s
> not the best idea when you're interested in motivated security
> researchers...
>
> Best regards,
>
> Robert Kugler
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Using CSS :visited to steal your history (again, zzzz...)

[Dan Kaminsky]

...you are a magnificent bastard.


On Sun, May 5, 2013 at 5:43 PM, Michal Zalewski  wrote:

> I guess this may be somewhat amusing...
>
> As you probably know, most browser vendors have fixed the ability to
> enumerate your browsing history through the CSS :visited
> pseudo-selector. The fix severely constraints the styling possible for
> visited links, and hides it from APIs such as
> window.getComputedStyle() [1].
>
> The fix does not prevent attackers from extracting similar information
> through cache timing [2], or by examining onerror / onload events for
> scripts and images loaded from sites to which you may be logged in.
> Nevertheless, the :visited attack is particularly versatile and
> reliable, so several people have tried to circumvent the fix by
> showing the user a set of hyperlinked snippets of text that, depending
> on the browsing history, will blend with the background or remain
> visible on the screen. Their visibility can be then indirectly
> measured by seeing how the user interacts with the page.
>
> The problem with these attacks is that they are either unrealistic, or
> extremely low-throughput. So, here is a slightly more interesting
> entry for this contest. The PoC works in Chrome and Firefox, but
> should be easily portable to other browsers:
>
> http://lcamtuf.coredump.cx/yahh/
>
> The basic idea behind this inferior clone of Asteroids is that we hurl
> a lot of link-based "asteroids" toward your spaceship, but you only
> see (and take down) the ones that correspond to the sites you have
> visited. There are several tricks to maintain immersion, including
> some proportion of "real" asteroids that the application is sure are
> visible to you. The approach is easily scalable to hundreds or
> thousands of URLs that can be tested very quickly, as discussed here:
>
>
> http://lcamtuf.blogspot.com/2013/05/some-harmless-old-fashioned-fun-with-css.html
>
> Captain Obvious signing off,
> /mz
>
> [1] https://developer.mozilla.org/en-US/docs/CSS/:visited
> [2]
> http://lcamtuf.blogspot.com/2011/12/css-visited-may-be-bit-overrated.html
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OT Google raises sploit bounties

[Dan Kaminsky]

On Wed, Nov 28, 2012 at 6:23 AM, Georgi Guninski wrote:

> On Tue, Nov 27, 2012 at 10:32:16PM -0800, Dan Kaminsky wrote:
> > > One Google employee responds to another Google employee about Google
> > > stuff...
> > >
> >
> > It's almost like security people at Google have been security people for
> a
> > very long time, and are given a redonkulously long leash ;)
> >
> > --Dan
>
> I would be interested what bounties they would pay
> for operation Аврора or for a botnet of say 1M host.
>
> microsoft are paying ridiculously low for botnets :)
>
>
>
Attackers get a higher ROI than defenders.  Same as it ever was.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OT Google raises sploit bounties

[Dan Kaminsky]

> One Google employee responds to another Google employee about Google
> stuff...
>

It's almost like security people at Google have been security people for a
very long time, and are given a redonkulously long leash ;)

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

On Mon, Aug 20, 2012 at 9:29 AM, Paul Schmehl wrote:

> --On August 20, 2012 8:32:59 AM -0700 Dan Kaminsky 
> wrote:
>
>
>>
>>
>> On Mon, Aug 20, 2012 at 8:29 AM, Paul Schmehl 
>> wrote:
>>
>>
>> --On August 20, 2012 2:22:28 AM -0700 Dan Kaminsky 
>> wrote:
>>
>>
>> May I ask what FreeBSD's entropy sources are?
>>
>>
>> I'm surprised you don't already know.  From device noise.
>>
>>
>>
>>
>> Which class?  There are many sorts of said noise (most of which I
>> believe actually work).
>>
>>
> The long answer is look at /usr/src/sys/sys/random.h.
>
> The short answer is:
> /* Allow the sysadmin to select the broad category of
> * entropy types to harvest
> */
> struct harvest_select {
> int ethernet;
> int point_to_point;
> int interrupt;
> int swi;
> };
>
> swi is software interrupt handlers.  interrupt is hardware interrupts
> (e.g. usb, pci, etc.)
>

Neat.  What's the default, and what does it mine?  Count?  Nanosecond time?


>
> *If* you install a hardware PRNG, FreeBSD will use that instead (by
> default).


Excellent.

>
>
> --
> Paul Schmehl, Senior Infosec Analyst
> As if it wasn't already obvious, my opinions
> are my own and not those of my employer.
> *
> "It is as useless to argue with those who have
> renounced the use of reason as to administer
> medication to the dead." Thomas Jefferson
> "There are some ideas so wrong that only a very
> intelligent person could believe in them." George Orwell
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

On Mon, Aug 20, 2012 at 8:29 AM, Paul Schmehl wrote:

> --On August 20, 2012 2:22:28 AM -0700 Dan Kaminsky 
> wrote:
>
>>
>> May I ask what FreeBSD's entropy sources are?
>>
>
> I'm surprised you don't already know.  From device noise.


Which class?  There are many sorts of said noise (most of which I believe
actually work).
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

>
> > My assumption is that the other Unixes weren't looking at interrupt
> timing
> > to begin with, i.e. they've always been as starved for entropy as Linux
> > eventually became.
>
> Well, you know what they say about assumptions.
>

Smart people will come around and help correct them?  :)


>
> >  That being said, does VXWorks even *have* an OS provided
> > strong random number generator?
>
> Don't know, don't care.
>

Why not?  It carries your data.


>
> > Windows has CryptGenRandom, which AFAIK doesn't block, and survives
> > everything but VM suspend/restore.
>
> FreeBSD also doesn't block.
>

May I ask what FreeBSD's entropy sources are?
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

On Sun, Aug 19, 2012 at 3:03 PM, Ben Laurie  wrote:

> On Sun, Aug 19, 2012 at 9:28 PM, Dan Kaminsky  wrote:
> >
> > On Sun, Aug 19, 2012 at 10:13 AM, Ben Laurie  wrote:
> >>
> >> On Sun, Aug 19, 2012 at 5:42 PM, Dan Kaminsky  wrote:
> >> > entropy gathering has gotten *worse* (via abandonment of interrupts),
> >> > not
> >> > better.
> >>
> >> Entropy gathering in _one particular OS_. Credit where its due, please.
> >
> >
> > My understanding is that bad keys were detected on more than just Linux,
> > which implies starvation on everything on everything not out of Redmond.
> >
> > What interesting approaches are you aware of that deserve credit?  Not a
> > rhetorical question, I'm genuinely curious.
>
> I was referring to the abandonment of interrupts in Linux. You think
> that other OSes have got worse at entropy gathering? And when did
> "more than Linux" start implying "not Windows"?
>

My assumption is that the other Unixes weren't looking at interrupt timing
to begin with, i.e. they've always been as starved for entropy as Linux
eventually became.  That being said, does VXWorks even *have* an OS
provided strong random number generator?

Windows has CryptGenRandom, which AFAIK doesn't block, and survives
everything but VM suspend/restore.

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

On Sun, Aug 19, 2012 at 10:13 AM, Ben Laurie  wrote:

> On Sun, Aug 19, 2012 at 5:42 PM, Dan Kaminsky  wrote:
> > entropy gathering has gotten *worse* (via abandonment of interrupts), not
> > better.
>
> Entropy gathering in _one particular OS_. Credit where its due, please.
>

My understanding is that bad keys were detected on more than just Linux,
which implies starvation on everything on everything not out of Redmond.

What interesting approaches are you aware of that deserve credit?  Not a
rhetorical question, I'm genuinely curious.

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DakaRand

[Dan Kaminsky]

>
> Lots of people are using "haveged" already, it operates on a similar
> principle.
>
> http://www.issihosts.com/haveged/
>
> Ciao, Marcus
>

Oh yes, there's been code floating around for years that uses timing drift
-- but it's never anything that, say, gets integrated into kernels or
distros or even embedded frameworks.  Compared to the number of nodes out
there, it's certainly not "lots" of people using haveged.  There's just
been a lot of fear and nervousness around clock drift approaches, and
indeed, entropy gathering has gotten *worse* (via abandonment of
interrupts), not better.

Hopefully we can finally put all that -- not to bed -- but to the test.
 Lets find out if clock drift works after all.

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] how i stopped worrying and loved the backdoor

[Dan Kaminsky]

Yeah, turns out RNG's *aren't* on most motherboards.  Thus, DakaRand.

The biggest surprise of this entire adventure is that DakaRand seems to
work inside of VM's too.  Didn't expect that at all.  But then, I think
it's going to take some time to analyze what's going on here.

On Sat, Aug 18, 2012 at 4:00 PM, coderman  wrote:

> Dan just released "DakaRand"
>   http://dankaminsky.com/2012/08/15/dakarand/
>
> src http://s3.amazonaws.com/dmk/dakarand-1.0.tgz
>
> while admitting that "Matt Blaze has essentially disowned this
> approach, and seems to be honestly horrified that I’m revisiting it"
> and "Let me be the first to say, I don’t know that this works." this
> mode would greatly reduce, maybe eliminate the incidence of key
> duplication in large sample sets (e.g. visibly poor entropy for key
> generation)
>
> the weak keys[0] authors clearly posit that they have detected merely
> the most obvious and readily accessible poor keys, and that further
> attacks against generator state could yield even more vulnerable
> pairs... you have been warned :P
>
> the solution is adding hw entropy[1][2] to the mix. anything less is
> doing it wrong!
>
> if you don't have hw entropy, adding dakarand is better than not.
>
> 0. "Mining Your Ps and Qs: Detection of Widespread Weak Keys in
> Network Devices - Extended"
>   https://factorable.net/weakkeys12.extended.pdf
>
> 1. "Intel RNG"
>   http://lists.randombit.net/pipermail/cryptography/2012-June/002995.html
>  see also by thread:
>
> http://lists.randombit.net/pipermail/cryptography/2012-June/thread.html#2995
>
> 2. xstore
>
> http://www.via.com.tw/en/downloads/whitepapers/initiatives/padlock/rng_prog_guide.pdf
>
> X. LD 50 radiation exposure of the common pigeon. entropy via carrier
> pigeon (DRAFT)
>  ;P
>
> P.P.S: if you're not passing valid hw entropy into VM guests, you're
> also doing it wrong. even enough passed at boot is sufficient,
> provided key generation is secure. always a million caveats... and
> adding dakarand to guests is better than not.
>
>
> On Wed, Jul 18, 2012 at 12:35 PM, coderman  wrote:
> > On Fri, Dec 24, 2010 at 5:08 PM, Dan Kaminsky  wrote:
> >> ...
> >> Don't we have hardware RNG in most motherboard chipsets nowadays?
> >
> > clearly not enough of them!
> >
> > 'Mining Your Ps and Qs: Detection of Widespread Weak Keys in Network
> Devices'
> > https://factorable.net/weakkeys12.extended.pdf
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Google Accounts Security Vulnerability

[Dan Kaminsky]

Surely you can create a sock puppet for debugging purposes.

On Thu, May 17, 2012 at 11:43 AM, Michael Gray  wrote:

> I'm not interested in providing that information. You can reproduce it
> without knowing my user name.
> On May 17, 2012 8:45 AM, "Mike Hearn"  wrote:
>
>> If you provide the name of the account you're logging in to, we can go
>> take a look what's happening.
>>
>> On Thu, May 17, 2012 at 5:29 PM, Michael Gray  wrote:
>> > Regardless of how you say it works, I can bypass it every time it would
>> > seem. Again, by using the method in my original post. It's likely you
>> have a
>> > bug if this isn't the functionality you're after.
>> >
>> > I appreciate the statistics but they mean little to me.
>> >
>> > Thank you for taking the time to respond. I hope my suggestions and
>> findings
>> > will assist you in correcting these issues
>> >
>> > On May 17, 2012 5:51 AM, "Mike Hearn"  wrote:
>> >>
>> >> I understand your concerns, however they are not valid. You can be
>> >> assured of the following:
>> >>
>> >> 1) We do not see this system as a replacement for passwords. If we
>> >> block a login the user is notified and asked if it was them, if it
>> >> wasn't we ask them to pick a new password. In very high confidence
>> >> cases we will immediately force the user to choose a new password,
>> >> because passwords are still the first line of defense.
>> >>
>> >> 2) We do not see this system as a replacement for 2-factor
>> >> authentication. However the reality is that the vast majority of our
>> >> users do not use 2-factor authentication and this is unlikely to
>> >> change any time soon. 2SV imposes a significant extra burden on the
>> >> user such that despite heavy promotion many users refuse to sign up,
>> >> and of those that do, many choose to unenroll shortly afterwards.
>> >> Therefore we also provide this always-on best effort system as well.
>> >>
>> >> 3) In fact it is very effective at stopping the large, botnet driven
>> >> types of attacks we see on a daily basis and so saying it doesn't add
>> >> any security is wrong. Since going live the system has successfully
>> >> defended tens of millions of users who have a compromised password. A
>> >> single unrepresentative data point based on one account isn't enough
>> >> for you to judge the utility of the system, whereas we can clearly see
>> >> the stopped campaigns (and drop in number of attempts).
>> >>
>> >> That said, if you have friends and relatives who use Google and you'd
>> >> like to to make them more secure, by all means encourage them to set
>> >> up two-factor authentication.
>>
>>
>>
>> --
>>
>> Mike Hearn | Senior Software Engineer | he...@google.com | Account
>> security team
>>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] The story of the Linux kernel 3.x...

[Dan Kaminsky]

>
> But we're making progress, we now know that opensuse on x86 is broken.
>
>
Is VSYSCALL at a fixed address a similar problem?  My Ubuntu boxes indeed
have this mapped at the fixed location mentioned.

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Trigerring Java code from a SVG image

[Dan Kaminsky]

Anything from  in any browser?

On Wed, May 16, 2012 at 2:25 AM, Michele Orru wrote:

> Mario Heiderich did a lot of research on that, he found so many bugs
> that allowed
> to embed Javascript in SVG images.
>
> Nice stuff Nick btw,
>
> Cheers
> antisnatchor
>
> On Wed, May 16, 2012 at 10:13 AM, Dan Kaminsky  wrote:
> > Yeah, there's a bunch of wild stuff in SVG.  The browsers ignore most of
> it,
> > AFAIK.  I think Firefox is the only browser to even consider
> ForeignObjects
> > (which let you throw HTML back into SVG).
> >
> > Probably the most interesting SVG thing is how they either do or don't
> have
> > script access, depending on whether or not they're loaded as 's.  It
> > would be problematic indeed if  could suddenly render
> > script!
> >
> >
> > On Tue, May 15, 2012 at 5:07 AM, Nicolas Grégoire
> >  wrote:
> >>
> >> Hello,
> >>
> >> SVG is a XML-based file format for static or animated images. Some SVG
> >> specifications (like  SVG 1.1 and SVG Tiny 1.2) allow to trigger some
> >> Java code when the SVG file is opened.
> >>
> >> Given that I had to look at these features for a customer, I developed
> >> some PoC codes which are now available online:
> >> http://www.agarri.fr/docs/batik-evil.svg
> >> http://www.agarri.fr/docs/batik-evil.jar
> >>
> >> I published a more detailed article on my blog:
> >> http://www.agarri.fr/blog/
> >>
> >> Regards,
> >> Nicolas Grégoire / @Agarri_FR
> >>
> >> ___
> >> Full-Disclosure - We believe in it.
> >> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> >> Hosted and sponsored by Secunia - http://secunia.com/
> >
> >
> >
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
>
>
> --
> /antisnatchor
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Trigerring Java code from a SVG image

[Dan Kaminsky]

Yeah, there's a bunch of wild stuff in SVG.  The browsers ignore most of
it, AFAIK.  I think Firefox is the only browser to even consider
ForeignObjects (which let you throw HTML back into SVG).

Probably the most interesting SVG thing is how they either do or don't have
script access, depending on whether or not they're loaded as 's.  It
would be problematic indeed if  could suddenly render
script!


On Tue, May 15, 2012 at 5:07 AM, Nicolas Grégoire <
nicolas.grego...@agarri.fr> wrote:

> Hello,
>
> SVG is a XML-based file format for static or animated images. Some SVG
> specifications (like  SVG 1.1 and SVG Tiny 1.2) allow to trigger some
> Java code when the SVG file is opened.
>
> Given that I had to look at these features for a customer, I developed
> some PoC codes which are now available online:
> http://www.agarri.fr/docs/batik-evil.svg
> http://www.agarri.fr/docs/batik-evil.jar
>
> I published a more detailed article on my blog:
> http://www.agarri.fr/blog/
>
> Regards,
> Nicolas Grégoire / @Agarri_FR
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

Well, what this all tells me is that my process of simply checking for
advertised configuration methods understates the number of nodes actually
vulnerable.  Reaver should be modifiable into an active scanner, at least.

On Mon, Feb 13, 2012 at 7:09 PM, Ian Hayes  wrote:

> On Mon, Feb 13, 2012 at 1:57 PM, Dan Kaminsky  wrote:
> > That's a fairly significant finding.  Can anyone else confirm the
> existence
> > of devices that still fall to Reaver even when WPS is disabled?
>
> The Netgear N750 definitely does. I can rummage through my Box'o'Stuff
> and see if I have any more wireless APs...
>
> It looks like the Belkin routers don't. After disabling WPS, reaver
> just hung after hitting the channel the AP was on. Re-enabling, reaver
> went right to work.
>
> Just in case anyone hasn't figured out how to use it yet, I did an
> in-house presentation a few weeks ago:
>
>
> http://www.n2netsec.com/site/index.php?option=com_content&view=section&layout=blog&id=5&Itemid=89
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

That's a fairly significant finding.  Can anyone else confirm the existence
of devices that still fall to Reaver even when WPS is disabled?

Chris, when you run:

iw scan wlan0 | grep “Config methods”

Do you see a difference in advertised methods?

On Mon, Feb 13, 2012 at 3:58 PM, chris nelson wrote:

> i have tested reaver on a netgear and linksys (dont have model nos. with
> me) with wps disabled and enabled. the wps setting did not matter and both
> were vulnerable. was able to recover wpa2 passphrase in ~4 hrs on both.
>
>
>
>
> On Mon, Feb 13, 2012 at 8:32 AM, Dan Kaminsky  wrote:
>
>> Steve while he's often derided goes into this very well.  Many cisco's
>>> only stop advertising wps when it is "off" but wps actually still
>>> exists...which means they are still easily hackable.
>>>
>>
>> Have you directly confirmed a WPS exchange can occur even on devices that
>> aren't advertising support?  That would indeed be a quick and dirty way to
>> "turn the feature off".
>>
>>
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

>
> Steve while he's often derided goes into this very well.  Many cisco's
> only stop advertising wps when it is "off" but wps actually still
> exists...which means they are still easily hackable.
>

Have you directly confirmed a WPS exchange can occur even on devices that
aren't advertising support?  That would indeed be a quick and dirty way to
"turn the feature off".
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

Interesting.  Do you know if they stop advertising WPS support after they
disable it?

On Sun, Feb 12, 2012 at 10:11 AM, Rob Fuller  wrote:

> I've tested a 6 models of Linksys, all of them appear to disable WPS
> completely as soon as a single wireless setting is set. I assume this
> would be the reason Cisco/Linksys aren't putting much stock in
> 'fixing' it further. If anyone has any experience to contradict this
> or have a modification to current tools to circumvent what I've
> perceived as disabled, I, as I'm sure Craig, would be very interested.
>
> --
> Rob Fuller | Mubix
> Certified Checkbox Unchecker
> Room362.com | Hak5.org
>
>
>
> On Sat, Feb 11, 2012 at 4:23 PM,   wrote:
> > _
> > "Use Tomato-USB OS on them."
> > _
> >
> > Besides you void warranty...
> > list of DD-WRT Supported routers:
> >
> >  E1000supported
> >  E1000 v2 supported
> >  E1000 v2.1   supported
> >  E1200 v1 ???
> >  E1200 v2 ???
> >  E1500???
> >  E1550???
> >  E2000supported
> >  E2100L   supported
> >  E2500not supported
> >  E3000supported
> >  E3200supported
> >  E4200 v1 not supported yet
> >  E4200 v2 not supported
> >  M10  
> >  M20  
> >  M20 v2   
> >  RE1000   
> >  WAG120N  not supported
> >  WAG160N  not supported
> >  WAG160N v2   not supported
> >  WAG310G  not supported
> >  WAG320N  not supported
> >  WAG54G2  not supported
> >  WAP610N  not supported
> >  WRT110   not supported
> >  WRT120N  not supported
> >  WRT160N v1   supported
> >  WRT160N v2   not supported
> >  WRT160N v3   supported
> >  WRT160NL supported
> >  WRT310N v1   supported
> >  WRT310N v2   not supported yet
> >  WRT320N  supported
> >  WRT400N  supported
> >  WRT54G2 v1   supported
> >  WRT54G2 v1.3 supported
> >  WRT54G2 v1.5 not supported
> >  WRT54GS2 v1  supported
> >  WRT610N v1   supported
> >  WRT610N v2   supported
> >  X2000not supported
> >  X2000 v2 not supported
> >  X3000not supported.
> >
> > _
> >
> > "Fixing?  Heh.
> >
> > Aside from rate limiting WPS, there isn't much of a fix, and you can't
> turn it off either."
> > _
> >
> > What about removing WuPS entirely?
> >
> > WuPS is a total failure because:
> >
> > 1. Even if everything is fine 8 digits long is very weak because once
> you got the pin after 7 month - 2 years for example, you are completely
> pwned.
> >
> > 2. Pin number is fixed you can't change it to a longer number or maybe a
> string like "omgponnies"
> >
> > 3. Setting up a WPA2 password manually it's a piece of cake (even with
> keypad only cell phones), if some people are lazy, you don't have to
> weakening the security of a strong protocol.
> >
> > Farth Vader
> >
> > ___
> > Full-Disclosure - We believe in it.
> > Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > Hosted and sponsored by Secunia - http://secunia.com/
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

On Fri, Feb 10, 2012 at 4:33 PM,  wrote:

> On Fri, 10 Feb 2012 14:41:37 EST, Dan Kaminsky said:
>
> > According to the Reaver people, DD-WRT doesn't support WPS at all :)
>
> The sort of people that run DD-WRT probably consider that a feature, not a
> bug. ;)
>

If you've got the skill to install DD-WRT, you've got the skill to manually
set up WPA2.

Note, by the way, the core concept of WPS (that setup should be easy) was
absolutely correct, and we have hard data that it worked.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

According to the Reaver people, DD-WRT doesn't support WPS at all :)

On Fri, Feb 10, 2012 at 2:00 PM, Zach C.  wrote:

> Solution: use DD-WRT? Or is that vulnerable too? (Or are there worse
> problems? :))
> On Feb 10, 2012 10:12 AM, "Dan Kaminsky"  wrote:
>
>> "Fixing a vulnerability like this with all the bureoucratic, QA and legal
>> process wouldn't take no more than 2 weeks"
>>
>> If bureaucratic, QA, and legal issues emerge, you can't even get the
>> names of the people you need to speak to in less than 2 weeks, let alone
>> schedule a conference call. Fixing?  Heh.
>>
>> Aside from rate limiting WPS, there isn't much of a fix, and you can't
>> turn it off either.
>>
>> Sent from my iPhone
>>
>> On Feb 10, 2012, at 2:40 AM, farthva...@hush.ai wrote:
>>
>> Don't buy Linksys Routers they are vulnerable to Wifi unProtected Setup
>> Pin registrar Brute force attack.
>> No patch or workaround exist at the making of this post.
>>
>> Vulnerable list and alleged patch availability:
>> source:http://www6.nohold.net/Cisco2/ukp.aspx?vw=1&articleid=25154
>>
>>  E1000  To Be Disclosed (aka we don't have idea)
>>  E1000 v2  To Be Disclosed
>>  E1000 v2.1  To Be Disclosed
>>  E1200 v1 early March
>>  E1200 v2 early March
>>  E1500 early March
>>  E1550 mid March
>>  E2000 To Be Disclosed
>>  E2100L mid March
>>  E2500 early March
>>  E3000 To Be Disclosed
>>  E3200 early March
>>  E4200 v1 early March
>>  E4200 v2 To Be Disclosed
>>  M10 To Be Disclosed
>>  M20 To Be Disclosed
>>  M20 v2 To Be Disclosed
>>  RE1000 early March
>>  WAG120N To Be Disclosed
>>  WAG160N To Be Disclosed
>>  WAG160N v2 To Be Disclosed
>>  WAG310G To Be Disclosed
>>  WAG320N To Be Disclosed
>>  WAG54G2 To Be Disclosed
>>  WAP610N To Be Disclosed
>>  WRT110 To Be Disclosed
>>  WRT120N To Be Disclosed
>>  WRT160N v1 To Be Disclosed
>>  WRT160N v2 To Be Disclosed
>>  WRT160N v3 To Be Disclosed
>>  WRT160NL To Be Disclosed
>>  WRT310N v1 To Be Disclosed
>>  WRT310N v2 To Be Disclosed
>>  WRT320N To Be Disclosed
>>  WRT400N To Be Disclosed
>>  WRT54G2 v1 To Be Disclosed
>>  WRT54G2 v1.3 To Be Disclosed
>>  WRT54G2 v1.5 To Be Disclosed
>>  WRT54GS2 v1 To Be Disclosed
>>  WRT610N v1 To Be Disclosed
>>  WRT610N v2 To Be Disclosed
>>  X2000 To Be Disclosed
>>  X2000 v2 To Be Disclosed
>>  X3000 To Be Disclosed
>>
>> The question is why a big company like Cisco/Linksys didn't release a
>> patch since almost 1 month and a half ?.
>>
>> Well i have circumstantial evidence that Cisco outsource some of their
>> Linksys firmware routers to other companies (Arcadyan for example.) in some
>> cases source code is only available through NDA's or not available at all.
>> That's why they are taking so long to release a fix to the WPS
>> vulnerability. Fixing a vulnerability like this with all the bureoucratic,
>> QA and legal process wouldn't take no more than 2 weeks. I found some GPL
>> violations by the way but this is beyond the scope of this message
>> (obfuscating firmware it's useless you now).
>>
>> I apologize if i offended someone but IT security it's serious business
>> specially if someone use your wifi to commit crimes.
>> This vulnerability contains public and very easy to use exploit code,
>> it's not a Denial of Service.
>>
>>
>> Farth Vader.
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Linksys Routers still Vulnerable to Wps vulnerability.

[Dan Kaminsky]

"Fixing a vulnerability like this with all the bureoucratic, QA and legal 
process wouldn't take no more than 2 weeks"

If bureaucratic, QA, and legal issues emerge, you can't even get the names of 
the people you need to speak to in less than 2 weeks, let alone schedule a 
conference call. Fixing?  Heh.  

Aside from rate limiting WPS, there isn't much of a fix, and you can't turn it 
off either.

Sent from my iPhone

On Feb 10, 2012, at 2:40 AM, farthva...@hush.ai wrote:

> Don't buy Linksys Routers they are vulnerable to Wifi unProtected Setup Pin 
> registrar Brute force attack.
> No patch or workaround exist at the making of this post.
> 
> Vulnerable list and alleged patch availability:
> source:http://www6.nohold.net/Cisco2/ukp.aspx?vw=1&articleid=25154
> 
>  E1000  To Be Disclosed (aka we don't have idea)
>  E1000 v2  To Be Disclosed
>  E1000 v2.1  To Be Disclosed
>  E1200 v1 early March
>  E1200 v2 early March
>  E1500 early March
>  E1550 mid March
>  E2000 To Be Disclosed
>  E2100L mid March
>  E2500 early March
>  E3000 To Be Disclosed 
>  E3200 early March
>  E4200 v1 early March
>  E4200 v2 To Be Disclosed
>  M10 To Be Disclosed
>  M20 To Be Disclosed
>  M20 v2 To Be Disclosed
>  RE1000 early March
>  WAG120N To Be Disclosed
>  WAG160N To Be Disclosed
>  WAG160N v2 To Be Disclosed
>  WAG310G To Be Disclosed
>  WAG320N To Be Disclosed
>  WAG54G2 To Be Disclosed
>  WAP610N To Be Disclosed
>  WRT110 To Be Disclosed
>  WRT120N To Be Disclosed
>  WRT160N v1 To Be Disclosed
>  WRT160N v2 To Be Disclosed
>  WRT160N v3 To Be Disclosed
>  WRT160NL To Be Disclosed
>  WRT310N v1 To Be Disclosed
>  WRT310N v2 To Be Disclosed
>  WRT320N To Be Disclosed
>  WRT400N To Be Disclosed
>  WRT54G2 v1 To Be Disclosed
>  WRT54G2 v1.3 To Be Disclosed
>  WRT54G2 v1.5 To Be Disclosed
>  WRT54GS2 v1 To Be Disclosed
>  WRT610N v1 To Be Disclosed
>  WRT610N v2 To Be Disclosed
>  X2000 To Be Disclosed
>  X2000 v2 To Be Disclosed
>  X3000 To Be Disclosed
> 
> The question is why a big company like Cisco/Linksys didn't release a patch 
> since almost 1 month and a half ?.
> 
> Well i have circumstantial evidence that Cisco outsource some of their 
> Linksys firmware routers to other companies (Arcadyan for example.) in some 
> cases source code is only available through NDA's or not available at all. 
> That's why they are taking so long to release a fix to the WPS vulnerability. 
> Fixing a vulnerability like this with all the bureoucratic, QA and legal 
> process wouldn't take no more than 2 weeks. I found some GPL violations by 
> the way but this is beyond the scope of this message (obfuscating firmware 
> it's useless you now).
> 
> I apologize if i offended someone but IT security it's serious business 
> specially if someone use your wifi to commit crimes.
> This vulnerability contains public and very easy to use exploit code, it's 
> not a Denial of Service.
> 
> 
> Farth Vader.
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Fun with Bitcoin, or how an exploit can hide in plain sight

[Dan Kaminsky]

Welcome to why BitCoin is so impressive.  You've got this app.  It's wide
open to the Internet, to the point where it opens up firewall rules if
necessary.  It's running some home grown network protocol, that ostensibly
ships little executable programs around.  It's written in C++, the
non-memory safe language you shoot your foot off with.  If you break it,
you get all the money.

Given all those anticonstraints, you're *still* left mucking around with
incredibly subtle design bugs, like my deanonymization through being the
majority of the cloud, or Microsoft's Red Balloon attack in which they
"hoard" transaction information that pays a large fee, or your (really
cool) exploit against signature checking optimization.

It's a fun bug you found, and I'm glad its fixed, but oh man is it hard to
exploit, and at the point there's a 51% attacker, the entire system has
already fallen apart (if for no other reason than the 51% attacker can
censor and even reverse arbitrary transactions by creating the longer block
chain, both by refusing to include transactions, and by assigning to
himself the initial coins others might have thought they'd mined).

Great work though!

On Wed, Feb 1, 2012 at 10:05 AM, Aidan Thornton wrote:

> So most people on here have probably heard of Bitcoin from somewhere,
> and most of you have probably got tired of it - but bear with me
> because this is kind of entertaining. For those of you that have been
> stuck in a darkened room with a disassembler and no internet access
> for the past few months, Bitcoin's a clever digital currency that
> manages to solve the problem of someone spending the same money twice
> without needing any kind of central trusted authority. It does this by
> using a variant of hash-cash to make rewriting the history of past
> transactions expensive.
>
> Now this means that someone with more than half the total compute
> power can launch certain attacks - they're listed on the Bitcoin wiki
> at
> https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power
> - but even they aren't meant to have total control. In particular,
> they're not meant to be able to spend other people's money because
> doing so requires a signature from their private key:
>
> "The attacker can't: Send coins that never belonged to him"
>
> For several months that claim has been *false* as a result of this
> commit by the lead Bitcoin developer:
>
> https://github.com/bitcoin/bitcoin/commit/b14bd4df58171454c2aa580ffad94982943483f5
>
> Now, while obviously that commit is doing something slightly risky,
> there's a nice reassuring comment from him in the code explaining
> exactly why it's not actually a security risk:
>
> // Skip ECDSA signature verification when connecting blocks
> (fBlock=true) during initial download
> // (before the last blockchain checkpoint). This is safe because block
> merkle hashes are
> // still computed and checked, and any change will be caught at the
> next checkpoint.
>
> It's a very convincing explanation to anyone that understands Bitcoin.
> You can only really add a blockchain checkpoint if all the nodes agree
> that the chain up to that point is valid - otherwise things will break
> in a fairly spectacular and obvious way - so a whole bunch of other
> Bitcoin nodes run by many independent people will already have
> verified the ECDSA signatures. There's even a good justification for
> making the change. Initial blockchain downloads are far too slow which
> discourages new users, and ECDSA signature verification is one of the
> slowest parts.
>
> Unfortunately the comment is fatally wrong. Even more scarily, there's
> no reason at all to suspect this from the commit diff, which is
> probably why no-one noticed anything was amiss when it was committed.
> If you take a look at the actual definition of IsInitialBlockDownload
> there's actually *two* situations which it considers part of the
> initial download. One of them is indeed being before the last
> blockchain checkpoint:
>
> if (pindexBest == NULL || nBestHeight <
> Checkpoints::GetTotalBlocksEstimate()) return true;
>
> The other involves the timestamp included within the last block and
> how recently it was received:
>
> return (GetTime() - nLastUpdate < 10 && pindexBest->GetBlockTime() <
> GetTime() - 24 * 60 * 60);
>
> So, if we receive a block less than 10 seconds after the previous one
> and the previous block had a timestamp more than 24 hours in the past,
> we don't bother to verify any of the ECDSA signatures in it and will
> allow it to include transactions that spend random people's Bitcoins!
>
> A powerful attacker could definitely exploit this; timestamps in the
> future are rejected and Bitcoin won't generally accept a version of
> history in which time goes backwards, but otherwise a 51% attacker can
> choose whatever timestamps they like and can delay releasing their
> version of the chain to meet the "less than 10 seconds" requirement.
> It's a very expensive attack but far 

Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine

[Dan Kaminsky]

Those who try to manage potentially malicious servers do so over IP KVM, in
which the foreign server basically gets only inbound Keyboard and Mouse and
outbound uncompressed pixels.

Anything more is untrusted, for a reason.

On Tue, Jan 24, 2012 at 5:50 PM, Nick FitzGerald
wrote:

> Ben Bucksch wrote:
>
> > Even then, that is not sufficient, as explained in length.
>
> No -- what you "explained in length" _and_ seem impervious to
> understanding, despite a couple of respondents explaining it quite
> clearly, is that you have chosen to perform ongoing "sensitive" work in
> an environment where doing so is, at best, represents a highly
> questionable security stance.
>
> _Part_ of what contributes to that questionability is your choice to
> more-or-less continuously run an application that you should always
> have known leaks access to the clipboard of what you oddly choose to
> describe as a "trusted desktop" (odd, because you should know that
> exposing the host clipboard to the client is common -- in fact,
> probably the standard default -- functionality of VNC clients).
>
> That your chosen/preferred/whatever VNC client does not allow you to
> turn off, or otherwise modify or monitor this functionality is not a
> security vulnerability or bug, as you seem intent on portraying it.  It
> may be an undesirable feature (or, more accurately, lack of a feature)
> but don't you have other VNC clients to choose from?  Must you use this
> particular VNC client?  If so and this method of working is so critical
> to you, should you not choose a different platform for your "trusted
> desktop" and run a more suitably configurable VNC client?  Or, if your
> sensitive work is really that sensitive, should you not invest in a
> second machine for remotely monitoring/interacting with the the
> untrusted, sandboxed applications you need to run, so that they really
> are securely separated (can we all say "air gap"?) from your more
> "sensitive" operations?  It would not have to be a very heavy-duty
> machine -- a very low-end netbook style machine, or possibly even a
> cheap tablet-style device may more than suffice...
>
> ...
>
> Another part of that questionability is obvious to anyone with nous
> reading this list...
>
>
>
> Regards,
>
> Nick FitzGerald
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Avast Antivirus

[Dan Kaminsky]

Nothing to be done, really.  Most users run as admin.

On Tue, Jan 17, 2012 at 4:19 PM, Floste  wrote:

> Hello,
>
> Avast Antivirus also comes with sandbox and a "SafeZone". But both can
> be circumvented using simple dll-injection and they seem to do nothing
> about it: http://forum.avast.com/index.php?topic=82291.0
>
> Maybe this post here will encourage them to fix it.
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] [CVE-2012-0207] Linux IGMP Remote Denial Of Service

[Dan Kaminsky]

LAN-only, no?

Sent from my iPhone

On Jan 17, 2012, at 4:11 PM, "HI-TECH ." 
 wrote:

> Demonstration of the Exploit:
> http://www.youtube.com/watch?v=78nAxh70yZE (thanks ClsHack)
> 
> see attached content
> 
> /Kingcope
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] WiFi Protected Setup attack code posted

[Dan Kaminsky]

WPS could have been fine, in that it would have forced an online attack that 
took an infeasible amount of time. 

It just didn't accomplish that.

My thinking is that they'll get this property back into WPS with some sort of 
blinding of the half-break state, but I haven't dug into the vuln enough to be 
sure. 

Sent from my iPhone

On Dec 29, 2011, at 11:38 AM, Gage Bystrom  wrote:

> Is be surprised if anyone related to security actually thought WPS was 
> remotely safe, bout time some actually released a public tool to brute it 
> though :P
> 
> On Dec 29, 2011 2:02 AM, "Craig Heffner"  wrote:
> Yesterday, Stefan published a paper describing a vulnerability in WPS that 
> allows attackers to recover WPA/WPA2 keys in a matter of hours 
> (http://sviehb.wordpress.com/2011/12/27/wi-fi-protected-setup-pin-brute-force-vulnerability/).
> 
> Code has been posted to implement the attack: 
> http://www.tacnetsol.com/news/2011/12/28/cracking-wifi-protected-setup-with-reaver.html
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OT: Firefox question / poll

[Dan Kaminsky]

On Tue, Dec 20, 2011 at 7:00 PM, coderman  wrote:

> On Tue, Dec 20, 2011 at 9:40 AM, Charles Morris 
> wrote:
> > I'm curious what everyone's opinion is on the following question...
> > esp. to any FF dev people on list:
> >
> > Do you think that the Firefox "warning: unresponsive script" is meant
> > as a security feature or a usability feature?
>
> anyone who said "security feature" is an idiot and/or not thinking clearly.
> your security is harmed by malicious script in milliseconds.
> this does nothing to protect you from anything.*
>
> it is purely a usability feature in response to shitty developers
> writing shitty webapps leading to excessively long script execution
> (which can thus be terminated if desired once this warning presents)
>
>
> * someone may say "availability is a security requirement!". true, but
> then a modem link to web 2.0 is a DoS, and there's simply no point
> going down that road...
>
> Absolutely correct.  There's effectively an infinite number of temporary
DoS attacks against browsers.  They're fragile enough in this space that
"exploits" are *accidentally* stumbled upon by devs.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default

[Dan Kaminsky]

On Mon, Nov 21, 2011 at 9:58 AM,  wrote:

> On Mon, 21 Nov 2011 14:12:38 GMT, Darren Martyn said:
>
> >  Valdis - I did not know the source had gotten THAT big, still, will be
> > interesting to explore parts of it that interest me - the TCP stack for a
> > start... Also, thanks for the advice on the book :)
>
> As of this morning, Linus's git tree had:
>
> [/usr/src/linux] find * -type f | xargs cat | wc -l
> 14993265
>
> and we're still at 3.2.0-rc2.  Almost certainly will tip over 15M by the
> time Linus
> lets 3.2.0 escape.  The linux-next tree (which will become 3.3) is already
> sitting at
> somewhere north of 15.3M lines of code.  Yes, we're averaging 100K lines
> of code
> a month.
>
>
15.3M lines of code != 15.3M lines of code in use on any one system !=
15.3M lines of code that can ever involve a security boundary.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default

[Dan Kaminsky]

Blocking of unpassworded accounts in sshd_config, IIRC.

Sent from my iPhone

On Nov 19, 2011, at 7:35 PM, Robert Kim App and Facebook Marketing 
 wrote:

> Ummm... any idea why remote SSH is not possible?!?!? o_O
> kinna weird!
> 
> On Thu, Nov 17, 2011 at 4:23 AM, Olivier  wrote:
> Hi list,
> 
> Unfortunately remote SSH connection are not allowed, I suggest guest
> account to be silently add in /etc/shadow for 12.04. It could be the
> best Ubuntu April fool ever.
> 
> Maybe calibre could also be installed by default, for a root shell out
> of the box.
> 
> 
> 
> -- 
> Robert Q Kim
> Facebook Marketing Strategies and Web Consultant
> http://sparkah.com/2010/08/25/facebook-marketing-strategies-from-nyc-and-los-angeles-most-devious-minds-2/
> 2611 S Coast Highway
> San Diego, CA 92007
> 310 598 1606
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default

[Dan Kaminsky]

Er, sudo bash gives you /dev/kmem, access to the hard drive block device...

Sent from my iPhone

On Nov 19, 2011, at 11:44 AM, ja...@zero-internet.org.uk wrote:

> Effective user id as a short answer; compare sudo whoami and su - whoami
> 
> 
> Sent from my BlackBerry® wireless device
> 
> -Original Message-
> From: Dan Kaminsky 
> Date: Sat, 19 Nov 2011 11:36:47 
> To: ja...@zero-internet.org.uk
> Cc: Johan Nestaas; 
> full-disclosure-boun...@lists.grok.org.uk;
>  Olivier; 
> full-disclosure@lists.grok.org.uk
> Subject: Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default
> 
> What is the security differential between su and sudo bash?
> 
> Sent from my iPhone
> 
> On Nov 19, 2011, at 6:15 AM, ja...@zero-internet.org.uk wrote:
> 
>> I'll second that; the isp I work at has a sizeable ubuntu customer base and 
>> these are customers who have made an informed decision.
>> 
>> Now; let's consider ubuntu's inherited security from debian such as 
>> configuring a 'mortal account' (admittedly can be ignored in the preseed) 
>> and then the lack of perms on su; must use sudo.
>> 
>> This is a distro that is newbie friendly but is not designed specifically 
>> for them.
>> 
>> Unfortunately, though, you make a distro with simplified tasks (printer 
>> installation a fantastic example) and people, especially long term linuxers- 
>> though I ought to be included I guess, remember back all too easily to when 
>> everything was an uphill struggle: "what do you mean I don't have to compile 
>> this as a flipping module? That's not freedom!" Being all too familiar.
>> 
>> Just my tuppence worth anyway.
>> 
>> Sent from my BlackBerry® wireless device
>> 
>> -Original Message-
>> From: Johan Nestaas 
>> Sender: full-disclosure-boun...@lists.grok.org.uk
>> Date: Fri, 18 Nov 2011 12:04:46 
>> To: Olivier
>> Cc: 
>> Subject: Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default
>> 
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default

[Dan Kaminsky]

What is the security differential between su and sudo bash?

Sent from my iPhone

On Nov 19, 2011, at 6:15 AM, ja...@zero-internet.org.uk wrote:

> I'll second that; the isp I work at has a sizeable ubuntu customer base and 
> these are customers who have made an informed decision.
> 
> Now; let's consider ubuntu's inherited security from debian such as 
> configuring a 'mortal account' (admittedly can be ignored in the preseed) and 
> then the lack of perms on su; must use sudo.
> 
> This is a distro that is newbie friendly but is not designed specifically for 
> them.
> 
> Unfortunately, though, you make a distro with simplified tasks (printer 
> installation a fantastic example) and people, especially long term linuxers- 
> though I ought to be included I guess, remember back all too easily to when 
> everything was an uphill struggle: "what do you mean I don't have to compile 
> this as a flipping module? That's not freedom!" Being all too familiar.
> 
> Just my tuppence worth anyway.
> 
> Sent from my BlackBerry® wireless device
> 
> -Original Message-
> From: Johan Nestaas 
> Sender: full-disclosure-boun...@lists.grok.org.uk
> Date: Fri, 18 Nov 2011 12:04:46 
> To: Olivier
> Cc: 
> Subject: Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Ubuntu 11.10 now unsecure by default

[Dan Kaminsky]

On Fri, Nov 18, 2011 at 5:01 AM,  wrote:

> On Thu, 17 Nov 2011 15:53:41 CST, C de-Avillez said:
>
> > There is no guest account on an Ubuntu server, so at least there
> > this is not a real/perceived risk.
>
> And nobody's *ever* installed the desktop version on a server because they
> didn't
> know any better, especially from Ubuntu's target audience.  Gotcha. ;)
>

OK, seriously.  If you're sitting in front of a machine that's presenting
you a login prompt, you've got enough privileges to insert a bootable
USB/CD and pull all the data / make yourself an account (FDE/Bios PW
notwithstanding).


>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Verizon Wireless DNS Tunneling

[Dan Kaminsky]

You never know what you'll be breaking, but you always know you'll be paying
for support calls.

On Fri, Oct 7, 2011 at 12:38 PM, Hartley, Christopher wrote:

> I would think that at minimum, thresholds could be set on how many names to
> resolve, and permitted types for unauthenticated users.  Prohibit NULL and
> TXT records for unauthenticated hosts - or just whitelist A and CNAMEs,
> reject others.  Reject the 50th (or whatever) query from an unauthenticated
> host/user... I don't think NACs are using DNS tricks in the main anymore
> anyway.  They shouldn't be...  there are much better ways.
>
> That said, I'm happy for this condition to exist permanently so long as I'm
> not responsible for the traffic.
>
>
> On Oct 7, 2011, at 10:26 AM, James Wright wrote:
>
> Actually, yes, they could provide bad data.  I believe (perhaps
> erroneously) that Comcast does this.  Probably other service providers do
> too.  Until you are authenticated to use their network you are redirected to
> a service page that can help authenticate you.  If you have connectivity
> issues (like bad cached DNS entries) after authenticating you are to reboot
> (or otherwise clear the local DNS cache).
>
> I don't really see why Verizon could not do similar.  All DNS traffic from
> an unauthenticated user/machine would be redirected to a DNS server that
> only returned the appropriate service page.  Most or all other traffic would
> be blocked.  Much like NAC.
>
>
> Thanks,
> James
>
>
> On Fri, Oct 7, 2011 at 10:05 AM, Dan Kaminsky  wrote:
>
>> One major reason it sticks around is -- what are you supposed to do,
>> return bad data until the user is properly logged in?  It might get cached
>> -- and while operating systems respect TTL, browsers most assuredly do not
>> ("well, it MIGHT take us somewhere good").
>>
>> It's not like there's a magic off switch that makes this go away.
>>
>> On Fri, Oct 7, 2011 at 4:56 AM, Marshall Whittaker <
>> marshallwhitta...@gmail.com> wrote:
>>
>>> Yes, I've found that DNS tunneling works well at the college I go to on
>>> their WIFI.  I've never gotten ICMP tunneling to work myself (outside of a
>>> virtual machine),  but I have some code laying around somewhere that can do
>>> it just in case I need it for something sometime.  Just thought it would be
>>> interesting to some people that it works on such a large provider as
>>> Verizon.  The only problem with it that I see is that it's quite slow.  But
>>> if it works, so be it.  Good for checking email and browsing the web and
>>> such on the road.  But I wouldn't try to torrent a linux distro with it,
>>> haha.
>>>
>>> --oxagast
>>>
>>> On Fri, Oct 7, 2011 at 7:39 AM, BH  wrote:
>>>
>>>>  This comes in handy when travelling, I also found a few places where
>>>> ICMP tunnelling works well.
>>>>
>>>>
>>>> On 7/10/2011 6:35 PM, Dan Kaminsky wrote:
>>>>
>>>> Works mostly everywhere.  It's apparently enough of a pain in the butt
>>>> to deal with, and abused so infrequently, that it's left alone.
>>>>
>>>> On Fri, Oct 7, 2011 at 3:32 AM, Marshall Whittaker <
>>>> marshallwhitta...@gmail.com> wrote:
>>>>
>>>>> I recently noticed that you can tunnel TCP through DNS (I used iodine)
>>>>> to penetrate Verizon Wireless' firewall.  You can connect, and if you can
>>>>> hold the connection long enough to make a DNS tunnel, then the connection
>>>>> stays up, then use SSH -D to create a proxy server for your traffic. 
>>>>> Bottom
>>>>> line is, you can use the internet without paying. I made a video of it.  
>>>>> It
>>>>> can be seen here:
>>>>> http://www.youtube.com/user/Oxagast?blend=2&ob=5#p/u/0/X6oWESQMVd8 I
>>>>> tried to contact Verizon on their security blog about it a few weeks ago 
>>>>> at
>>>>> http://securityblog.verizonbusiness.com/ however, I have not had a
>>>>> response.  This technique still works as of this posting.  Maybe this will
>>>>> help them get their act together ;-)
>>>>>
>>>>>  --oxagast
>>>>>
>>>>> ___
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia

Re: [Full-disclosure] Verizon Wireless DNS Tunneling

[Dan Kaminsky]

Yeah, the problem is the bad data doesn't flush after authentication.  So
you try to go to Google, you're redirected to 10.0.0.1, you get
authenticated, but the browser still tries to go to 10.0.0.1.  You try
handling those support calls.  So instead most places give you real DNS, and
hijack at IP/TCP.

On Fri, Oct 7, 2011 at 7:26 AM, James Wright  wrote:

> Actually, yes, they could provide bad data.  I believe (perhaps
> erroneously) that Comcast does this.  Probably other service providers do
> too.  Until you are authenticated to use their network you are redirected to
> a service page that can help authenticate you.  If you have connectivity
> issues (like bad cached DNS entries) after authenticating you are to reboot
> (or otherwise clear the local DNS cache).
>
> I don't really see why Verizon could not do similar.  All DNS traffic from
> an unauthenticated user/machine would be redirected to a DNS server that
> only returned the appropriate service page.  Most or all other traffic would
> be blocked.  Much like NAC.
>
>
> Thanks,
> James
>
>
>
> On Fri, Oct 7, 2011 at 10:05 AM, Dan Kaminsky  wrote:
>
>> One major reason it sticks around is -- what are you supposed to do,
>> return bad data until the user is properly logged in?  It might get cached
>> -- and while operating systems respect TTL, browsers most assuredly do not
>> ("well, it MIGHT take us somewhere good").
>>
>> It's not like there's a magic off switch that makes this go away.
>>
>> On Fri, Oct 7, 2011 at 4:56 AM, Marshall Whittaker <
>> marshallwhitta...@gmail.com> wrote:
>>
>>> Yes, I've found that DNS tunneling works well at the college I go to on
>>> their WIFI.  I've never gotten ICMP tunneling to work myself (outside of a
>>> virtual machine),  but I have some code laying around somewhere that can do
>>> it just in case I need it for something sometime.  Just thought it would be
>>> interesting to some people that it works on such a large provider as
>>> Verizon.  The only problem with it that I see is that it's quite slow.  But
>>> if it works, so be it.  Good for checking email and browsing the web and
>>> such on the road.  But I wouldn't try to torrent a linux distro with it,
>>> haha.
>>>
>>> --oxagast
>>>
>>> On Fri, Oct 7, 2011 at 7:39 AM, BH  wrote:
>>>
>>>>  This comes in handy when travelling, I also found a few places where
>>>> ICMP tunnelling works well.
>>>>
>>>>
>>>> On 7/10/2011 6:35 PM, Dan Kaminsky wrote:
>>>>
>>>> Works mostly everywhere.  It's apparently enough of a pain in the butt
>>>> to deal with, and abused so infrequently, that it's left alone.
>>>>
>>>> On Fri, Oct 7, 2011 at 3:32 AM, Marshall Whittaker <
>>>> marshallwhitta...@gmail.com> wrote:
>>>>
>>>>> I recently noticed that you can tunnel TCP through DNS (I used iodine)
>>>>> to penetrate Verizon Wireless' firewall.  You can connect, and if you can
>>>>> hold the connection long enough to make a DNS tunnel, then the connection
>>>>> stays up, then use SSH -D to create a proxy server for your traffic. 
>>>>> Bottom
>>>>> line is, you can use the internet without paying. I made a video of it.  
>>>>> It
>>>>> can be seen here:
>>>>> http://www.youtube.com/user/Oxagast?blend=2&ob=5#p/u/0/X6oWESQMVd8 I
>>>>> tried to contact Verizon on their security blog about it a few weeks ago 
>>>>> at
>>>>> http://securityblog.verizonbusiness.com/ however, I have not had a
>>>>> response.  This technique still works as of this posting.  Maybe this will
>>>>> help them get their act together ;-)
>>>>>
>>>>>  --oxagast
>>>>>
>>>>> ___
>>>>> Full-Disclosure - We believe in it.
>>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>>
>>>>
>>>>
>>>>
>>>> ___
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>
>>>>
>>>>
>>>> ___
>>>> Full-Disclosure - We believe in it.
>>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>>
>>>
>>>
>>> ___
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Verizon Wireless DNS Tunneling

[Dan Kaminsky]

One major reason it sticks around is -- what are you supposed to do, return
bad data until the user is properly logged in?  It might get cached -- and
while operating systems respect TTL, browsers most assuredly do not ("well,
it MIGHT take us somewhere good").

It's not like there's a magic off switch that makes this go away.

On Fri, Oct 7, 2011 at 4:56 AM, Marshall Whittaker <
marshallwhitta...@gmail.com> wrote:

> Yes, I've found that DNS tunneling works well at the college I go to on
> their WIFI.  I've never gotten ICMP tunneling to work myself (outside of a
> virtual machine),  but I have some code laying around somewhere that can do
> it just in case I need it for something sometime.  Just thought it would be
> interesting to some people that it works on such a large provider as
> Verizon.  The only problem with it that I see is that it's quite slow.  But
> if it works, so be it.  Good for checking email and browsing the web and
> such on the road.  But I wouldn't try to torrent a linux distro with it,
> haha.
>
> --oxagast
>
> On Fri, Oct 7, 2011 at 7:39 AM, BH  wrote:
>
>>  This comes in handy when travelling, I also found a few places where ICMP
>> tunnelling works well.
>>
>>
>> On 7/10/2011 6:35 PM, Dan Kaminsky wrote:
>>
>> Works mostly everywhere.  It's apparently enough of a pain in the butt to
>> deal with, and abused so infrequently, that it's left alone.
>>
>> On Fri, Oct 7, 2011 at 3:32 AM, Marshall Whittaker <
>> marshallwhitta...@gmail.com> wrote:
>>
>>> I recently noticed that you can tunnel TCP through DNS (I used iodine) to
>>> penetrate Verizon Wireless' firewall.  You can connect, and if you can hold
>>> the connection long enough to make a DNS tunnel, then the connection stays
>>> up, then use SSH -D to create a proxy server for your traffic. Bottom line
>>> is, you can use the internet without paying. I made a video of it.  It can
>>> be seen here:
>>> http://www.youtube.com/user/Oxagast?blend=2&ob=5#p/u/0/X6oWESQMVd8 I
>>> tried to contact Verizon on their security blog about it a few weeks ago at
>>> http://securityblog.verizonbusiness.com/ however, I have not had a
>>> response.  This technique still works as of this posting.  Maybe this will
>>> help them get their act together ;-)
>>>
>>>  --oxagast
>>>
>>> ___
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>>
>>
>>
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Verizon Wireless DNS Tunneling

[Dan Kaminsky]

Works mostly everywhere.  It's apparently enough of a pain in the butt to
deal with, and abused so infrequently, that it's left alone.

On Fri, Oct 7, 2011 at 3:32 AM, Marshall Whittaker <
marshallwhitta...@gmail.com> wrote:

> I recently noticed that you can tunnel TCP through DNS (I used iodine) to
> penetrate Verizon Wireless' firewall.  You can connect, and if you can hold
> the connection long enough to make a DNS tunnel, then the connection stays
> up, then use SSH -D to create a proxy server for your traffic. Bottom line
> is, you can use the internet without paying. I made a video of it.  It can
> be seen here:
> http://www.youtube.com/user/Oxagast?blend=2&ob=5#p/u/0/X6oWESQMVd8 I tried
> to contact Verizon on their security blog about it a few weeks ago at
> http://securityblog.verizonbusiness.com/ however, I have not had a
> response.  This technique still works as of this posting.  Maybe this will
> help them get their act together ;-)
>
> --oxagast
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Twitter URL spoofing still exploitable

[Dan Kaminsky]

>
> Ok, now nobody can spoof a URL, but how come a user will tell good
> URLs and bad ones apart? Oh boy!
>
>
Wherever did you get the idea that users can do this?
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Recent claims that windows update is broken

[Dan Kaminsky]

>
> > For the record, no.  Windows Update doesn't just depend on
> WinVerifyTrust,
> > it also calls CertVerifyCertificateChainPolicy with
> > the CERT_CHAIN_POLICY_MICROSOFT_ROOT flag, documented here:
> >
> > http://msdn.microsoft.com/en-us/library/aa377163(v=vs.85).aspx
> >
> >
> >
>
> By your logic there would be no exploits just because the documentation
> writes so.
>

Nothing's stopping you from hooking CertVerifyCertificateChainPolicy and
seeing for yourself :)  See also:

http://twitter.com/#!/thierryzoller/status/112240979079204864

@thierryzoller: @dakami that finally explains why i didnt succeed in mitm it
few years ago


>
> I bothered to ask mainly for these reasons:
>
> 1. It is unclear to me what collection of private keys/certs Comodohacker
> has
>

He's been hitting certificates that have public interfaces, because as we
know, most public interfaces are terrible.

I do not expect the Microsoft Root to have a public interface.


> 2. From thereg article:
> >Microsoft declined to comment.
>

Microsoft commented rather clearly here:

http://bit.ly/q0JpIT

Attackers are not able to leverage a fraudulent Windows Update certificate
to install malware via the Windows Update servers. The Windows Update client
will only install binary payloads signed by the actual Microsoft root CA
certificate, which is issued and secured by Microsoft. Also, Windows Update
itself is not at risk, even to an attacker with a fraudulent certificate.

Obviously the guy's got all sorts of illicit access.  Just probably not
this.

>
> --
> georgi
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Recent claims that windows update is broken

[Dan Kaminsky]

On Thu, Sep 8, 2011 at 2:55 AM, Georgi Guninski wrote:

> http://www.theregister.co.uk/2011/09/07/diginotar_hacker_proof/
> "I'm able to issue windows update," he [Comodohacker] wrote. "Microsoft's
> statement about Windows Update and that I can't issue such update is totally
> false!"
>
> The original Comodohacker statement is at: http://pastebin.com/85WV10EL
>
> Is this true?
>

For the record, no.  Windows Update doesn't just depend on WinVerifyTrust,
it also calls CertVerifyCertificateChainPolicy with
the CERT_CHAIN_POLICY_MICROSOFT_ROOT flag, documented here:

http://msdn.microsoft.com/en-us/library/aa377163(v=vs.85).aspx



>
> --
> joro
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Apache Killer

[Dan Kaminsky]

On Wed, Aug 24, 2011 at 10:52 PM, root  wrote:

>
> > Seriously.  This is Zalewski we're talking about.  If you've extended his
> > work, you're doing something right.
>
>
> Or perhaps, not. Respectfully, fuck this elitist bullshit.
> I'm sure you and your friend are good hard-working guys. But you should
> not be the focus of every press release, specially if you didn't find
> the damn bug.
>
>
OK, so I looked into it.

Zalewski's stuff in 2007 was about bandwidth amplification -- with a few
requests, you could get a server to send you a truly enormous amount of
data.  Kingcope's attack shares the same vector (multiple range requests)
but uses it entirely differently, not as a drain of bandwidth on the client
but against memory on the server.  Different DoS, same buggy code.

Think of it like memory corruption -- in one person's hands, the daemon
simply crashes.  In another's, a reverse shell is born.

I don't think the press has made Zalewski the focus, though.  I looked at
the various articles on Google News; here's the distribution of credit I
see:

Register:  Credits both Kingcope and Zalewski by name
Computerworld:  Credits both Kingcope and Zalewski by name
LWN/Apache:  Credits neither, but links to Kingcope's post directly
H-Online:  Credits neither, but links to Kingcope's post directly
ZDNet:  Credits neither, but links to Kingcope's post directly
Slashdot:  Links to Kingcope's post directly, credits Zalewski by name
CRN: Credits Kingcope exclusively

For the record, it's a solid find.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Apache Killer

[Dan Kaminsky]

On Wed, Aug 24, 2011 at 9:45 PM, root  wrote:

> On 08/25/2011 01:33 AM, Michal Zalewski wrote:
> >> Good catch, but you didn't provide for a working exploit at the time.
> >>
> >> Now I only see your name on the press. Why?
> >
> > I don't know why this is in the news at all, let alone with any
> > specific attribution. Perhaps you wanted to ask the journalists?;-)
> >
> > /mz
> >
>
> Fair enough.
> Journalist, next time please use this headline:
>
> "Asshole hacker Kingwhatever post Apache DoS exactly on friday night.
> Google reportedly has nothing to do with it."
>
>
So it's come to pass that there's more gold per ton of landfill, than there
is in the raw earth.

It's still gold.

Seriously.  This is Zalewski we're talking about.  If you've extended his
work, you're doing something right.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Binary Planting Goes "Any File Type"

[Dan Kaminsky]

It's a nice attempt, but no.  The social engineering required to pull
that off exceeds what's required to get somebody to download and
execute setup.exe, and we don't call that RCE either.

Hundreds of false bugs are blinding you to probably a dozen real bugs.
 Likely more.  In security as in finance, the bad drives out the good.


On Fri, Jul 8, 2011 at 4:11 PM, Mitja Kolsek
 wrote:
> Ok, Dan, just for you:
>
> Launch Internet Explorer 9 on Windows 7 (probably other IE/Win works too), go 
> to File->Open (or press Ctrl+O), browse to Test.html and open it. No 
> double-clicking and you couldn't launch an executable this way. Better?
>
> Cheers,
> Mitja
>
> On Jul 8, 2011, at 9:10 PM, Dan Kaminsky  wrote:
>
>> And here's where your exploit stops being one:
>>
>> ===
>> Suppose the current version of Apple Safari (5.0.5) is our default web
>> browser. If we put the above files in the same directory (on a local
>> drive or a remote share) and double-click Test.html, what happens is
>> the following:
>> ===
>>
>> At this point, Test.html might actually be test.exe with the HTML icon
>> embedded.  Everything else then is unnecessary obfuscation -- code
>> execution was already possible the start by design.
>>
>> This is a neat vector though, and it's likely that with a bit more
>> work it could be turned into an actual RCE.
>>
>> On Fri, Jul 8, 2011 at 10:38 AM, ACROS Security Lists  wrote:
>>>
>>> We published a blog post on a nice twist to binary planting which we call 
>>> "File
>>> Planting." There'll be much more of this from us in the future, but here's 
>>> the first
>>> sample for you to (hopefully) enjoy.
>>>
>>> http://blog.acrossecurity.com/2011/07/binary-planting-goes-any-file-type.html
>>>
>>> or
>>>
>>> http://bit.ly/nXmRFD
>>>
>>>
>>> Best regards,
>>>
>>> Mitja Kolsek
>>> CEO&CTO
>>>
>>> ACROS, d.o.o.
>>> Makedonska ulica 113
>>> SI - 2000 Maribor, Slovenia
>>> tel: +386 2 3000 280
>>> fax: +386 2 3000 282
>>> web: http://www.acrossecurity.com
>>> blg: http://blog.acrossecurity.com
>>>
>>> ACROS Security: Finding Your Digital Vulnerabilities Before Others Do
>>>
>>>
>>> ___
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] COM Server-Based Binary Planting ProofOfConcept

[Dan Kaminsky]

Two things:

1) Are you sure a stock build of Windows doesn't pop a security
warning when right clicking the file:// IFRAME?  You might have munged
your test OS.
2) You're getting closer with this "Send To" stuff, but you're still
socially engineering.  Definitely better than classic "please download
and execute this file" though.

You really should stop talking about exploits against Powerpoint etc.
As long as I can make an .exe that visually looks pixel for pixel like
a .ppt, the security model you imagine (that the desktop can
differentiate between code execution and document editing) doesn't
exist.  This work is better, if incomplete.

On Thu, Jun 2, 2011 at 9:32 AM, Mitja Kolsek  wrote:
>
> Thor, the "Online Proof of Concept" section of the blog post points you to a 
> *remote*
> exploit (without any warning) but let me repeat the link here:
>
> http://www.binaryplanting.com/demo/XP_2-click/test.html
>
> Visit this with IE8 on 32-bit Windows XP.
>
> Please find further information here:
>
> http://blog.acrossecurity.com/2011/05/anatomy-of-com-server-based-binary.html
> http://blog.acrossecurity.com/2011/05/silently-pwning-protected-mode-ie9-and.html
>
> In general there are two types of remote binary planting exploits: SMB and 
> WebDAV.
> The former works inside (local) networks where firewalls block outbound SMB 
> traffic.
> WebDAV attacks work through firewalls too since many firewalls allow outbound 
> WebDAV
> traffic and Windows silently fall back to WebDAV if SMB doesn't work. If our 
> online
> remote exploit doesn't work for you, you can download the PoC locally and 
> test it in
> your local network.
>
> I'll be happy to explain it to you further if need be.
>
> Thanks,
> Mitja
>
>
>> -Original Message-
>> From: Thor (Hammer of God) [mailto:t...@hammerofgod.com]
>> Sent: Thursday, June 02, 2011 6:00 PM
>> To: secur...@acrossecurity.com; 'Dan Kaminsky'
>> Cc: full-disclosure@lists.grok.org.uk; bugt...@securityfocus.com
>> Subject: RE: [Full-disclosure] COM Server-Based Binary
>> Planting ProofOfConcept
>>
>> But it *is* worth mentioning that you have to create the
>> malicious dll file, copy it to the system, create folders
>> etc, and all the other mumbo jumbo to "exploit" this in the
>> "default configuration."   So, the answer to Dan's question
>> is actually, "no, you can't."  Which brings into question the
>> actual "worth" of mentioning this in the first place. :)
>>
>> t
>>
>> > -Original Message-
>> > From: full-disclosure-boun...@lists.grok.org.uk
>> > [mailto:full-disclosure- boun...@lists.grok.org.uk] On
>> Behalf Of ACROS
>> > Security Lists
>> > Sent: Thursday, June 02, 2011 8:42 AM
>> > To: 'Dan Kaminsky'; secur...@acrossecurity.com
>> > Cc: full-disclosure@lists.grok.org.uk; bugt...@securityfocus.com
>> > Subject: Re: [Full-disclosure] COM Server-Based Binary
>> Planting Proof
>> > OfConcept
>> >
>> > It would hardly be worth mentioning otherwise.
>> >
>> > Cheers,
>> > Mitja
>> >
>> > > -Original Message-
>> > > From: full-disclosure-boun...@lists.grok.org.uk
>> > > [mailto:full-disclosure-boun...@lists.grok.org.uk] On
>> Behalf Of Dan
>> > > Kaminsky
>> > > Sent: Thursday, June 02, 2011 5:36 PM
>> > > To: secur...@acrossecurity.com
>> > > Cc: si-c...@arnes.si; full-disclosure@lists.grok.org.uk;
>> > > bugt...@securityfocus.com; c...@cert.org
>> > > Subject: Re: [Full-disclosure] COM Server-Based Binary Planting
>> > > Proof OfConcept
>> > >
>> > > Does this run code without prompting, on a reasonably default
>> > > configuration?
>> > >
>> > > On Thu, Jun 2, 2011 at 7:52 AM, ACROS Security Lists
>> > > 
>> > > wrote:
>> > > >
>> > > > We published a remote/local proof of concept for the COM
>> > > Server-Based
>> > > > Binary Planting exploit presented at the Hack in the Box
>> > > conference in Amsterdam.
>> > > >
>> > > > Feel free to try it out online if WebDAV works through your
>> > > firewall,
>> > > > or download it and test it in your local network or simply
>> > > on your computer.
>> > > >
>> > > >
>> > >
>> http://blog.acrossecurity.com/2011/06/com-server-based-binary-planti

Re: [Full-disclosure] ZDI-11-168: Multiple Vendor librpc.dll Remote Information Disclosure Vulnerability

[Dan Kaminsky]

Don't most TCP/IP stacks block localhost addresses from coming in over the
network?

On Mon, May 16, 2011 at 12:44 PM, ZDI Disclosures <
zdi-disclosu...@tippingpoint.com> wrote:

> ZDI-11-168: Multiple Vendor librpc.dll Remote Information Disclosure
> Vulnerability
> http://www.zerodayinitiative.com/advisories/ZDI-11-168
> May 16, 2011
>
> -- CVE ID:
> CVE-2011-0321 & CVE-2011-1210
>
> -- CVSS:
> 9, (AV:N/AC:L/Au:N/C:P/I:P/A:C)
>
> -- Affected Vendors:
> IBM
> EMC
>
> -- Affected Products:
> IBM Informix
> EMC NetWorker
>
> -- TippingPoint(TM) IPS Customer Protection:
> TippingPoint IPS customers have been protected against this
> vulnerability by Digital Vaccine protection filter ID 52.
> For further product information on the TippingPoint IPS, visit:
>
>http://www.tippingpoint.com
>
> -- Vulnerability Details:
> This vulnerability allows remote attackers to register RPC services on
> vulnerable installations of EMC Legato Networker and IBM Informix
> Dynamic Server. Authentication is not required to exploit this
> vulnerability.
>
> The flaw exists within the librpc.dll component which listens by default
> on UDP port 111. When handling the pmap_set request the process verifies
> the source address is "127.0.0.1". This communication is via UDP and a
> valid source address is not required, a udp packet from source address
> "127.0.0.1" can be created sent to this service allowing a remote
> attacker to register and unregister RPC services. A remote attack can
> use this vulnerability to create a denial of service condition or
> eavesdrop on process communications.
>
> -- Vendor Response:
>
> EMC fix posted January 31, 2011:
> CVE-2011-0321
> http://archives.neohapsis.com/archives/bugtraq/2011-01/0162.html
>
> http://archives.neohapsis.com/archives/bugtraq/2011-01/att-0162/ESA-2011-003.txt
>
> IBM issued patch May 16, 2011:
> CVE-2011-1210
> 11.10 - http://www.ibm.com/support/docview.wss?uid=swg1IC76179
> 11.50 - http://www.ibm.com/support/docview.wss?uid=swg1IC76177
> 11.70 - http://www.ibm.com/support/docview.wss?uid=swg1IC76178
>
> -- Disclosure Timeline:
> 2010-11-15 - Vulnerability reported to vendor
> 2011-05-16 - Coordinated public release of advisory
>
> -- Credit:
> This vulnerability was discovered by:
>* Anonymous
>
> -- About the Zero Day Initiative (ZDI):
> Established by TippingPoint, The Zero Day Initiative (ZDI) represents
> a best-of-breed model for rewarding security researchers for responsibly
> disclosing discovered vulnerabilities.
>
> Researchers interested in getting paid for their security research
> through the ZDI can find more information and sign-up at:
>
>http://www.zerodayinitiative.com
>
> The ZDI is unique in how the acquired vulnerability information is
> used. TippingPoint does not re-sell the vulnerability details or any
> exploit code. Instead, upon notifying the affected product vendor,
> TippingPoint provides its customers with zero day protection through
> its intrusion prevention technology. Explicit details regarding the
> specifics of the vulnerability are not exposed to any parties until
> an official vendor patch is publicly available. Furthermore, with the
> altruistic aim of helping to secure a broader user base, TippingPoint
> provides this vulnerability information confidentially to security
> vendors (including competitors) who have a vulnerability protection or
> mitigation product.
>
> Our vulnerability disclosure policy is available online at:
>
>http://www.zerodayinitiative.com/advisories/disclosure_policy/
>
> Follow the ZDI on Twitter:
>
>http://twitter.com/thezdi
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Plumber Injection Attack in Bowser's Castle

[Dan Kaminsky]

Super Mario Brothers 2 is not vulnerable to this exploit, as it does not
ship with a Bowser.

It is possible to use the Plumber to inject Wart, but only during sleep(3).

On Fri, Apr 1, 2011 at 6:59 AM, Nelson Elhage  wrote:

> Advisory Name: Plumber Injection Attack in Bowser's Castle
>  Release Date: 2011-04-01
>  Application: Bowser's Castle
> Versions: Super Mario Bros., Super Mario Bros.: The Lost Levels
>   Identifier: SMB-1985-0001
> Advisory: http://blog.ksplice.com/2011/04/smb-1985-0001-advisory/
>
> ---
>
> Vulnerability Overview
> --
>
>  Multiple versions of Bowser's Castle are vulnerable to a plumber injection
>  attack. An Italian plumber could exploit this bug to bypass security
> measures
>  (walk through walls) in order to rescue Peach, to defeat Bowser, or for
>  unspecified other impact.
>
> Exploit
> ---
>
>  http://www.youtube.com/watch?v=rGshxZ1dYjA
>
>  This vulnerability is demonstrated by
>  "happylee-supermariobros,warped.fm2" [1]. Attacks using this
>  exploit have been observed in the wild, and multiple other exploits
>  are publicly available.
>
> Affected Versions
> -
>
>  Versions of Bowser's Castle as shipped in Super Mario Bros. [2] and Super
>  Mario Bros.: The Lost Levels [3] are affected.
>
> Solution
> 
>
>  http://www.youtube.com/watch?v=nacFU7ozeZA
>
>  An independently developed patch [4] is available.
>
>  A binary hot patch [5] to apply the update to an existing version is also
>  available.
>
>  All users are advised to upgrade.
>
> Mitigations
> ---
>
>  For users unable to apply the recommended fix, a number of
>  mitigations are possible to reduce the impact of the vulnerability.
>
>  NOTE THAT NO MITIGATION IS BELIEVED TO BE COMPLETELY EFFECTIVE.
>
>  Potential mitigations include:
>
>  - Employing standard defense-in-depth strategies incorporating
>multiple layers of defense, including Goombas [6], Koopa Troopas [7],
>Bullet Bills [8], and others.
>  - Installing poison mushrooms outside your castle [9].
>  - Installing a firewall to limit access to affected systems. [10]
>  - Frequently moving your princess between different castles [11].
>
> Credit
> --
>
>  The vulnerability was originally discovered by Mario and Luigi, of Mario
>  Bros. Security Research.
>
>  The provided patch and this advisory were prepared by Lakitu Cloud
>  Security, Inc. The hot patch was developed in collaboration with
>  Ksplice, Inc. [12]
>
> Product Overview
> 
>
>  Bowser's Castle is King Bowser's home and the base of operations
>  for the Koopa Troop. Bowser's Castle is the final defense against
>  assaults by Mario to kidnap Princess Peach, and is guarded by
>  Bowser's most powerful minions. [13]
>
> References
> --
>
>  [1] http://tasvideos.org/1715M.html
>  [2] http://en.wikipedia.org/wiki/Super_Mario_Bros.
>  [3] http://en.wikipedia.org/wiki/Super_Mario_Bros.:_The_Lost_Levels
>  [4]
> http://blog.ksplice.com/wp-content/uploads/2011/04/smb-1985-0001.patch
>  [5]
> http://blog.ksplice.com/wp-content/uploads/2011/04/patch-smb-1985-0001.sh
>  [6] http://www.mariowiki.com/Goomba
>  [7] http://www.mariowiki.com/Koopa_Troopa
>  [8] http://www.mariowiki.com/Bullet_Bill
>  [9] http://www.mariowiki.com/Firebar
>  [10]
> http://tvtropes.org/pmwiki/pmwiki.php/Main/YourPrincessIsInAnotherCastle
>  [11] http://www.mariowiki.com/Poison_Mushrooms
>  [12] http://www.ksplice.com/
>  [13] http://www.mariowiki.com/Bowser%27s_Castle
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Why should the presence of shebang (#!) freak out ANY security conscious guy?

[Dan Kaminsky]

It's change.  And change is scary.

(Seriously, nothing wrong with hashbang, except perhaps a slightly
increased risk of CSRF from people forgetting, yes, the web's broken
session management is still broken even with client side JS page
assembly.)

On Wed, Feb 23, 2011 at 2:51 PM, Security Conscious
 wrote:
> Could someone please have a look at these twitter posts:
> http://twitter.com/#!/achitnis/status/40444144992260096
> http://twitter.com/#!/achitnis/status/40447225658228736
> http://twitter.com/#!/achitnis/status/40450742326140928
> and explain why the presence of #! in URLs would freak out ANY security
> conscious guy?
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Amusing xss against some lexmark printers

[Dan Kaminsky]

> You can use nmap to set the RDYMSG of a printer and xss the printer
> web interface:
> nmap --script=pjl-ready-message.nse
> --script-args='pjl_ready_message="alert(1);"' . [0]
>
>
*chuckles*

What's the rendering engine?  WebKit?
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] how i stopped worrying and loved the backdoor

[Dan Kaminsky]

Sent from my iPhone

On Dec 25, 2010, at 2:38 PM, BMF  wrote:

> On Sat, Dec 25, 2010 at 2:12 PM,   wrote:
>> Check out Markus Jacobsson et al, "A Practical Secure Physical Random
>> Bit Generator", 1998, using the turbulence of airflow inside the drive
>> as the source of randomness. Can't do much better than that.
> 
> I read that when it came out. I am quite familiar with turbulent
> boundary layers. Nobody sells hardware (hard drives, in this case)
> which actually implements the technique. All of my original queries
> still stand.

Making noisy diodes isn't all that hard, AFAIK. You eliminate bias by only 
returning difference bits -- 01 is a 0, 10 is a 0. Whether the underlying 
silicon is in fact doing that...well, that's a question for the chip reversers. 

> 
> BMF
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] how i stopped worrying and loved the backdoor

[Dan Kaminsky]

On Fri, Dec 24, 2010 at 4:37 PM, BMF  wrote:

> On Fri, Dec 24, 2010 at 4:27 PM, coderman  wrote:
> >  how many of you have a competent userspace entropy
> > daemon funneling hardware sources into host pool?
>
> It would be nice if there were inexpensive hardware sources available
> and a means to distribute the entropy among hosts in one's own trusted
> infrastructure. I have a mail server, a name server, an ntp server
> (usually several), among various other sorts of pieces of
> infrastructure which serve hundreds or even thousands of servers. Why
> not an entropy server? It would be nice if I could setup an entropy
> generating black box somewhere and attach it via USB to my entropy
> server host then install a package with a config file on all of my
> machines pointing to the entropy host. But so far I know of no such
> thing. Do you?
>
>
Don't we have hardware RNG in most motherboard chipsets nowadays?

(Not that you should exclusively trust it, but the nature of RNG's is that
it's easy to mix in sources.)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] OpenBSD has Open Backdoored Software Distribution - admitted by Theo

[Dan Kaminsky]

On Wed, Dec 22, 2010 at 3:47 PM, Dave Nett  wrote:

> http://marc.info/?l=openbsd-tech&m=129296046123471&w=2
>
> Long mail which just admit has backdoor, poor Theo.
>


(g) I believe that NETSEC was probably contracted to write backdoors
as alleged.
(h) If those were written, I don't believe they made it into our
tree.  They might have been deployed as their own product.

You had only one more sentence to read!  Just one!
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Firefox Addon: KeyScrambler

[Dan Kaminsky]

Won't work against a hardware keylogger, as it gets the strokes before the 
driver does.

Won't work against any software aware of it; thread inject into Firefox to get 
the real keystrokes and it's game over.  Or heck, simply pretend to be a 
firefox process to get the decryption key, assuming it's not fixed.

Would work against some stock, mass distributed keyloggers, I suppose?

Sent from my iPhone

On Dec 8, 2010, at 3:12 AM, mrx  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Hi list,
> 
> Is anyone familiar with the firefox addon KeyScrambler? According to 
> developers this encrypts keystrokes.
> 
> Quote:
> "How KeyScrambler Works:
> When you type on your keyboard, the keys travel along a path within the 
> operating system before it arrives at your browser. Keyloggers plant
> themselves along this path and observe and record your keystrokes. The 
> collected information is then sent to the criminals who will use it to
> steal from you.
> 
> KeyScrambler defeats keyloggers by encrypting your keystrokes at the keyboard 
> driver level, deep within the operating system. When the encrypted
> keystrokes reach your browser, KeyScrambler then decrypts them so you see 
> exactly the keys you've typed. Keyloggers can only record the
> encrypted keys, which are completely indecipherable."
> 
> Can this be trusted? As in trusted I mean not bypassed.
> 
> Input from the professionals on this list would be much appreciated.
> 
> Thank you
> regards
> Dave
> 
> - -- 
> Mankind's systems are white sticks tapping walls.
> Thanks Roy
> http://www.propergander.org.uk
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.2 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEVAwUBTP9oJrIvn8UFHWSmAQIlVAf/T4zUGOaYiAoM/C+8ZFcMhDuOxOznvyXX
> IROHCr51aoQ6ShEIOhHLoQUaqLzZ4zrGirrnX5LFTJ0nmmr6cAG2raMiAi/BYnQb
> UnoXQkZ+9HnThkTSra59aRe8fRaG/MUlsG4lqWxvb0jGuZf2ekk83MPRlDCeXKWw
> CtMEB7YWRyay1kh6DdTAckXNMWXbfOoLAOh55ldmjhM7IN65EKW1rsQDN8Bdn3aX
> XyWWrRUTXDQfkI4mwXlVcGKuObPt8SAW1MgY8wP5q9qK8nAcGj/cig7URg4cVdYM
> Ss8/tryrPokTTGy2iSGjil3aQn21K5ANm6UYOSoNFodEq2SO0Hwyug==
> =nUTt
> -END PGP SIGNATURE-
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] verizon vs m$

[Dan Kaminsky]

On Tue, Dec 7, 2010 at 10:12 PM,   wrote:
> On Tue, 07 Dec 2010 07:16:34 EST, Larry Seltzer said:
>> >>> 2. some interpret it as a feature and some as a bug?
>>
>> > Does it have to be either?
>>
>> It sounds to me as if this is a deliberate design decision, and people are
>> disagreeing over the severity of its implications.
>
> Some people refer to that as a "feee-tchure" or "Broken As Designed". It's
> technically not a bug, but it does violate the Principle of Least Surprise.
>
>

To be fair, "Surprise!  Nothing works" would be a little more surprising.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] verizon vs m$

[Dan Kaminsky]

On Tue, Dec 7, 2010 at 6:02 PM, Georgi Guninski  wrote:
> do i get it right?:
>
> 1. the verizon paper is entirely correct

Well, sure.

> 2. some interpret it as a feature and some as a bug?

Does it have to be either?

>
> On Sun, Dec 05, 2010 at 11:25:36PM +0200, Georgi Guninski wrote:
>> in a world like this, verizon kills exploder bugs:
>>
>> http://www.theregister.co.uk/2010/12/03/protected_mode_bypass/
>> http://www.verizonbusiness.com/resources/whitepapers/wp_escapingmicrosoftprotectedmodeinternetexplorer_en_xg.pdf
>>
>> the language doesn't seem passionate:
>> -
>> Finally, Microsoft and other software vendors should clearly document which 
>> features do and do not
>> have associated security claims. Clearly stating which features make 
>> security claims, and which do not,
>> will allow informed decisions to be made on IT security issues.
>> -
>>
>> lol
>>
>> --
>> joro
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] verizon vs m$

[Dan Kaminsky]

> Did you read the Reg article?  It has nothing to do with the definition of a 
> "security boundary."  It's not about that at all.  It's about a title tease 
> of "bypassing protected mode" with associated inaccurate content when the 
> whole thing could be summarized with "Protected Mode is not enabled by 
> default in the Intranet zone."  The "boundary" conversation, while 
> interesting, is irrelevant here.
>
> I know times are tough and click-throughs on ads need to be maximized, but I 
> don't think misrepresentation of technical content is appropriate.  I can 
> understand why the Reg would write the article, but I asked Guninski if the 
> reason he posted it was because he considered Protected Mode being disabled 
> by default in the Intranet zone some sort of security issue.

Read the actual research.

===
One vector is through name squatting attacks in the user’s
“BaseNamedObjects” (BNO) kernel object
namespace. In this attack, an object with a fixed name can be created
which is then opened by an
application that trusts the object not to be malicious by virtue of it
existing in the local namespace
(which was previously a reasonable assumption). This issue has been
given as an example of why
Protected Mode is not a security boundary by Microsoft.

Another vector is through leaked or duplicated handles. Access control
decisions are made at the point
that an object is opened, so existing handles may provide access to
resources that are only accessible
to more privileged contexts if they are transferred between processes.
Handles in low integrity
processes which have write access rights to higher integrity objects
can be considered privileged.
It was through this vector that Skywing escaped from Protected Mode
using a leaked handle.

The last vector is through objects which are deliberately shared
between low integrity processes and
higher integrity processes. This includes the Window Station kernel
object which is shared between
all processes within the same interactive logon session. With full
access to the Window Station, low
integrity processes also have access to the Global Atom Table, Window
Station properties, the user’s
clipboard and the “\Default” Desktop object. Such objects can be
detected through a tool written as
part of this research that locates objects open in low and higher
integrity processes; to determine if two
handles refer to the same object, the kernel mode pointers to the
object’s data structure are compared.

The Global Atom Table is used to store both integers and strings which
are each indexed by an integer.
A simple fuzzer was created to fuzz this table, which only caused a
null pointer dereference in “Process
Explorer” and corruption of Internet Explorer UI elements. Dynamic
Data Exchange (DDE) inter-process
communication occurs through the Global Atom Table and this may be
subject to more interesting
attacks via malicious atom table manipulation.28 Internet Explorer
also uses the Global Atom Table
heavily, but it would seem mostly for User Interface related functionality.
===

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] verizon vs m$

[Dan Kaminsky]

> -
> Finally, Microsoft and other software vendors should clearly document which 
> features do and do not
> have associated security claims. Clearly stating which features make security 
> claims, and which do not,
> will allow informed decisions to be made on IT security issues.
> -

>From 2007:

http://www.networkworld.com/news/2007/021407-microsoft-uac-not-a-security.html

"Vista makes tradeoffs between security and convenience, and both UAC
and Protected Mode IE have design choices that required paths to be
opened in the IL wall for application compatibility and ease of use,"
he wrote.

Because the boundaries defined by UAC and Protected Mode IE are
designed to be porous, they can't really be considered security
barriers, he said. "Neither UAC elevations nor Protected Mode IE
define new Windows security boundaries," Russinovich wrote. "Because
elevations and ILs don’t define a security boundary, potential avenues
of attack, regardless of ease or scope, are not security bugs."

He said Microsoft had communicated this in the past, but that the
point needed reiterating.

(Note that Russinovich is properly cited in the Verizon Business
report -- just pointing out that this has come up before.)

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Evilgrade 2.0 - the update explotation framework is back

[Dan Kaminsky]

On Sat, Oct 30, 2010 at 8:02 AM,  wrote:

> On Sat, 30 Oct 2010 04:43:14 +0800, Jacky Jack said:
> > It's now a time for vendors to re-consider their updating scheme.
>
> And do what differently, exactly?
>

We really need autoupdate baked into the platform.

A) Laying in wait for some random to think "Wow, I should update iTunes" and
> hijack the process.
>
> B) Send out a few hundred thousand spam with a '
> From:upd...@apple-itunes-support.com
> '
> with a link to a site you control and feed the the sheep some malware.
>

Yeah, and C) I can take a rubber hose and choke you with it until you give
me the admin password.  That C works does not obviate A or B.

There are...side effects to C.

What you're not understanding is that many autoupdaters operate with zero
user interaction.  There is something to be said about silent ownage, simply
because you connected to a network.

Also, note that Evilgrade has been out for several years, and there are
still (many) vulnerable endpoints. This is the reality of design bugs --
they can survive the light of day, because they're such a miserable pain to
fix.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Security-Assessment.com Advisory: Oracle JRE - java.net.URLConnection class - Same-of-Origin (SOP) Policy Bypass

[Dan Kaminsky]

Sent from my iPhone

On Oct 20, 2010, at 8:58 AM, Michal Zalewski  wrote:

>> Security-Assessment.com follows responsible disclosure
>> and promptly contacted Oracle after discovering
>> the issue. Oracle was contacted on August 1,
>> 2010.
> 
> My understanding is that Stefano Di Paola of Minded Security reported
> this back in April; and further, the feature was a part of reasonably
> well-documented functionality of Java pretty much ever since:
> 
> http://download.oracle.com/javase/6/docs/api/java/net/URL.html
> 
> "Two hosts are considered equivalent if both host names can be
> resolved into the same IP addresses"
> 
> This was a pretty horrible design, so it's good to see it gone, though.

Eh, you can see where it came from though. Design bugs like this are absolutely 
miserable to fix (see how we'll never get rebinding out of the browser) and 
letting identical IP's script against eachother lets an awful lot of legitimate 
traffic through while blocking almost all attacks.

I'm not saying it's a preferred design, but let's reserve "horrible" for things 
that don't have quite the obvious thought process behind them.

Is this, in fact, gone now?

> 
> /mz
> 
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] ZDI-10-191: Adobe Reader ICC Parsing Remote Code Execution Vulnerability

[Dan Kaminsky]

>
> Well, awesome. This sounds near-identical to some issues that the Sun JRE
> had a few years back[1]. I wonder if the code shares a common lineage? :)
>
>
No common lineage required; ICC's filled with 32 bit element counts.
 They're always int overflow bait.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Tue, Sep 14, 2010 at 6:07 PM, Stefan Kanthak  wrote:
> Dan Kaminsky wrote:
>
>> h0h0h0.  There be history, Larry.
>>
>> Short version:  Go see how many DLLs exist outside of c:\windows\system32.
>> Look, ye mighty, and despair when you realize all those apps would be broken
>> by CWD DLL blocking.
>
> No, that's the too much shortened version.
> The correct version but is: Go see how many DLLs exist outside of the DLL
> search path.
> CWD DLL blocking does NOT break all those apps!
> Apps which install their DLLs into their own application directory won't
> notice CWD blocking at all.
>
> And apps which break can be easily fixed:
>
> [HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\application.exe]
> "Path"=...
>
> exists for more than 15 years now.
>
> Stefan
>
>

An automatic patch that breaks random apps will not be an automatic
patch -- and neither will the twenty patches after it.

Nobody cares that the breakage "can be fixed" with some fifteen year old key.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Firefox same-origin policy for fonts

[Dan Kaminsky]

The idea is the same as crossdomain.xml in flash -- content can
explicitly opt into being shared across domain boundaries.

Our real problem is that there's no way to know whether content is
generically available to the Internet, or just you because of IP
firewalling / cookies / whatnot.  So we have to default to blocking
all cross domain reads, since that other domain might be hosting your
email.

On Sun, Sep 12, 2010 at 7:43 PM,   wrote:
> One of my users asked me to install MathJax on my server.
> Reading installation instructions in
>  http://www.mathjax.org/resources/docs/?installation.html#notes-about-shared-installations
> I came across the following:
>
>  ... Firefox's same-origin security policy for cross-domain scripting.
>  Firefox's interpretation of the same-origin policy is more strict than
>    most other browsers, and it affects how fonts are loaded with the
>   �...@font-face CSS directive. ...
>  There is a solution to this, however, if you manage the server ...
>    create a file called .htaccess that contains the following lines: ...
>    Header set Access-Control-Allow-Origin "*"
>
> That would suggest that this same-origin policy can be defeated by
> settings on the "evil" server: the policy is not enforced, useless.
> Did I misunderstand something?
>
> (Does not really matter to me, am not planning on using that setting,
> but am wondering about Firefox workings.)
>
> Thanks,
>
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney    Australia
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Nmap NOT VULNERABLE to Windows DLL Hijacking Vulnerability

[Dan Kaminsky]

On Fri, Sep 10, 2010 at 11:46 AM, Nikhil Mittal
 wrote:
>
> >>Here's my definition
>
> >>Exploitable vulnerability = vulnerabilityn't t
> >>Non-exploitable "vulnerability" = mental masturbation
>
> Nice definition. I would like to add one more line for my definition
>
> Inability to recognize a straight forward vulnerability = mentally handicap

OK, lets go over this again.

Nikhil, Simple DLL Hijacking is quite possibly the least
straightforward potentially exploitable condition *of all time*.  We
may look back on this characteristic as the thing that finally proved
the legitimacy of Cross Site Scripting attacks -- compared to Simple
DLL Hijacking, XSS is practically a stack smash.  Simple DLL
Hijacking's problem is as follows:

a) The presumed preconditions for an attack are extensive and expensive
b) An attacker who met those preconditions, would not be stopped by
the proposed defenses

Regarding a, we're seeing lots of PDF 0-day floating around.  Why?
Because it's pretty cheap to get somebody to parse a PDF:   and you're done.  Getting someone to go through all the
steps with SDH?  Too complicated.

That being said, there are scenarios.  Matt @ AttackVector probably
found the best one right now -- a worm drops DLLs into a shared
document folder, and anyone who opens the docs gets hit.  And of
course, multiple people have figured out that SDH causes problems for
Autorun defenses, because a document read (not copied) directly off a
thumbdrive will presently launch code.

Even if you grant these are legitimate vectors, these are vectors
bouncing off Office's presumed type safety -- not WinImageView
3.4.8's.  And they're not even close to straightforward.

The core problem though is that Explorer itself doesn't strongly
enforce type safety.  I can't emphasize enough, you just don't have
enough context when you double click an item in a browser, that it's
not actually an .exe.  People keep pretending you do have this
context, and it's simply untrue.  Look at it this way:  If it was as
easy to execute arbitrary code from a web page, as it was from a
Explorer Shell Window to \\attacker.com\foo, we'd be up in arms.

So essentially, what you find is that the very concept of browsing
remote shares and USB sticks you don't trust, is unsafe.  This creates
the astonishing situation where Sharepoint becomes a security
technology!

You might notice that I keep referring to all this as Simple DLL
Hijacking.  It's likely that DLL Hijacking will actually be a critical
component of a genuine attack vector.  It's just not, yet.  The
journey of a thousand miles has been declared complete with a single
step.  So we're on the cusp of some huge portion of advisories coming
from the security community being little more than "random Windows app
runs DLLs from CWD".

Frankly, I think we can find better bugs.  I think we'd better.  Just
like bad money drives out good money, bad bugs drive out good bugs.
The credibility of advisories, and even the usefulness of FD, is
somewhat at risk.

--Dan

P.S.  Maybe there should be a new list -- full-disclosure-sdh -- for
this discussion?  I can't be the only one wondering how enormous this
thread has to get.  Yeah, yeah, I know.  I'm dreaming.

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] [GOATSE SECURITY] Clench: Goatse's way to say "screw you" to certificate authorities

[Dan Kaminsky]

Ah, a new password-authenticated DH.  At first glance, this is similar to
SRP (http://srp.stanford.edu/), but the server stores a plaintext password.


Initial thinking -- I'm not convinced that an offline brute force attack
won't work -- the nonce may break rainbow tabling, but it is transmitted via
unauthenticated DH (meaning, an attacker can see it with a mildly active
attack).

Thus the questions:

a) Can an attacker, able to see multiple instances of a client's g2b, g3b,
Pb and Qb, offline-brute-force them to verify the plaintext password?
b) Can an attacker, able to see multiple instances of a server's Pa, Qa and
Ra, offline-brute-force them to verify the plaintext password of an
arbitrary user?

Neither is possible in the present form-based HTTPS system, or SRP.

I'm not saying the above attacks will work.  There are a decent amount of
randomizers in here (both r and s are randomly selected, and never sent).
But the fact that you're saying "even if x-y could be extrapolated..." is
worrisome.

First, x==y, no?  So isn't x-y always 0?
Second, a MITM can clearly control the nonce (remember, at this point the
server pubkey isn't authenticated yet, and the server entirely controls the
nonce), so your statement that "a new nonce is built for every
authentication attempt, and  potentially meaningful data from (x – y) cannot
be generated without multiple attempts on the same shared secret value."
isn't accurate.

Also, multiple attempts on the same shared secret value...what's hard about
that?

Finally, this entire approach needs to stay out of the DOM.  It's not just a
client authentication protocol, it's a server authentication protocol,
meaning you can't trust the foreign UI until the password has authenticated
the content coming in.



On Wed, Sep 8, 2010 at 1:22 PM, Andrew Auernheimer wrote:

> Chris,
>
> The cryptographic primitives are long-standing and strong, and the
> source is open! Feel free to pick apart our proposed protocol
> specification!
>
> On Wed, Sep 8, 2010 at 12:15 PM, Christian Sciberras 
> wrote:
> > You're expecting us to trust YOU over the Government X?
> >
> > How do we know you're not working for the French Government (seeing
> > how you didn't list it in your conspiracy list)?
> >
> > I love jokes, but this is a bit too late for April's Fool.
> >
> > Cheers,
> > Chris.
> >
> >
> >
> > On Wed, Sep 8, 2010 at 6:59 PM, Tim 
> wrote:
> >>
> >> Hello Andrew,
> >>
> >>> un-tl;dr abstract: SSL is broken. Certificate authorities only exist
> >>> to let the US, Chinese, Turkish, Brazilian etc etc government or
> >>> Russian mob spy on you (whichever is interested first). Well, I guess
> >>> they also exist to line the pockets of assholes who want $10-50 for
> >>> pushing a button. Luckily, we’ve remedied this! We’ve established a
> >>> way that a client, using only standard password authentication, can
> >>> validate a server’s public key and ensure that no third party is
> >>> listening (without the use of a trusted third party such as a
> >>> certificate authority or manual fingerprint verification). Read on for
> >>> a wonderfully simple hack and proof of concept code!
> >>>
> >>> Biggest problem we solve: “Trusted” third parties can’t be trusted and
> >>> criminals or hostile governments are free to launch man in the middle
> >>> attacks. Extensive research in this area has been done by by
> >>> Marlinspike, Dan Kaminsky and Mike Zusman which you really should
> >>> read.
> >> ...
> >>> The whole PKI architecture is broken and cannot be safely relied upon.
> >>> Any system of authentication which relies on a “trusted” third party
> >>> that you have no dominion over is flawed. DNSSEC is only an
> >>> incremental improvement with the same underlying flaw– I may trust the
> >>> ICANN, ISC, NIST, NTIA, the Department of Homeland Security, or
> >>> VeriSign more than the combined ineptitude and maliciousness of every
> >>> current SSL CA, but I still don’t trust them. The whole idea of a
> >>> trust anchor is fallacious.
> >>
> >> I agree with you, the currently used SSL/TLS PKI is fragile and
> >> subvertible.  SSL/TLS itself isn't so bad (less a renegotiation flaw).
> >>
> >>
> >>> We set out to solve this problem in a way that can reconcile three
> >>> realities of security:
> >>>
> >>> * Users cannot effectively comprehend anything but password
> >

Re: [Full-disclosure] KeePass version 2.12 <= Insecure DLL Hijacking Vulnerability (dwmapi.dll)

[Dan Kaminsky]

excuse me, kdbx.  same difference


On Tue, Sep 7, 2010 at 2:23 AM, Dan Kaminsky  wrote:

> So, what's the security model around .ygwx files?
>
>
> On Tue, Sep 7, 2010 at 1:57 AM, YGN Ethical Hacker Group 
> wrote:
>
>> The fixed version KeePass 2.13 has been released.
>>
>> http://keepass.info/news/n100906_2.13.html
>>
>> But failure to describe "DLL Hijacking was fixed".
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] KeePass version 2.12 <= Insecure DLL Hijacking Vulnerability (dwmapi.dll)

[Dan Kaminsky]

So, what's the security model around .ygwx files?

On Tue, Sep 7, 2010 at 1:57 AM, YGN Ethical Hacker Group wrote:

> The fixed version KeePass 2.13 has been released.
>
> http://keepass.info/news/n100906_2.13.html
>
> But failure to describe "DLL Hijacking was fixed".
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 31, 2010, at 6:49 PM, paul.sz...@sydney.edu.au wrote:

> Dan Kaminsky  wrote:
>
>> iexplore.exe has a security model. Explorer.exe doesn't ...
>
> Very dim view. So, there is no way for a Windows user to access his
> "desktop", e.g. any data on a CD or USB stick, in a safe way? Seems so
> wasteful for MS to try and plug autorun viruses, then...
>
> Thankfully, you are wrong. All decent OSs have some security. (Some  
> are
> more decent than others.)
>

Ok. Which desktop shell doesn't behave just like explorer?

More instructively -- what would a secure desktop look like?


> Cheers, Paul
>
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney 
> Australia

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 31, 2010, at 4:11 PM, paul.sz...@sydney.edu.au wrote:

> valdis.kletni...@vt.edu wrote:
>
>>> ... The victim is attempting to view a plain text file. Surely
>>> that can be done safely?
>>
>> Only if your OS's security model understands the fact that executable
>> code and data belong in different security domains and thus different
>> rules should apply about what files to "trust" in each category.
>
> Hmm... an OS that cannot "view" plain-text in a safe manner...
> Shame on those who would call that an OS.
>
> Yes, even the Windows security model understands those things.

Notepad.exe can launch from iexplore.exe in some contexts; this open  
is safe (and when it isn't, it's Critical).

Notepad.exe can launch from Explorer.exe in some contexts, this open  
is not safe.

iexplore.exe has a security model. Explorer.exe doesn't (outside of  
standard user). That's the reality, shared by all the desktops.



>
> Cheers, Paul
>
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney 
> Australia
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 31, 2010, at 4:08 PM, paul.sz...@sydney.edu.au wrote:

> Dan Kaminsky  wrote:
>
>>> I can differentiate my coolProposal.doc from msword.exe just fine..
>>
>> Uh huh. Here, let me go ahead and create 2010 Quarterly
>> Numbers.ppt.exe with a changed icon, and see what you notice.
>
> So you (Dan) can differentiate. Why couldn't other do the same?

It's not that they can't. It's that they don't, and we have huge  
amounts of data confirming this. Have you never been to a Moxie  
Marlinspike talk?  His success rates on SSL Stripping a tor node were  
100%. 100%!!!

> Do you honestly think you are so much smarter than anyone else?
>

It's not about intelligence, it's about what you and I care about. For  
example, I don't care about how cars work. I want to put my key in the  
ignition and go.

There's only so much anyone really cares about. Outside of our little  
club here, people want the computer to just work.



> Cheers, Paul
>
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney 
> Australia

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 31, 2010, at 2:20 PM, Charles Morris  wrote:

> On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky  wrote:
>
>>
>> Again, the clicker can't differentiate word (the document) from  
>> word (the
>> executable).  The clicker also can't differentiate word (the  
>> document) from
>> word (the code equivalent script).
>>
>> The security model people keep presuming exists, doesn't.
>>
>> Even the situation whereby a dll is dropped into a directory of  
>> documents --
>> the closest to a real exploit path there is -- all those docs can be
>> repacked into executables.
>>
>
> What?
>
> I can differentiate my coolProposal.doc from msword.exe just fine..
>

Uh huh. Here, let me go ahead and create 2010 Quarterly  
Numbers.ppt.exe with a changed icon, and see what you notice.


> If your statement is that the windows defaults should be changed,
> including the "hide extensions" default, then I wholeheartedly agree
> as I detailed in my first post. It's the first thing I turn off.
>
> Many people who think the same way have considered that a
> vulnerability in windows for years, I wouldn't consider it part of
> the "DLL Hijacking" fiasco.

Imagine if the browser lock meant arbitrary code could run.

I find your faith in small collections of pixels hilarious.

>
> Cheers,
> Charles

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 31, 2010, at 2:01 PM, Charles Morris  wrote:

>>
>>> ... Don't run applications from untrusted locations ...
>>
>> You got it wrong. Only trusted applications are run. - The attacker
>> prepares a WORD.DOC (and a RICHED20.DLL) file in some place. The
>> victim clicks on the WORD.DOC file, using his own installed MSWord.
>>
>
> Aaah, well if that is the issue, it seems to me that the  
> vulnerability here is
> that the application in question (MSWord) has it's CWD set to the  
> directory of
> the file that it is opening through the explorer shell.
>
> It should chdir() to it's own parent directory before doing anything  
> interesting
> that depends on CWD. (i.e. loading DLLs or executing "./ 
> amazingApp.sh")
>
> It's general good programming practice to be mindful of your CWD, I  
> know
> that personally; a call to chdir() is almost always at the top of my  
> script.
>
> So, I take back what I said about it being a non-issue, it IS in fact
> a vulnerability in the application.
>

Again, the clicker can't differentiate word (the document) from word  
(the executable).  The clicker also can't differentiate word (the  
document) from word (the code equivalent script).

The security model people keep presuming exists, doesn't.

Even the situation whereby a dll is dropped into a directory of  
documents -- the closest to a real exploit path there is -- all those  
docs can be repacked into executables.

> Cheers,
> Charles
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Mon, Aug 30, 2010 at 11:45 AM, Pavel Kankovsky <
p...@argo.troja.mff.cuni.cz> wrote:

> On Thu, 26 Aug 2010, Dan Kaminsky wrote:
>
> > The question is whether they're supposed to execute code in this
> > particular context.
>
> I think the question ought to be: what authority and privileges shall be
> granted to the code when it is executed?
>

Yeah, and the thing about all of the desktop shells (Explorer, Finder, etc)
is that they're all just as happy to open a Word Document with winword.exe,
as they are to open winword.exe (or something else with that name) itself.
In other words, the security model is that authority and privileges are the
expansive set that is full code execution as that user.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

...up till the moment you realize that the interface doesn't really
differentiate between "2010 Quarterly Projections" as an .exe or as a .ppt.
Double clicking in desktop = do whatever it takes to run this, code
execution or not.

On Fri, Aug 27, 2010 at 10:36 AM, Christian Sciberras wrote:

> "while there's probably an actual vuln somewhere using this
> methodology, nothing's been found yet"
>
>
> Do you really think so?
>
> Having any kind of executable load the first ntoskernel.dll it finds,
> such as the innocent one in it's own directory isn't really wise...
>
>
>
>
>
>
> On Fri, Aug 27, 2010 at 4:19 PM, Dan Kaminsky  wrote:
> > Well, if I pull out the crystal ball, I see two possibilities:
> >
> > 1) Patch goes out, implementing this policy
> > 2) 1% of customers go dark
> > 3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE
> >
> > 1) Patch goes out, off by default
> > 2) 0% of customers turn it on
> > 3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO
> WRITE
> >
> > Neither look exactly appetizing, and it's not like we (yet) have a clear
> > vulnerability that needs to be addressed.
> >
> > On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer 
> > wrote:
> >>
> >> #1 in the DLL search list is the directory from which the program was
> >> loaded. How can you have a scenario where CWD is a better choice than
> that?
> >> Why would it be a good choice DLL sharing?
> >>
> >>
> >>
> >> Here’s another possibility for a Microsoft action. Add a search location
> >> 1.5 specified by the application to Windows. If all the Office apps are
> >> sharing DLLs they can put their apps in Office/sharedDLLs and point to
> it.
> >> At least we could move forward from here. Microsoft’s choice here dooms
> us
> >> to this problem for the forseeable future.
> >>
> >>
> >>
> >> From: Dan Kaminsky [mailto:d...@doxpara.com]
> >> Sent: Friday, August 27, 2010 10:08 AM
> >> To: Larry Seltzer
> >> Cc: valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk
> >> Subject: Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
> >>
> >>
> >>
> >> h0h0h0.  There be history, Larry.
> >>
> >> Short version:  Go see how many DLLs exist outside of
> >> c:\windows\system32.  Look, ye mighty, and despair when you realize all
> >> those apps would be broken by CWD DLL blocking.
> >>
> >> Longer version:
> >>
> >> Unix has always had the tradition of a system administrator.  When it
> went
> >> consumer, it went straight to package management -- something it could
> do,
> >> because a) there just aren't that many apps and b) they're mostly open
> >> source, so distros can legally fix things up.
> >>
> >> Windows comes from a different direction:  Many, many consumer facing
> >> apps, very few of them open source, users installing for themselves, no
> >> package manager.  Among other things, this introduces the concept of:
> >>
> >> Which DLLs should you load?
> >>
> >> Suppose you have ten applications, each using foo.dll.  Should they all
> >> use foo.dll from c:\windows\system32?  Maybe, maybe not.  There are many
> >> possible versions that might be in there, and they might or might not
> work.
> >>
> >> You can push your version of foo.dll into c:\windows\system32.  Great,
> >> you'll work fine, but there's nine other apps you might break.
> >>
> >> You can use a local foo.dll.  Now you can have your lib and they can
> have
> >> theirs.
> >>
> >> Welcome to DLL hell.
> >>
> >> There's been a lot of work in fixing this situation, but not from the
> >> security perspective.  I know we're masters of righteous indignation,
> but I
> >> have to emphasize -- while there's probably an actual vuln somewhere
> using
> >> this methodology, nothing's been found yet.  Changing something with
> only a
> >> tenuous link to security, with such a massive impact on whether
> applications
> >> run or not?  Yeah, not exactly surprised it's still there.
> >>
> >> On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer 
> >> wrote:
> >>
> >> Clearly desktops need to be able to run arbitrary code. That’s what
&g

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

h0h0h0.  There be history, Larry.

Short version:  Go see how many DLLs exist outside of c:\windows\system32.
Look, ye mighty, and despair when you realize all those apps would be broken
by CWD DLL blocking.

Longer version:

Unix has always had the tradition of a system administrator.  When it went
consumer, it went straight to package management -- something it could do,
because a) there just aren't that many apps and b) they're mostly open
source, so distros can legally fix things up.

Windows comes from a different direction:  Many, many consumer facing apps,
very few of them open source, users installing for themselves, no package
manager.  Among other things, this introduces the concept of:

Which DLLs should you load?

Suppose you have ten applications, each using foo.dll.  Should they all use
foo.dll from c:\windows\system32?  Maybe, maybe not.  There are many
possible versions that might be in there, and they might or might not work.

You can push your version of foo.dll into c:\windows\system32.  Great,
you'll work fine, but there's nine other apps you might break.

You can use a local foo.dll.  Now you can have your lib and they can have
theirs.

Welcome to DLL hell.

There's been a lot of work in fixing this situation, but not from the
security perspective.  I know we're masters of righteous indignation, but I
have to emphasize -- while there's probably an actual vuln somewhere using
this methodology, nothing's been found yet.  Changing something with only a
tenuous link to security, with such a massive impact on whether applications
run or not?  Yeah, not exactly surprised it's still there.


On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer wrote:

>  Clearly desktops need to be able to run arbitrary code. That’s what
> they’re there for.
>
>
>
> Why wouldn’t eliminating the CWD from the DLL search order fix the problem?
> I asked Microsoft about this (
> http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php)
> and they said the obvious answer, that it would break too many customer
> installations. And I guess it would break a bunch of them, but there really
> isn’t a good reason for anyone to load a DLL from the CWD, is there?
>
>
>
> I think they dropped the ball on this at Vista time. They made so many
> other changes for security reasons then that forced users and developers to
> change practice that this one wouldn’t have been such a big stink. And
> they’ve known about the basic problem for 10 years (and should have known
> earlier, since it was a UNIX attack beforehand).
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

Well, if I pull out the crystal ball, I see two possibilities:

1) Patch goes out, implementing this policy
2) 1% of customers go dark
3) That's a WHOLE BUNCH OF CUSTOMERS WHO DISABLE WINDOWS UPDATE

1) Patch goes out, off by default
2) 0% of customers turn it on
3) That's a MEANINGLESS REGISTRY ENTRY THAT COST A BUNCH OF MONEY TO WRITE

Neither look exactly appetizing, and it's not like we (yet) have a clear
vulnerability that needs to be addressed.

On Fri, Aug 27, 2010 at 10:14 AM, Larry Seltzer wrote:

>  #1 in the DLL search list is the directory from which the program was
> loaded. How can you have a scenario where CWD is a better choice than that?
> Why would it be a good choice DLL sharing?
>
>
>
> Here’s another possibility for a Microsoft action. Add a search location
> 1.5 specified by the application to Windows. If all the Office apps are
> sharing DLLs they can put their apps in Office/sharedDLLs and point to it.
> At least we could move forward from here. Microsoft’s choice here dooms us
> to this problem for the forseeable future.
>
>
>
> *From:* Dan Kaminsky [mailto:d...@doxpara.com]
> *Sent:* Friday, August 27, 2010 10:08 AM
> *To:* Larry Seltzer
> *Cc:* valdis.kletni...@vt.edu; full-disclosure@lists.grok.org.uk
>
> *Subject:* Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
>
>
>
> h0h0h0.  There be history, Larry.
>
>
> Short version:  Go see how many DLLs exist outside of c:\windows\system32.
> Look, ye mighty, and despair when you realize all those apps would be broken
> by CWD DLL blocking.
>
> Longer version:
>
> Unix has always had the tradition of a system administrator.  When it went
> consumer, it went straight to package management -- something it could do,
> because a) there just aren't that many apps and b) they're mostly open
> source, so distros can legally fix things up.
>
> Windows comes from a different direction:  Many, many consumer facing apps,
> very few of them open source, users installing for themselves, no package
> manager.  Among other things, this introduces the concept of:
>
> Which DLLs should you load?
>
> Suppose you have ten applications, each using foo.dll.  Should they all use
> foo.dll from c:\windows\system32?  Maybe, maybe not.  There are many
> possible versions that might be in there, and they might or might not work.
>
> You can push your version of foo.dll into c:\windows\system32.  Great,
> you'll work fine, but there's nine other apps you might break.
>
> You can use a local foo.dll.  Now you can have your lib and they can have
> theirs.
>
> Welcome to DLL hell.
>
> There's been a lot of work in fixing this situation, but not from the
> security perspective.  I know we're masters of righteous indignation, but I
> have to emphasize -- while there's probably an actual vuln somewhere using
> this methodology, nothing's been found yet.  Changing something with only a
> tenuous link to security, with such a massive impact on whether applications
> run or not?  Yeah, not exactly surprised it's still there.
>
>  On Fri, Aug 27, 2010 at 7:20 AM, Larry Seltzer 
> wrote:
>
> Clearly desktops need to be able to run arbitrary code. That’s what they’re
> there for.
>
>
>
> Why wouldn’t eliminating the CWD from the DLL search order fix the problem?
> I asked Microsoft about this (
> http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php)
> and they said the obvious answer, that it would break too many customer
> installations. And I guess it would break a bunch of them, but there really
> isn’t a good reason for anyone to load a DLL from the CWD, is there?
>
>
>
> I think they dropped the ball on this at Vista time. They made so many
> other changes for security reasons then that forced users and developers to
> change practice that this one wouldn’t have been such a big stink. And
> they’ve known about the basic problem for 10 years (and should have known
> earlier, since it was a UNIX attack beforehand).
>
>
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Fri, Aug 27, 2010 at 9:10 AM,  wrote:

> On Fri, 27 Aug 2010 07:20:22 EDT, Larry Seltzer said:
>
> > Why wouldn't eliminating the CWD from the DLL search order fix the
> problem?
> > I asked Microsoft about this (
> >
> http://blogs.pcmag.com/securitywatch/2010/08/list_of_dll_vulnerability_wind.php
> )
> > and they said the obvious answer, that it would break too many customer
> > installations. And I guess it would break a bunch of them, but there
> really
> > isn't a good reason for anyone to load a DLL from the CWD, is there?
>
> The mentality that "Our program only works with version 1.14 of the DLL so
> we'll ship a copy of it in the directory" is too entrenched.  That's why
> you'll
> see a box that has 4 or 5 different copies of the Java RTE on it.  Of
> course,
> on a *sane* system you'd use a variable like LD_LIBRARY_PATH to say where
> to
> find the libraries (and maybe apply some W^X exclusion to path components).
> But there's just too many 3rd party packages that would have to be updated
> to
> make it palatable.
>

As opposed to other platforms that, what, don't have 3rd party packages?  :)


>
> Remember - Microsoft doesn't have any real committment to deliver a truly
> secure system to you. It has a committment to deliver just enough security
> and other features so it can deliver dollars to its shareholders.  We all
> *know*
> what it would take to secure it - and it won't happen because the resulting
> paradidm shits will torpedo sales.
>

Oh, come on.  MS puts more effort into delivering a secure platform than
pretty much anyone at this point.  They're just not the low hanging fruit
they once were.

The difference between attack and defense is that we know when attack
doesn't work.  Unrolling this one characteristic pretty much yields security
as it stands today.  It's why attack research is so important -- it's our
only source of ground truth!
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Fri, Aug 27, 2010 at 1:51 AM,  wrote:

> On Fri, 27 Aug 2010 01:29:32 EDT, Dan Kaminsky said:
>
> > Again, let me emphasize.  Really interesting vector, will probably end up
> > attached to an unambiguous flaw.  But right now, we're just seeing flaws
> > along the lines of "Double clicking an icon in Explorer might execute
> > arbitrary code".  It doesn't matter that that's true even if there's a
> > network share, or a USB stick.  That's what Explorer *does*.
>
> And as I said, a fix that starts off with "First thing we do is feed
> Explorer
> to a pack of hungry dingos" won't fly with Joe Sixpack. ;)
>

Eh, no sense being so specific.  I'm sure the same sort of type confusion
tricks are possible in Finder, GNOME, KDE, etc.  Desktops run arbitrary
code.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Fri, Aug 27, 2010 at 1:05 AM,  wrote:

> On Thu, 26 Aug 2010 20:39:04 PDT, Dan Kaminsky said:
>
> > There may very well be a legitimate boundary cross from this DLL
> > stuff, but we haven't seen it yet. All the present stuff has the
> > indelible mark of a false boundary, in that no fix can be imagined
> > that actually closes the vector.
>
> Oh you're wrong there Dan.  I can imagine fixes that would close the
> vector (starting with fixes that impose a legitimate enforcable boundary).
>
> Fixes that will be accepted by Joe Sixpack? I think we saw where UAC ended
> up. :)
>

Hehe.  You start with the beginnings of imagining a fix.  Here, you say 'the
desktop will be aware of when it is launching content safe for viewing, vs.
dangerous, and will behave differently'.  Eventually you realize:

1) You have to build this database
2) You have to maintain this database, even in the face of third party apps
adding handlers
3) You have to determine what the differential behavior is going to be on a
safe vs. unsafe type

And it's in the middle of 3) that you end up...well...where UAC ended up :)

Again, let me emphasize.  Really interesting vector, will probably end up
attached to an unambiguous flaw.  But right now, we're just seeing flaws
along the lines of "Double clicking an icon in Explorer might execute
arbitrary code".  It doesn't matter that that's true even if there's a
network share, or a USB stick.  That's what Explorer *does*.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Fri, Aug 27, 2010 at 1:06 AM,  wrote:

> Dan Kaminsky  wrote:
>
> >> Badly setup desktops: do not "hide extensions", maybe view details
> >> (or list) not icons.
> >
> > All that matters is defaults, and icons are way more powerful ...
>
> Those defaults are wrong, change them. Anyway, icons are shown
> with "view details".
>

I think you mean application types are shown with "view details".  The
problem is, there's a couple dozen application types that are all code
execution equivalent by design.  Do you know all of them?  Why should a
user?



>
> > The web browser and the email client are not designed to launch
> > arbitrary code. The desktop ... is.
>
> This attack may happen through the browser (UNC paths or somesuch).
> Any talk about USB sticks or desktops is bogus.
>
>
There's no path between IE and a UNC window that doesn't either security
prompt or raise an unadorned Explorer window to a remote share.  I could see
an argument that the latter should prompt, given that it's a (by definition)
code execution context.  But that's about it.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 26, 2010, at 9:30 PM, paul.sz...@sydney.edu.au wrote:

> Dan Kaminsky  wrote:
>
>>>> Instead of it executing "wab.exe (Windows Address Book) and open  
>>>> the
>>>> file test.vcf", one can directly get any .exe file open.
>>>
>>> Users have shown themselves very willing to open up test.vcf.exe.
>>
>> Or for that matter, test, which is actually an exe with the icon of a
>> vcf.  Thus the problem with all this chortling about foolish
>> applications:  the desktop simply does not possess the security model
>> of the browser or the email client.
>
> Badly setup desktops: do not "hide extensions", maybe view details (or
> list) not icons.


All that matters is defaults, and icons are way more powerful signals  
than a couple of letters at the end of "2010 Market  
Projections.ppt.exe' anyway.

The web browser and the email client are not designed to launch  
arbitrary code. The desktop, with the slight caveat of Standard User  
vs. Administrator, simply is.

> Cheers, Paul
>
> Paul Szabo   p...@maths.usyd.edu.au   http://www.maths.usyd.edu.au/u/psz/
> School of Mathematics and Statistics   University of Sydney 
> Australia

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Aug 26, 2010, at 7:53 PM, Larry Seltzer   
wrote:

>> Instead of it executing "wab.exe (Windows Address Book) and open the
>> file test.vcf", one can directly get any .exe file open.
>
> Users have shown themselves very willing to open up test.vcf.exe.
>

Or for that matter, test, which is actually an exe with the icon of a  
vcf.  Thus the problem with all this chortling about foolish  
applications:  the desktop simply does not possess the security model  
of the browser or the email client.

There may very well be a legitimate boundary cross from this DLL  
stuff, but we haven't seen it yet. All the present stuff has the  
indelible mark of a false boundary, in that no fix can be imagined  
that actually closes the vector.

> LJS
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive

[Dan Kaminsky]

On Thu, Aug 26, 2010 at 3:53 PM, matt  wrote:

> Hey guys..
>
> Here's an example the DLL hijacking attack using a USB drive with autorun.
>  I haven't seen this done yet, so I figured I'd post it.
>
> http://www.attackvector.org/autorun-dll-hijacker-usb-stick/
>
>
Sure, but you have the same problem most of the other DLL hijacking exploits
have:

There's no security boundary that says that what appears to be a .ppt,
actually is one.  The attacker controls both the icon and the filename.
That's the case from a network share, that's the case from a USB mount,
that's just the way it is.

Here's the larger picture:

These are unusually interesting findings.  On the one hand, you have
arbitrary code execution, generally the gold standard for vulnerability.  On
the other hand, operating systems *by definition* execute arbitrary code
The question is whether they're supposed to execute code in this particular
context.

The answer is not actually obvious.

The specific boundary at play seems to be the document boundary.  There are
very popular file formats that we'd like to be able to read and view,
without running any embedded code inside -- powerpoint files, for instance.
In the proposed scenario, the user has double clicked a file from a remote
share.

Calc pops up.  Clearly a vuln, right?

Here's the problem:  How could this boundary ever be maintained?  The user
has no actual way of knowing that the file he's clicking on is, in fact, a
PowerPoint document in the first place.  It could just as easily be a .exe,
faking its icon.  And every major operating system has been hiding file
extensions for years.

Worse, even if extension weren't hidden, its not like applications have any
sort of "safety contract" when executed from the desktop.  Some formats have
very clear mandates, inherited from being trafficked via email.  Others are
outright scripting languages and are fundamentally designed to execute
arbitrary code.

The web has developed a very clear security model:  If you can parse it zero
click from a web site, it's required to stay within the browser sandbox.
The desktop has no such model -- some formats are 'safe', others aren't.

There was some talk about whether PSD was "vulnerable" to this flaw.  The
complexity comes from the fact that, for all we know, opening a PSD file
executes arbitrary scripts by design.  Why shouldn't it?  Not everything is
a web browser.

So, it's not that this is a weak bug or a massive bug.  It's a
characteristic, that has managed to make the otherwise unambiguous proof of
concept -- popping calc -- ambiguously problematic.  That's actually
impressive, if a bit meta.

We'll probably see some unambiguous attacks pop up, but they haven't yet.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

On 7/25/2010 4:59 PM, Pavel Kankovsky wrote:
> On Sat, 24 Jul 2010, Dan Kaminsky wrote:
> 
>> And what do you think is doing revocation checking?
>> Hint:  Even fewer things than are doing chain validation.
> 
> So... no one is doing revocation checking and expiration is evil.
> How are we supposed to get rid of invalid certificates?

Ask me that in a few days ;)

>> The problem is that we assume that security doesn't have to be convenient.
> 
> Let me paraphrase one famous sentence: security should be made as
> convenient as possible but not more convenient.

This is a great formulation, actually.

>> Intermediate certs?  You mean those god-mode can-sign-anything certs
>> that are sold for a pile of money, a wink, and a smile?
> 
> No. See RFC 3280 Internet X.509 Public Key Infrastructure, section
> 4.2.1.11 Name Constraints. Any PKIX-compliant application must recognize
> this extension.

So nobody will sell you a name constrained certificate.  It's almost
like there are serious implementation issues with the extension in the
field.

>> Everyone loves blaming the business guys.  Nope.  When it comes to
>> X.509, we nerds blew it.
> 
> "We blew" it in the sense that X.509 is designed for a strictly
> hierarchical bureaucratic environment, not for an open world where
> commercial CAs are supposed to compete within a shared namespace.

Absolutely correct.  Whatever world X.509 is great for, it sure ain't
this one.

> yet it allows large-scale deployment of patches without any meetings,
> planning, testing, and validation? You must be kidding.

Patch management involves the same thing being put on different hosts,
and there's really no choice -- you can't run an infrastructure without
maintaining it, on some timescale anyway.

Certificate management involves different things being put on different
hosts, and there's totally a choice -- you can simply not have a
certificate at all.

There's definitely some overlap.  But remember, in the field, the data
is not subtle:  Certificates are deployed through gritted teeth.

> You should decide whether you want to blame X.509 itself or a 
> particular way it is used.

To paraphrase another quote, "X.509 never fails, only X.509 deployers."

The funny thing is, I've met a decent number of the actual authors of
X.509.  They're uniformly brilliant.  Maybe it's like that old Star Trek
pilot...super advanced aliens heal humans who've crash landed on their
planet, but they didn't exactly have a guide to what they were supposed
to do...

> 
>> Expiration is one of a number of serious and genuinely unique
>> operational hazards in X.509.
> 
> When you fail to pay your electric bill every month, they will cut
> your power supply. All your computers will stop working. Is it a 
> "genuinely unique operational hazard" too? ;)

You know, it's strange.  I never hear stories about networks being taken
down for nonpayment of electric bills, but we have straight up UI
support for certificate errors.  Why do you think that is?

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

> Unfortunately, this approach (while being quite feasible from the
>> technical POV) appears to be incompatible with the business model of
>> existing CAs.
>>
>
> Everyone loves blaming the business guys.  Nope.  When it comes to X.509,
> we nerds blew it.If you have got 500 servers that need renewed certificates
> then you have.
>
> ...(alot of work ahead of you.)
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

> People may neglect to revoke certificates that have become invalid (e.g.
> a personal certificate for someone who has deceased).
>

And what do you think is doing revocation checking?

Hint:  Even fewer things than are doing chain validation.

The problem is a conflict between security and convenience.
>

The problem is that we assume that security doesn't have to be convenient.


>
> Ironically, online communication allows a rather elegant solution: you can
> have a hierarchy of certificates starting with short-lived certs for
> routine operation issued online by the lowest level of intermediate CAs
> with each level offering less automation to reduce exposure and longer
> lifetimes to make up for lost convenience.
>

Intermediate certs?  You mean those god-mode can-sign-anything certs that
are sold for a pile of money, a wink, and a smile?


>
> Unfortunately, this approach (while being quite feasible from the
> technical POV) appears to be incompatible with the business model of
> existing CAs.
>

Everyone loves blaming the business guys.  Nope.  When it comes to X.509, we
nerds blew it.If you have got 500 servers that need renewed certificates
then you have.

got 500 server that need patches installed, not to mention other routine
> admin tasks. If you need 8 man hours per server to renew one certificate,
> how many man hours per server do you need to deploy one patch?
>

Windows Update / BigFix, move on with your life.


Many (if not most) CAs let you renew a certificate two or three months
> before its expiration and give you the remaining time back. One who needs
> to renew one certificate every other day can do it once in 2 or 3 months
> in batches of up to 30 or 45 renewals without losing anything.
>

Or, you could just have a small handful of servers with keys and leave the
rest without.  Which is precisely what we see.

See, here's the problem:  You're all talking about what *could* be the
case.  I'm telling what *is* the case.  Expiration is one of a number of
serious and genuinely unique operational hazards in X.509.  We started this
conversation discussing the situation of a CA gov operator who hadn't rolled
their certs.  Some people were surprised.

The reality is, it's amazing there was a cert at all.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

On Thu, Jul 22, 2010 at 11:28 PM, Marsh Ray wrote:

> On 07/22/2010 08:05 PM, Dan Kaminsky wrote:
>
>>
>> That's $240K/yr being spent to manage three year expirations, just on
>> labor.
>>
>
> Yep.
>
> But as Dr. Laura would say, "you knew that before you married her".
>
> Nobody said you had to go into that business, or that you were entitled to
> make a profit on it.


Nobody says they have to deploy secure endpoints, but the credit card
people, and even then only on a really restricted subset of sites.

There are fundamental sources of these failures that are not just "people
are stupid".  Remember the tales of failed +$100M PKI deployments around the
turn of the millenium?

Why do you think so much money got spent?


What might be the unintended consequences be of having 500 "secure" sites
> hosted by folks that can't manage to spend one day every three freakin'
> years on maintenance?
>
> It's one day every three years per server.  If you have a lot of servers,
it adds up.  And so, we back into the empirical reality -- people don't put
SSL on a lot of servers.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

> Operationally, it just shouldn't be that big a deal to schedule a
> maintenance every few years. Like expiring domain registrations, the hardest
> part is simply to not lose track of it. The Accounting dept in an
> organization can sometimes help to not forget that stuff.
>
>
Shouldn't?  That's a nice word.

What does the data say?

Suppose I have five hundred web servers with five hundred expiration dates,
strewn out roughly uniformly over a three year period.  That means, I have
about one expiration every two days.

Now, to run a change:

1) A purchase must be made, of the thing to be changed
2) A meeting must be scheduled, to organize the change (especially if, as
you suggest, an external organization tracks these things)
3) An administrator must be tapped to implement the change in non-peak time
4) The change must happen
5) The change must be tested and validated
6) The new expiration time must be confirmed for tracking purposes

Lets say this is 8 man hours.  That means this is 4,000 man hours of work.
Assume the employee doing this work has an average cost to the company of
$60/hr (remember, you need to roughly double the cost of a full time
employee, after you factor in benefits, payroll taxes, etc).

That's $240K/yr being spent to manage three year expirations, just on labor.

And, of course, you see the result of this:  People don't go ahead and put
500 different certs on 500 different machines.  Instead, you end up with an
Internet having but a million SSL endpoints, only half of which even pretend
to have a validating certificate.

Costs can hide.  Consequences are another matter.
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] In-band signalling (was: Re: NuralStorm Webmail Multiple Vulnerabilities)

[Dan Kaminsky]

Out of band signaling can be made to work in small networks. In larger  
networks and systems, the problem is -- what makes you think you have  
simply two planes?  We call them n-tier, not 2-tier after all.

And nobody tunnels like telephony guys. If they ain't encapsulating,  
they ain't living.

So the game, as I see it, isn't to demand out of band operations. The  
game is to engineer systems that can strongly maintain separation  
between contexts, in band. Theoretically, nested TLV protocols would  
do this, but I think we've had enough malloc-external-length-memcpy- 
internal-length bugs to show, practically, it doesn't work.

I'm having some good experiences with protocols that move around  
Base64-encoded blocks. The key is to not encrypt the block, because  
man, you're never finding the key during debug.  Even then, it's being  
an interesting challenge to make standard tools unpack for debugging.   
No debug, no deploy.


On Jul 17, 2010, at 2:41 PM, Pavel Kankovsky  wrote:

> On Thu, 15 Jul 2010 valdis.kletni...@vt.edu wrote:
>
>>> (*) In-band signalling in telephone networks.
>> Feel free to elucidate a *feasible* way to have deployed out-of-band
>> signaling on the installed copper-pair base back then.
>
> I won't pretent I am an expert on PSTN technology. Nevertheless
> frequency-division multiplexing was already in use in 1950s so I do  
> not
> find the idea of literal out-of-band signalling (i.e. to make the  
> bandwith
> of trunk link channels slightly wider than what is allowed to come  
> from
> local loops and use that extra bandwidth for signalling) completely
> implausible.
>
>> Also, compare the *actual* costs and losses due to phreakers snagging
>> free service due to in-band signaling to the eventual cost of  
>> upgrading
>> every single central office to something that supported out-of-band.
>
> This smells like a red herring. They had to upgrade all of them to  
> support
> direct distance dialing in the first place and there have been more
> upgrades not related to the eventual widespread deployment of SS7 in
> 1990s.
>
>> Maybe those bell-heads weren't so dumb...
>
> That was not my point.
>
> It might have paid off to accept the risk of abuse when hardware was
> crude and expensive and when knowledge and gear needed to exploit the
> vulnerability was not easily available. Although I suspect it was more
> a case of being lucky enough to get away with a lack of foresight than
> a deliberate risk management decision.
>
> But it is 2010 now. Everything I mentioned earlier has changed years  
> ago.
> Hardware is incredibly more powerful and much cheaper. Every kiddie  
> has
> got a PC and high-speed Internet connection. All knowledge is one  
> Google
> search away (okay, I am a little bit exaggerating here). Yet the old  
> 2600
> Hz whistle lives on in apostrophes and less-than signs because we  
> still
> have not learned to keep control data and user data segregated.
>
> -- 
> Pavel Kankovsky aka Peak  / Jeremiah  
> 9:21\
> "For death is come up into our MS Windows(tm)..." \ 21st century  
> edition /
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Expired certificate

[Dan Kaminsky]

Junk,

X.509 always has another way it falls over in the field.   
Expiration management is one of those ways. In theory, it's no big  
deal to swap out an expired cert for a valid one.

In reality, it's a time bomb, of the sort that usually doesn't  
exist. Does the output of gcc have a 'run by' date?  Will your Cisco  
router simply fail to move traffic six months from now?  Perhaps the  
only thing vaguely akin to certificate failure is hard drive failure  
-- but imagine if drives *intentionally* committed suicide one day  
after warranty expire. People would go nuts!

Somehow, this is all OK in X.509.

Doing an emergency change to production machine is difficult in the  
best of times, when there's an actual outage and the clock is ticking.  
In this case, the outage is basically a policy outage. The box is up,  
it can receive traffic, it's just the other guy needs to handle the  
error differently. So, they're asking for that.

If you're curious *why* it's such a pain in the ass to make unplanned  
changes, it's because of the following process, repeated over and over  
again:

1) Someone needs to make a small change
2) He decides to be a bad ass and just does it
3) There's an outage because the guy screwed up
4) So said guy can keep his job, the outage is blamed on policy that  
clearly needs to be made stronger

Repeat until outage rate drops to accepable levels.



On Jul 17, 2010, at 8:56 AM, Junk Meat  wrote:

> What part of my thread suggests making unplanned changes in a live
> environment?  All that was said was the re-issuance of a certificate  
> and
> it's installation is a relatively simple process.  So you believe its
> alright to let a certificate remain expired for two weeks?
>
> Don't worry about educating me, there is nothing you have said that I
> don't already know...  it doesn't even sound like you have anything
> intelligent to articulate besides petty criticism and contemptuous  
> remarks.
>
>
> On 7/16/2010 5:16 PM, bk wrote:
>> So basically you advocate making unplanned changes whenever someone  
>> feels like it?
>>
>> The only problem here is that they let the cert expire.  Being  
>> responsible about conducting maintenance, instead of having a knee- 
>> jerk reaction, isn't to be faulted.
>>
>> If you think you can write better secure file transfer software, no  
>> one is stopping you.  You'll make a fortune.  Just remember it has  
>> to support more than half a dozen different protocols, support  
>> dozens of nodes talking to the same storage backends, synchronize  
>> data across datacenters, support triggered actions at multiple  
>> places in the transaction across multiple protocols, support  
>> multiple payload encryption protocols, allow single-sign-on  
>> authentication with third-party vendors, etc, etc, etc.  Oh yeah,  
>> it all has to pass independent code-review by external auditors.   
>> At that rate, supporting instant application of new certs in a  
>> multi-tiered environment with bi-directional trust is a cake-walk  
>> in comparison.
>>
>> Simple, right?
>>
>> I'm done educating you.  I know the software and I know what I'm  
>> talking about; clearly you know neither.
>>
>> On Jul 16, 2010, at 12:49 PM, Junk Meat wrote:
>>
>>
>>> chort or whatever your name is, some of us know what we're doing  
>>> and don't need to wait 2 weeks for a lousy ssl cert update much  
>>> less a daemon restart... give me a break.
>>>
>>> Quit defending the State of California, if they were so up on  
>>> security they shouldn't have passed SB1386 or any other  
>>> legislation for that matter.  Certificate authorities notify their  
>>> customers well in advance of expiring certs, multiple times in  
>>> fact, there's no excuse for that and then expecting your clients  
>>> to violate best practice afterward.  As far as change control and  
>>> system complexity, wise organizations keep things simple not  
>>> overly complex.
>>>
>>> Shawn Dermenjian
>>>
>>> On 7/16/2010 3:11 PM, bk wrote:
>>>
 Maybe you should know what you're talking about before you  
 speculate.  Most daemons require a restart when you change their  
 cert.  When you're talking about a service that has guaranteed up- 
 time, it can only be taken down for scheduled maintenance.   
 Changing production systems on a whim totally fails the 'A' in  
 'CIA' (and possibly the 'I' too).  Wise organizations implement  
 change-control policies to keep their critical systems from being  
 run-amok by ad-hoc changes.

 I'm familiar with the software State of California is using for a  
 lot of their secure file transfers and changing the certificate  
 is not as simple as you think (although the software is extremely  
 secure).  There are several cross-certification trust  
 relationships that need to be established for the software to  
 continue working after replacing certs.

 The risk of connecting to a machine with an expired

Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

[Dan Kaminsky]

> DR> And many of them could be mitigated via BCPs until such time as
> DR> fixed code could be deployed, as well.
> There it is again, BCP. Is this the new "IDS" ?
>
>
Best Practices are what forms when Ops guys are given broken systems and
told to make them work.

This isn't meant in a derogatory way.  Do you like things working?  I sure
do.  If it takes rules like "don't run trivial networking scanners on the
VoIP network" to keep the phones running, well, guess what.

There is a problem that this masks issues.  Attacker's aren't exactly known
for saying, "I'd own your network, but that would violate best practices, so
I won't."  VoIP code (speaking from fairly direct experience) is
aggressively fragile, partially since it comes from a background where the
presumption was that all traffic was trusted, and partially because the
specs are so hideously turgid.

In the short run, best practices are the only way to keep this stuff
stable.  In the long run...what's that?  Just gotta get to the next
quarter...
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

[Dan Kaminsky]

Agreed completely on don't panic.



On Jul 1, 2010, at 9:30 PM, "Dobbins, Roland"   
wrote:

>
> On Jul 2, 2010, at 8:13 AM, Lee wrote:
>
>> so presumably the scan came from a network that had full access to  
>> the routers.
>
> One question is whether or not the network in question *should* have  
> full access to the management plane of the routers.
>
> ;>
>
>> That's a bit harder to defend against.
>
>
> Sure, but also note that CoPP, HWRL, and the like can help,  
> depending upon the platform.
>
> Don't get me wrong; this should be investigated further, and PSIRT  
> are on it.  My point is that folks don't need to go into panic mode,  
> but should educate themselves as to how to defend their network  
> infrastructure against attack and then deploy the relevant BCPs.
>
> --- 
> 
> Roland Dobbins  // 
>
>Injustice is relatively easy to bear; what stings is justice.
>
>-- H.L. Mencken
>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

[Dan Kaminsky]

Permanent DoS's are unacceptable even from intentionally malicious  
traffic, let alone a few nmap flags. They're unacceptable to us,  
they're unacceptable to Microsoft (see: MSRC bug bar), and even Cisco  
PSIRT has shown up on thread desiring to clean things up.

It's funny you bring up SNMP. Do you remember what happened when that  
protocol got fuzzed by the PROTOS guys in 2002?  Every network device  
on the planet pretty much exploded. I will grant you that network  
isolation is indeed best practice, but broken code is not something to  
apologize for or mitigate against.  It's something to apply real  
pressure against.  If we can't get pissed, how is that QA guy supposed  
to block shipment?

(That being said, you'll note 'it's code you just shouldn't run' is  
wrong. First thing's first, the network has to function. We route  
packets with the infrastructure we have, etc.  But products that can't  
survive nmap are likely going to have real problems with actual  
exploit tools, and RCE in routers is not something to risk, 'best  
practice mitigations' or no.)

On Jul 1, 2010, at 7:16 PM, "Dobbins, Roland"   
wrote:

>
> On Jul 1, 2010, at 11:12 PM, Florian Weimer wrote:
>
>> And it's certainly a bug worth fixing.
>
> I doubt it's a 'bug' which can be 'fixed', just the same as sending  
> enough legitimate HTTP requests to a Web server to bring it to its  
> knees isn't a 'bug' which can be 'fixed', but rather a DoS which  
> must be mitigated via a variety of mechanisms.  It would be quite  
> helpful if the original poster would detail the models/types/ 
> versions of the network devices in question, and possibly provide a  
> sample query packet.
>
> Part of the general issue here is the large disconnect between the  
> traditional security research community and the networking  
> community; with a few notable exceptions, there isn't a lot of  
> mutual discussion and understanding, and certainly no understanding  
> of network infrastructure device architectures, best current  
> practices (BCPs), and so forth.
>
> One of the most fundamental BCPs is that one must make use of  
> various network infrastructure self-protection mechanisms to keep  
> undesirable traffic away from the control and management planes of  
> said network infrastructure.  Here's a .pdf presentation which  
> discusses network infrastructure self-protection:
>
> 
>
> Firing a bunch of SNMP queries at network infrastructure devices and  
> causing network disruption as a result isn't anything new, it's a  
> well-understood phenomenon with a well-understood - in the network  
> operational community, at least - remedy via making use of the  
> appropriate self-protection mechanisms built into most modern  
> network infrastructure devices.
>
> --- 
> 
> Roland Dobbins  // 
>
>Injustice is relatively easy to bear; what stings is justice.
>
>-- H.L. Mencken
>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

[Dan Kaminsky]

I would not object to posts on Full-Disclosure along the lines of "nmap -sV
crashes x device".  Unauthenticated remote permanent DoS's from standard
network scanning tools are certainly legitimate findings, and if this gives
more power to the QA guy in $NETWORKVENDOR, all the better.

On Thu, Jul 1, 2010 at 10:27 PM, Cor Rosielle  wrote:

> Hi Thierry,
>
> I agree this is a vulnerability. I also want to clear up an apparent
> misunderstanding: I don't tell not to scan with -sV, but to be careful
> because it is a dangerous switch that is known to sometimes crash
> devices. When you are testing a target, you have to know your tools and
> this is one of the characteristics of nmap.
>
> When testing, there are often some alternatives to choose from. And if
> the objective is to find out if there are any vulnerabilities in a host,
> then nmap -sV is one of the tools in the toolbox you can use. But if you
> just want to know the version of SNMP running, like Shang did, you just
> might want to choose another tool. (I would have used something like:
> for HOST in $(cat file.with.hosts); do snmpget -v 1 -c community-string
> $HOST sysDescr.0; done
> to find out if SNMP v1 was supported).
>
> Regards,
> Cor
>
>
> On Thu, 2010-07-01 at 11:28 +0200, Thierry Zoller wrote:
> > Hi Shang,
> >
> > If  this  is  possible  you  have  found  a  vulnerability. Any way to
> > remotely  cause  DoS  with  special  or  harmless  code  is  per  se a
> > vulnerability.
> >
> > Instead  of  telling  somebody  to not scan with -sV you are better of
> > reporting the vulnerability (ies)
> >
> > Regards,
> > Thierry
> >
> > coc> During my training classes I always tell the -sV switch is
> > coc> dangerous and known to (sometimes) crash the target.
> >
> > coc> Usually a better tool to test open udp ports is unicornscan, but
> > coc> that doesn't have a switch like -iL. Since you are testing your
> > coc> own devices and you know the community string, you could insider
> > coc> to loop through the list of IP's and snmpget a value from the MIB.
> >
> > coc> Cor
> >
> > coc> sent from a mobile device
> >
> >
> > coc> Origineel bericht
> > coc> Van: Shang Tsung
> > coc> Verzonden:  30-06-2010 13:03:32
> > coc> Onderw.:  Should nmap cause a DoS on cisco routers?
> >
> > coc> Hello,
> >
> > coc> Some days ago, I had the task to discover the SNMP version that our
> > coc> servers and networking devices use. So I run nmap using the
> following
> > coc> command:
> >
> > coc> nmap -sU -sV -p 161-162 -iL target_file.txt
> >
> > coc> This command was supposed to use UDP to probe ports 161 and 162,
> which
> > coc> are used for SNMP and SNMP Trap respectively, and return the SNMP
> > coc> version.
> >
> > coc> This "innocent" command caused most networking devices to crash and
> > coc> reboot, causing a Denial of Service attack and bringing down the
> > coc> network.
> >
> > coc> Now my question is.. Should this had happened? Can nmap bring the
> whole
> > coc> network down from one single machine?
> >
> > coc> Is this a configuration error of the networking devices?
> >
> > coc> This is scary...
> >
> > coc> Shang Tsung
> >
> >
> >
> >
> >
> >
> > coc>
> >
> > coc>
> 
> > coc> This list is sponsored by: Information Assurance Certification
> Review Board
> >
> > coc> Prove to peers and potential employers without a doubt that you
> > coc> can actually do a proper penetration test. IACRB CPT and CEPT
> > coc> certs require a full practical examination in order to become
> certified.
> >
> > coc> http://www.iacertification.org
> > coc>
> 
> >
> >
> > coc> ___
> > coc> Full-Disclosure - We believe in it.
> > coc> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> > coc> Hosted and sponsored by Secunia - http://secunia.com/
> >
> >
> >
> >
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Should nmap cause a DoS on cisco routers?

[Dan Kaminsky]

And this is why BreakingPoint matters:  Because, oh man, network people let
manufacturers get away with shipping some really fragile code.

If a Windows desktop fell over because you looked at it funny -- and lets be
honest, nmap -sV is quite literally, looking at something funny -- it'd be
an unambiguous remote DoS and we'd laugh at Microsoft if they said we should
deploy best practices to deal with it.  Now, if the networking equipment in
question was a $75 Linksys router, sure.  There's a million ways to knock
those things over, and you get what you pay for.

But genuinely expensive gear?  Some of that budget needs to start going into
resiliency.

On Thu, Jul 1, 2010 at 1:07 PM, Dobbins, Roland  wrote:

>
> On Jul 1, 2010, at 5:23 PM, Thierry Zoller wrote:
>
> > If a device crashes when being scanned - it's a vulnerability.
>
> It sounds to me as if what happened was that he ended up driving the CPUs
> of the devices in question to 100%, and they stopped handling control-plane
> traffic and fell over.  There are infrastructure self-protection best
> current practices (BCPs) which can be deployed to defend against
> infrastructure-targeted DoS.
>
> I've only seen this happen a few hundred times or so, so I could be wrong,
> of course.
>
> ;>
>
> As the original poster posited:
>
> > Is this a configuration error of the networking devices?
>
> The answer is, almost assuredly, "Yes."
>
> ---
> Roland Dobbins  // 
>
>Injustice is relatively easy to bear; what stings is justice.
>
>-- H.L. Mencken
>
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Chrome and Safari users open to stealth HTML5 Application Cache attack

[Dan Kaminsky]

On Tue, Jun 29, 2010 at 12:41 AM, Chris Evans  wrote:

> On Mon, Jun 28, 2010 at 1:30 PM, Dan Kaminsky  wrote:
> >
> >> In summary, any http hit on an insecure network is dangerous on all
> >> browsers.
> >> (FWIW, Chromium resolves this for me. When I type mail into the
> >> omnibar, it auto-completes to https://mail.google.com/)
> >>
> >
> > Actually, I see this as a legitimate gap.  HTTP links don't cache-mix
> with
> > HTTPS links, and cookies can have server-side integrity checking to
> prevent
> > HTTP pollution (lets not talk about the secure tag for cookies), but if
> it
> > is indeed the case that there is no way to have a HTTPS-exclusive
> > Application Cache, then that is a feature killing bug that's been
> > legitimately called out.
>
> Eh? Lava's attack poisons a plain HTTP resource. As per "regular"
> caching, Application Cache is supposed to separate the effects of HTTP
> and HTTPS responses.
>

==
On unsecured networks, attackers could stealthily
create malicious Application Caches in the browser of victims for even HTTPS
sites.
It has always been possible to poison the browser cache and compromise the
victim's account for HTTP based sites.
With HTML5 Application Cache, it is possible to poison the cache of even
HTTPS sites.
==

Is it agreed that if the above is true -- meaning, separation doesn't
actually exist -- then there's a bug?





>
>
> Cheers
> Chris
>
> >
> > --Dan
> >
> >
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Chrome and Safari users open to stealth HTML5 Application Cache attack

[Dan Kaminsky]

> In summary, any http hit on an insecure network is dangerous on all
> browsers.
> (FWIW, Chromium resolves this for me. When I type mail into the
> omnibar, it auto-completes to https://mail.google.com/)
>
>
Actually, I see this as a legitimate gap.  HTTP links don't cache-mix with
HTTPS links, and cookies can have server-side integrity checking to prevent
HTTP pollution (lets not talk about the secure tag for cookies), but if it
is indeed the case that there is no way to have a HTTPS-exclusive
Application Cache, then that is a feature killing bug that's been
legitimately called out.

--Dan
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] newest category of security bugs considered elite ?

[Dan Kaminsky]

On May 1, 2010, at 8:30 PM, Nick FitzGerald   
wrote:

> Dan Kaminsky wrote:
>
>> I really like the hash length declaration bugs, where the client can
>> tell the server how many bytes of a hash need to be validated.  (Yep,
>> you just say "one byte is plenty")
>>
>> SNMPv3 and XML-DSIG both fell to this, catastrophically.
>
> I thought Georgi asked for the newest class of elite vulns?
>
> Does (at least) ten years old count as new?
>
Ooh, SMB's old Hollywood OS bug -- one character at a time attacks.  
Indeed, this is very old.  It's actually an annoying pattern, that  
things we think are attack multipliers ('you have to simultaneously  
attack MD5 and SHA1') turn out to just be adders (you can attack one  
at a time).

This bug class is different, and as far as I know unseen from the 80's  
and 90's. In this one, you tell the remote system, 'sure, I can match  
your stored hash -- but it's only one byte long.'. So you try an  
average of 128 passwords, and off you go.

It's basically a problem where the client is trusted to provide  
excessive metadata about server state. If you've got other examples in  
this family, it'd be cool to hear them.

(The TLS reneg bug was super cool but client/server confusion of  
identical protocol messages has precedent, I'm sure.)



>   http://www.microsoft.com/technet/security/bulletin/ms00-072.mspx
>
> And against Win9x count as elite?   8-)
>
> FWIW, MS00-072 was fairly widely exploited in the wild by at least the
> Opaserv (aka Opasoft) family of worms, though not until a couple (?)  
> of
> years after the bulletin's release.
>
>
>
> Regards,
>
> Nick FitzGerald
>
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] newest category of security bugs considered elite ?

[Dan Kaminsky]

I really like the hash length declaration bugs, where the client can  
tell the server how many bytes of a hash need to be validated.  (Yep,  
you just say "one byte is plenty")

SNMPv3 and XML-DSIG both fell to this, catastrophically.





On May 1, 2010, at 2:23 PM, Georgi Guninski   
wrote:

> ok, we had a flame.
>
> what is the newest category of sekurity bugz that is considered  
> elite ?
>
> basically, int. over., BO are generally considered elite yet barely  
> new.
> XSS probably is not elite by 3l33t majority opinion.
>
> i was looking in the past and my heart was not beating fast ;-)
>
> -- 
> joro
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] IE8 img tag HiJacking

[Dan Kaminsky]

Interesting use, using filesize to back into the actual CAPTCHA used for a
given query.  Sneaky!

So it's possible to read not only filesize, but image dimensions
cross-domain.  I actually found a use for this -- it's a good way to
exchange a small amount of data between sites that mutually distrust one
another.  The reason for this is that images are pretty much the only
resources that can be loaded cross-domain that won't have embedded script
executed by a browser.

(Side note:  At this point, you're probably thinking:  Vladimir just said
that some browsers allow SVG to load via  -- and SVG can embed script
with nothing but a script tag  and a smile!  Doesn't this mean a bunch of
sites are in trouble?

Turns out, no, not as far as I can tell anyway.  IE and Firefox both block
 to SVG entirely, while Chrome, Safari, and Opera allow it.  But there
appears to be a script firewall (or more accurately, a missing connection)
between -loaded SVG and the script engine.  Static SVG renders just
fine, but don't expect it to do anything unless you top-level nav, inline,
or use something like embed.)

Back to image dimensions, it turns out that this information channel cannot
be closed; even if the dimensions of the object itself couldn't be queried,
the XY positioning of the objects *around* the imported images must be both
queryable and dependent on image properties.

I was curious however if img.fileSize would leak filesizes of non-image
content.  Doesn't look like it does -- undefined in everything but IE, -1 in
IE.


2010/4/22 T Biehn 

> It could be used as a technique for defeating the login images used as
> "two-factor-authentication" by some online services.
> The application of using filesize to fingerprint an image is somewhat
> novel. This is a decidedly 'old' vector, though.
>
> -Travis
>
> 2010/4/21 Владимир Воронцов 
>
> Hello Full disclosure!
>>
>> Once again, unwinding theme HiJacking found a fun way to get the very
>> least information about the target resource when the user is located at
>> the
>> attacker.
>>
>> Already crocked  tag opens new opportunities using the method
>> fileSize, described here:
>> http://msdn.microsoft.com/en-us/library/ms533752
>> (v = VS.85). Aspx
>>
>> Consider a simple example - a Web application after authentication
>> provides some sort of picture for the user, for example:
>>
>> http://example.com/getImage.php?image=myAvatar
>>
>> The attacker, knowing this can create a page to read:
>>
>> http://example.com/getImage.php?image=myAvatar";>
>>
>> 
>>
>> Thus, the attacker learns the simplest case, whether the target user
>> access to example.com.
>>
>> Continuing the theme, I want to note that in some cases, can obtain
>> additional information from the very values of the size of the picture. It
>> can be any logical information Web applications, say, the same script can
>> show administrators a picture of the same size, and users - of another.
>> Thus, we obtain the user rights. And so on.
>>
>> I'd like to return the size of the method is not only "valid" images, but
>> also HTML pages, JSON, etc. But, unfortunately, does not work. Maybe, of
>> course, there are exceptions, call to investigate the matter.
>>
>> I have some thoughts on the study of vector images in XML format, because
>> HTML is often valid XML, and then ...
>>
>> Check for the test version IE9, but he did not support SVG inside tag
>> , but only as a separate tag.
>>
>> Works in IE8, in Opera 10.52 does not work on check writing, if not
>> difficult.
>>
>> Original at russian language: http://oxod.ru/?p=113
>>
>> --
>> Best regards,
>> Vladimir Vorontsov
>> ONsec security expert
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>
>
>
> --
> FD1D E574 6CAB 2FAF 2921  F22E B8B7 9D0D 99FF A73C
> http://pgp.mit.edu:11371/pks/lookup?search=tbiehn&op=index&fingerprint=on
> http://pastebin.com/f6fd606da
>
> ___
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/
>
___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] IE8 img tag HiJacking

[Dan Kaminsky]

Also, Billy Hoffman has done a lot of fun work in this space, see
http://www.gnucitizen.org/blog/javascript-remoting-dangers/



2010/4/22 Dan Kaminsky :
> Interesting use, using filesize to back into the actual CAPTCHA used for a
> given query.  Sneaky!
>
> So it's possible to read not only filesize, but image dimensions
> cross-domain.  I actually found a use for this -- it's a good way to
> exchange a small amount of data between sites that mutually distrust one
> another.  The reason for this is that images are pretty much the only
> resources that can be loaded cross-domain that won't have embedded script
> executed by a browser.
>
> (Side note:  At this point, you're probably thinking:  Vladimir just said
> that some browsers allow SVG to load via  -- and SVG can embed script
> with nothing but a script tag  and a smile!  Doesn't this mean a bunch of
> sites are in trouble?
>
> Turns out, no, not as far as I can tell anyway.  IE and Firefox both block
>  to SVG entirely, while Chrome, Safari, and Opera allow it.  But there
> appears to be a script firewall (or more accurately, a missing connection)
> between -loaded SVG and the script engine.  Static SVG renders just
> fine, but don't expect it to do anything unless you top-level nav, inline,
> or use something like embed.)
>
> Back to image dimensions, it turns out that this information channel cannot
> be closed; even if the dimensions of the object itself couldn't be queried,
> the XY positioning of the objects *around* the imported images must be both
> queryable and dependent on image properties.
>
> I was curious however if img.fileSize would leak filesizes of non-image
> content.  Doesn't look like it does -- undefined in everything but IE, -1 in
> IE.
>
>
> 2010/4/22 T Biehn 
>>
>> It could be used as a technique for defeating the login images used as
>> "two-factor-authentication" by some online services.
>> The application of using filesize to fingerprint an image is somewhat
>> novel. This is a decidedly 'old' vector, though.
>>
>> -Travis
>>
>> 2010/4/21 Владимир Воронцов 
>>>
>>> Hello Full disclosure!
>>>
>>> Once again, unwinding theme HiJacking found a fun way to get the very
>>> least information about the target resource when the user is located at
>>> the
>>> attacker.
>>>
>>> Already crocked  tag opens new opportunities using the method
>>> fileSize, described here:
>>> http://msdn.microsoft.com/en-us/library/ms533752
>>> (v = VS.85). Aspx
>>>
>>> Consider a simple example - a Web application after authentication
>>> provides some sort of picture for the user, for example:
>>>
>>> http://example.com/getImage.php?image=myAvatar
>>>
>>> The attacker, knowing this can create a page to read:
>>>
>>> http://example.com/getImage.php?image=myAvatar";>
>>>
>>> 
>>>
>>> Thus, the attacker learns the simplest case, whether the target user
>>> access to example.com.
>>>
>>> Continuing the theme, I want to note that in some cases, can obtain
>>> additional information from the very values of the size of the picture.
>>> It
>>> can be any logical information Web applications, say, the same script can
>>> show administrators a picture of the same size, and users - of another.
>>> Thus, we obtain the user rights. And so on.
>>>
>>> I'd like to return the size of the method is not only "valid" images, but
>>> also HTML pages, JSON, etc. But, unfortunately, does not work. Maybe, of
>>> course, there are exceptions, call to investigate the matter.
>>>
>>> I have some thoughts on the study of vector images in XML format, because
>>> HTML is often valid XML, and then ...
>>>
>>> Check for the test version IE9, but he did not support SVG inside tag
>>> , but only as a separate tag.
>>>
>>> Works in IE8, in Opera 10.52 does not work on check writing, if not
>>> difficult.
>>>
>>> Original at russian language: http://oxod.ru/?p=113
>>>
>>> --
>>> Best regards,
>>> Vladimir Vorontsov
>>> ONsec security expert
>>>
>>> ___
>>> Full-Disclosure - We believe in it.
>>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>>> Hosted and sponsored by Secunia - http://secunia.com/
>>
>>
>>
>> --
>> FD1D E574 6CAB 2FAF 2921  F22E B8B7 9D0D 99FF A73C
>> http://pgp.mit.edu:11371/pks/lookup?search=tbiehn&op=index&fingerprint=on
>> http://pastebin.com/f6fd606da
>>
>> ___
>> Full-Disclosure - We believe in it.
>> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
>> Hosted and sponsored by Secunia - http://secunia.com/
>
>

___
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Re: [Full-disclosure] Possible RDP vulnerability

[Dan Kaminsky]

You say this, but I note with interest and approval that your  
recommendation was to sidestep desktop 'restrictions' entirely in  
favor of certificate based access control.


Quantization of security and all that.

On Mar 27, 2010, at 11:56 AM, "Thor (Hammer of God)" > wrote:


No, they don’t “always” win.  Maybe back with windows 2000, or  
XP, but not with Windows 7 anyway.  Of course, none of this does any 
thing to stop them from booting off a CD and owning the box that way.




However, I do agree that people need to fully understand exactly  
what they are, and more importantly, are NOT doing insofar as  
security is concerned when it comes to access to local assets.




t



From: Dan Kaminsky [mailto:d...@doxpara.com]
Sent: Saturday, March 27, 2010 7:37 AM
To: wicked clown
Cc: Thor (Hammer of God); Full-Disclosure@lists.grok.org.uk
Subject: Re: [Full-disclosure] Possible RDP vulnerability



So it's a super common thing for schools to have 'locked down'  
Windows desktops, and even more common for even slightly nerdy kids  
to take the lockdown as a challenge to be  defeated.




The point of course is that the kids always win:  At the point  
somebody has the set of privileges exposed by any amount of desktop  
access, constraining execution for them is similar to getting the  
idea that, perhaps, it would be the responsible thing to open  
discussions around managing the open state of the barn door.








On Mar 27, 2010, at 7:39 AM, wicked clown > wrote:


I think we are two different pages :)

what I was trying to show if you have a group policy that will only  
run a certain applications for example notepad.exe, the user is  
unable to access my computer, run or the start button or any other  
application. There would be a shortcut on the desktop for just  
notepad.exe for the user to execute.


The user use RDP to connect to the terminal server so they can  
access notepad.exe but if you change the application in the programs  
tab under the RDP client the user is now able to run any application  
on the terminal server, the user then execute internet explorer and  
download a modified cmd.exe and save it in the c:\windows\temp (even  
if you denied access to the hard drive users can still write to the  
temp folder) now I log off the rdp client change the program to  
point to c:\windows\temp\cmd.exe, I how have access to the command  
prompt with access to the command prompt I can run any other  
application or access other parts of the server they are not allowed  
to access.


That is what my video was try to demostrate that even denying access  
to applications on the server you can still execute applications  
from that server.


But as been mention if you put that single click in the RDP-tcp on  
the server then the user is unable to execute other applications.


I have been doing some further checks and I can confirm I have seen  
this affect about 90% of so called secure systems with group policy,  
but will execute normally block applications. I have even found  
systems on the Internet that are vulnerable to this.


I think we may have to agree to disagree on this subject. But thank  
you for you views and comments.


On Fri, Mar 26, 2010 at 9:29 PM, Thor (Hammer of God) > wrote:


I think you still misunderstand.



The option you refer to has nothing to do with “locking down” the  
server.  When you say things like “a locked down group policy that i 
s tighter than a ducks bum” what exactly are you talking about?




Selecting “don’t allow a startup program to be run” simply  
forces the desktop to be shown as opposed to an application one may  
specify.  If I initiate a session and tell it to run calc.exe, then  
calc.exe is what it presented upon connection.  It’s a shortcut for  
the user.  If at the server I don’t allow applications to be specifi 
ed, then it won’t run them and will default to the desktop.  But I c 
an still go “start, run, calc” and it will run fine if I have  
permissions to run it.  AppLocker is a great way to lock down the ho 
st environment, whether RDP or not.




And you are quite incorrect about “no user based control”  
stopping you.  As mentioned, AppLocker could have prevented it had i 
t been deployed “properly.”  Well, it would help, anyway.
Depends on the manner in which the attack was carried out, of course 
, but that has nothing whatsoever to do with the setting in RDP.  De 
ploying RDP to untrusted users or malicious users is not good policy 
; as such, you need to take extra care in securing RDP hosts by usin 
g permissions and other restrictions.




I think you need to relax a little and think about what you post – s 
aying things like “a GPO tighter to a ducks bum” and “open to  
total pwnage” and “nothing would stop me” sounds a bit  
hyperbolic (in addition to being incorrect).




To summarize, your concerns have nothing to do with RDP security  
settings as you have presented them.