Re: [Full-disclosure] PayPal.com XSS Vulnerability
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 robert.kugle...@gmail.comwrote: 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))//-- /SCRIPT'SCRIPTalert(String.fromCharCode(88,83,83))/SCRIPT 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...)
...you are a magnificent bastard. On Sun, May 5, 2013 at 5:43 PM, Michal Zalewski lcam...@coredump.cx 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
On Wed, Nov 28, 2012 at 6:23 AM, Georgi Guninski gunin...@guninski.comwrote: 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
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
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
On Mon, Aug 20, 2012 at 8:29 AM, Paul Schmehl pschmehl_li...@tx.rr.comwrote: --On August 20, 2012 2:22:28 AM -0700 Dan Kaminsky d...@doxpara.com 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
On Mon, Aug 20, 2012 at 9:29 AM, Paul Schmehl pschmehl_li...@tx.rr.comwrote:
--On August 20, 2012 8:32:59 AM -0700 Dan Kaminsky d...@doxpara.com
wrote:
On Mon, Aug 20, 2012 at 8:29 AM, Paul Schmehl pschmehl_li...@tx.rr.com
wrote:
--On August 20, 2012 2:22:28 AM -0700 Dan Kaminsky d...@doxpara.com
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
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] DakaRand
On Sun, Aug 19, 2012 at 10:13 AM, Ben Laurie b...@links.org wrote: On Sun, Aug 19, 2012 at 5:42 PM, Dan Kaminsky d...@doxpara.com 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
On Sun, Aug 19, 2012 at 3:03 PM, Ben Laurie b...@links.org wrote: On Sun, Aug 19, 2012 at 9:28 PM, Dan Kaminsky d...@doxpara.com wrote: On Sun, Aug 19, 2012 at 10:13 AM, Ben Laurie b...@links.org wrote: On Sun, Aug 19, 2012 at 5:42 PM, Dan Kaminsky d...@doxpara.com 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] how i stopped worrying and loved the backdoor
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 coder...@gmail.com 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 coder...@gmail.com wrote: On Fri, Dec 24, 2010 at 5:08 PM, Dan Kaminsky d...@doxpara.com 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
Surely you can create a sock puppet for debugging purposes. On Thu, May 17, 2012 at 11:43 AM, Michael Gray mg...@emitcode.com 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 he...@google.com 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 mg...@emitcode.com 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 he...@google.com 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] Trigerring Java code from a SVG image
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 img's. It would be problematic indeed if img src=foo.jpg 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] Trigerring Java code from a SVG image
Anything from img in any browser? On Wed, May 16, 2012 at 2:25 AM, Michele Orru antisnatc...@gmail.comwrote: 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 d...@doxpara.com 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 img's. It would be problematic indeed if img src=foo.jpg 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/ -- /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] The story of the Linux kernel 3.x...
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] Linksys Routers still Vulnerable to Wps vulnerability.
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.
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 sleekmountain...@gmail.comwrote: 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 d...@doxpara.com 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.
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 cthulhucall...@gmail.com wrote: On Mon, Feb 13, 2012 at 1:57 PM, Dan Kaminsky d...@doxpara.com 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_contentview=sectionlayout=blogid=5Itemid=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.
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=1articleid=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] Linksys Routers still Vulnerable to Wps vulnerability.
According to the Reaver people, DD-WRT doesn't support WPS at all :) On Fri, Feb 10, 2012 at 2:00 PM, Zach C. fxc...@gmail.com wrote: Solution: use DD-WRT? Or is that vulnerable too? (Or are there worse problems? :)) On Feb 10, 2012 10:12 AM, Dan Kaminsky d...@doxpara.com 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=1articleid=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.
On Fri, Feb 10, 2012 at 4:33 PM, valdis.kletni...@vt.edu 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] Fun with Bitcoin, or how an exploit can hide in plain sight
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 makos...@googlemail.comwrote: 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 from impossible. By full-disclosure standards this is
Re: [Full-disclosure] VNC viewers: Clipboard of host automatically sent to remote machine
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 n...@virus-l.demon.co.ukwrote: 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
Nothing to be done, really. Most users run as admin. On Tue, Jan 17, 2012 at 4:19 PM, Floste flo...@gmx.de 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
LAN-only, no? Sent from my iPhone On Jan 17, 2012, at 4:11 PM, HI-TECH . isowarez.isowarez.isowa...@googlemail.com wrote: Demonstration of the Exploit: http://www.youtube.com/watch?v=78nAxh70yZE (thanks ClsHack) see attached content /Kingcope undeadattack.c ___ 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
On Tue, Dec 20, 2011 at 7:00 PM, coderman coder...@gmail.com wrote: On Tue, Dec 20, 2011 at 9:40 AM, Charles Morris cmor...@cs.odu.edu 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
On Mon, Nov 21, 2011 at 9:58 AM, valdis.kletni...@vt.edu 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
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 johannest...@gmail.com Sender: full-disclosure-boun...@lists.grok.org.uk Date: Fri, 18 Nov 2011 12:04:46 To: Olivierfeui...@bibibox.fr Cc: full-disclosure@lists.grok.org.uk 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
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 d...@doxpara.com Date: Sat, 19 Nov 2011 11:36:47 To: ja...@zero-internet.org.ukja...@zero-internet.org.uk Cc: Johan Nestaasjohannest...@gmail.com; full-disclosure-boun...@lists.grok.org.ukfull-disclosure-boun...@lists.grok.org.uk; Olivierfeui...@bibibox.fr; full-disclosure@lists.grok.org.ukfull-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 johannest...@gmail.com Sender: full-disclosure-boun...@lists.grok.org.uk Date: Fri, 18 Nov 2011 12:04:46 To: Olivierfeui...@bibibox.fr Cc: full-disclosure@lists.grok.org.uk 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
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 evdo.hs...@gmail.com wrote: Ummm... any idea why remote SSH is not possible?!?!? o_O kinna weird! On Thu, Nov 17, 2011 at 4:23 AM, Olivier feui...@bibibox.fr 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
On Fri, Nov 18, 2011 at 5:01 AM, valdis.kletni...@vt.edu 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
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=2ob=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] Verizon Wireless DNS Tunneling
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 li...@blackhat.bz 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=2ob=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
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 jamfwri...@gmail.com 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 d...@doxpara.com 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 li...@blackhat.bz 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=2ob=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
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 hartley...@osu.eduwrote: 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 d...@doxpara.com 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 li...@blackhat.bz 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=2ob=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
Re: [Full-disclosure] Twitter URL spoofing still exploitable
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
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
On Thu, Sep 8, 2011 at 2:55 AM, Georgi Guninski gunin...@guninski.comwrote: 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
On Wed, Aug 24, 2011 at 10:52 PM, root ro...@fibertel.com.ar 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
On Wed, Aug 24, 2011 at 9:45 PM, root ro...@fibertel.com.ar 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
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 mitja.kol...@acrossecurity.com 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 d...@doxpara.com 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 li...@acros.si 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 CEOCTO 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
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 mitja.kol...@acros.si 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 li...@acros.si 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 ng -proof.html or http://bit.ly/iSxHKO Best regards, Mitja Kolsek CEOCTO 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 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/ ___ 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
Re: [Full-disclosure] ZDI-11-168: Multiple Vendor librpc.dll Remote Information Disclosure Vulnerability
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
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 nelh...@ksplice.com 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?
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 securityconscious...@gmail.com 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
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=scriptalert(1);/script' . [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
Sent from my iPhone On Dec 25, 2010, at 2:38 PM, BMF badmotherfs...@gmail.com wrote: On Sat, Dec 25, 2010 at 2:12 PM, cpol...@surewest.net 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
On Fri, Dec 24, 2010 at 4:37 PM, BMF badmotherfs...@gmail.com wrote: On Fri, Dec 24, 2010 at 4:27 PM, coderman coder...@gmail.com 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
On Wed, Dec 22, 2010 at 3:47 PM, Dave Nett dave.n...@yahoo.com wrote: http://marc.info/?l=openbsd-techm=129296046123471w=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
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 m...@propergander.org.uk 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$
On Tue, Dec 7, 2010 at 6:02 PM, Georgi Guninski gunin...@guninski.com 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$
- 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] verizon vs m$
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] Evilgrade 2.0 - the update explotation framework is back
On Sat, Oct 30, 2010 at 8:02 AM, valdis.kletni...@vt.edu 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.comfrom%3aupd...@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
Sent from my iPhone On Oct 20, 2010, at 8:58 AM, Michal Zalewski lcam...@coredump.cx 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
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
On Tue, Sep 14, 2010 at 6:07 PM, Stefan Kanthak stefan.kant...@nexgo.de 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
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, paul.sz...@sydney.edu.au 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
On Fri, Sep 10, 2010 at 11:46 AM, Nikhil Mittal nikhil_uitr...@yahoo.co.in 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: iframe src='foo.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
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 glutt...@gmail.comwrote: 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 uuf6...@gmail.com 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 tim-secur...@sentinelchicken.org 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 authentication. They don’t understand key management, and the task of getting hundreds of thousands or millions of users to install a client certificate or generate a keypair (and not accidentally reveal the private key) is a Herculean task that few IT departments want to try. * Users cannot be trusted to manually verify fingerprints. Seriously, they just won’t. Even the ones that perceive themselves as sophisticated and security-conscious. Ok, maybe. Let's assume for now that these two assertions are correct. * The network is now many times more hostile and open to attack than the server. Really? Now compared to when? HERE'S HOW CLENCH WORKS: 1. Client connects to server and sends hello
Re: [Full-disclosure] KeePass version 2.12 = Insecure DLL Hijacking Vulnerability (dwmapi.dll)
So, what's the security model around .ygwx files? On Tue, Sep 7, 2010 at 1:57 AM, YGN Ethical Hacker Group li...@yehg.netwrote: 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)
excuse me, kdbx. same difference On Tue, Sep 7, 2010 at 2:23 AM, Dan Kaminsky d...@doxpara.com wrote: So, what's the security model around .ygwx files? On Tue, Sep 7, 2010 at 1:57 AM, YGN Ethical Hacker Group li...@yehg.netwrote: 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
On Aug 31, 2010, at 2:01 PM, Charles Morris cmor...@cs.odu.edu 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
On Aug 31, 2010, at 2:20 PM, Charles Morris cmor...@cs.odu.edu wrote: On Tue, Aug 31, 2010 at 5:15 PM, Dan Kaminsky d...@doxpara.com 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
On Aug 31, 2010, at 4:08 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com 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
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
On Aug 31, 2010, at 6:49 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com 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
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
On Fri, Aug 27, 2010 at 1:51 AM, valdis.kletni...@vt.edu 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
On Fri, Aug 27, 2010 at 9:10 AM, valdis.kletni...@vt.edu 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
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 la...@larryseltzer.comwrote: #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 la...@larryseltzer.com 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
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 la...@larryseltzer.comwrote: 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
...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 uuf6...@gmail.comwrote: 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 d...@doxpara.com 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 la...@larryseltzer.com 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 la...@larryseltzer.com 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/ ___ Full-Disclosure - We believe
Re: [Full-disclosure] DLL hijacking with Autorun on a USB drive
On Thu, Aug 26, 2010 at 3:53 PM, matt m...@attackvector.org 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] DLL hijacking with Autorun on a USB drive
On Aug 26, 2010, at 7:53 PM, Larry Seltzer la...@larryseltzer.com 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
On Aug 26, 2010, at 9:30 PM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com 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
On Fri, Aug 27, 2010 at 1:06 AM, paul.sz...@sydney.edu.au wrote: Dan Kaminsky d...@doxpara.com 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
On Fri, Aug 27, 2010 at 1:05 AM, valdis.kletni...@vt.edu 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] Expired certificate
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
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
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] Expired certificate
On Thu, Jul 22, 2010 at 11:28 PM, Marsh Ray ma...@extendedsubset.comwrote: 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
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 junkm...@goshawn.com 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 cert is that the cert may have been revoked. That's why there are expiration dates on certs. Even if you're using a CRL, you cannot have the CRL contain
Re: [Full-disclosure] In-band signalling (was: Re: NuralStorm Webmail Multiple Vulnerabilities)
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 p...@argo.troja.mff.cuni.cz 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] Should nmap cause a DoS on cisco routers?
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?
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 rdobb...@arbor.net 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 rdobb...@arbor.net // http://www.arbornetworks.com 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?
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 c...@outpost24.com 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?
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 rdobb...@arbor.net 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: http://files.me.com/roland.dobbins/prguob 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 rdobb...@arbor.net // http://www.arbornetworks.com 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?
Agreed completely on don't panic. On Jul 1, 2010, at 9:30 PM, Dobbins, Roland rdobb...@arbor.net 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 rdobb...@arbor.net // http://www.arbornetworks.com 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
In summary, any http hit on an insecure network is dangerous on all browsers. (FWIW, Chromium resolves this for me. When I type mailenter 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] Chrome and Safari users open to stealth HTML5 Application Cache attack
On Tue, Jun 29, 2010 at 12:41 AM, Chris Evans scarybea...@gmail.com wrote: On Mon, Jun 28, 2010 at 1:30 PM, Dan Kaminsky d...@doxpara.com wrote: In summary, any http hit on an insecure network is dangerous on all browsers. (FWIW, Chromium resolves this for me. When I type mailenter 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] newest category of security bugs considered elite ?
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 gunin...@guninski.com 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] newest category of security bugs considered elite ?
On May 1, 2010, at 8:30 PM, Nick FitzGerald n...@virus-l.demon.co.uk
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] IE8 img tag HiJacking
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 d...@doxpara.com:
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 img -- 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
img 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 img-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 tbi...@gmail.com
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 Владимир Воронцов vladimir.voront...@onsec.ru
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 img 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:
img id=onsec src=http://example.com/getImage.php?image=myAvatar;
input type=button onclick=if (onsec.fileSize 0) (alert ('authorized
on example.com') else (alert ('not authorized on example.com')}
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
img, 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=tbiehnop=indexfingerprint=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
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 img -- 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
img 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 img-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 tbi...@gmail.com
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 Владимир Воронцов vladimir.voront...@onsec.ru
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 img 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:
img id=onsec src=http://example.com/getImage.php?image=myAvatar;
input type=button onclick=if (onsec.fileSize 0) (alert ('authorized
on example.com') else (alert ('not authorized on example.com')}
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
img, 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=tbiehnop=indexfingerprint=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
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 wickedclow...@googlemail.com 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) t...@hammerofgod.com 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. MS10-015 is certainly an important issue for local-host based attacks, of which RDP is one. One’s mitigation efforts should indeed include RDP hosts. The takea way from that is to apply more due diligence to securing RDP deploym ents as one would with any asset you give users local access to. R DP should not be viewed as a security mechanism, but rather, an acce ss mechanism. There are MANY ways to secure RDP, limit access, publ ish applications in singularity, create remote workspaces, etc, but you need to educate yourself on these solutions. The behavior you describe is expected, by design behavior. t From: full-disclosure-boun...@lists.grok.org.uk [mailto:full- disclosure-boun...@lists.grok.org.uk] On Behalf Of wicked clown Sent: Friday, March 26, 2010 8:31 AM To: Full-Disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Possible RDP vulnerability Thank you
Re: [Full-disclosure] Possible RDP vulnerability
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) t...@hammerofgod.com 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 wickedclow...@googlemail.com 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) t...@hammerofgod.com 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
Re: [Full-disclosure] EasyJet is storing user passwords in the clear
Sai, I see where you're coming from, but what are the most recent statistics on the effectiveness of hash cracking? Isn't it something like 70% of the passwords in the field can be cracked with a minimal amount of brute forcing? There are best practices, and there are vulnerabilities. I don't think anybody's going to argue it's not best practice to store hashes rather than plaintext, but lets not delude ourselves regarding their effectiveness. On Wed, Feb 24, 2010 at 6:57 PM, Sai Emrys s...@saizai.com wrote: A month ago, I notified EasyJet's network administrator, Lance Wantenaar lance.wanten...@easyjet.com, about a serious flaw in EasyJet's password storage policy. Although I explained the problem and its consequences to him clearly, and explained that I would be acting in accordance with the standards of responsible full disclosure, EasyJet has not corrected this issue despite Lance's assurances that they would investigate it. I have since attempted to follow up with Lance multiple times, but he has not responded. Since they have both had the standard one month and failed to even superficially patch this problem, and their official contact has chosen to not stay in contact, I am making this issue public in the hope that any other security problems with their websites are also made public, and that public shaming will prompt them to protect their users' security when private disclosure did not. EasyJet is currently storing users' passwords in the clear (or using reversible encryption, which is equivalent). You can verify this for yourself by creating an account at http://www.easyjet.com/asp/en/members/ and then activating the 'I have forgotten my password' link. It emails the password back to you in plain text, something that is completely impossible in a securely designed system that only stores salted hashes. Although I have not tested EasyJet's website for SQL injection vulnerabilities, and have no plan to do so, I would say that in my professional experience, people who make such a glaring security error as storing passwords in the clear tend to have other errors as well. As a result of EasyJet's incompetence, if any such vulnerability is found, an attacker will also be able to harvest all of its users' passwords. For a recent example of why this is a problem, please see http://www.techcrunch.com/2009/12/14/rockyou-hack-security-myspace-facebook-passwords/ - and note the followup litigation at http://gigaom.com/2009/12/30/rockyou-sued-over-user-data-breach/ . If you have any questions about this, or you know of any other relevant security issues that may be of interest to me, please contact me. My contact info is at http://saizai.livejournal.com/info . This has been posted publicly to my blog at http://saizai.livejournal.com/960498.html ; I would appreciate a link from any news story or related blogging. Sincerely, Sai Emrys ___ 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] EasyJet is storing user passwords in the clear
On Thu, Feb 25, 2010 at 10:39 AM, Michael Neal Vasquez m...@alumni.princeton.edu wrote: On Thu, Feb 25, 2010 at 8:05 AM, Dan Kaminsky d...@doxpara.com wrote: Sai, I see where you're coming from, but what are the most recent statistics on the effectiveness of hash cracking? Isn't it something like 70% of the passwords in the field can be cracked with a minimal amount of brute forcing? 70% ? Plain MD5 perhaps, but I don't think salted, or sha1, etc, have anywhere near such high success rates. The problem isn't in the algorithm -- it's in the passwords themselves. Salting helps in that the attacker can't amortize the work effort across the entire population, but at the end of the day, even PBKDF2 isn't going to do much against 1234567890 and its ilk. To put it another way, if EasyJet *did* have a breach, they couldn't very well say It's OK, because the passwords were hashed. ___ 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] EasyJet is storing user passwords in the clear
We agree completely on the 70%. Re, the 30%-- Salting makes the biggest difference on large datasets, just because even for 1000 different users you're now working 1000 times faster. Algorithm choice matters less. The speed difference between MD5 and SHA-1 isn't that significant though: $ openssl speed md5 Doing md5 for 3s on 16 size blocks: 2985670 md5's in 2.96s Doing md5 for 3s on 64 size blocks: 2931714 md5's in 3.04s Doing md5 for 3s on 256 size blocks: 2063380 md5's in 2.98s Doing md5 for 3s on 1024 size blocks: 956809 md5's in 3.03s Doing md5 for 3s on 8192 size blocks: 157650 md5's in 2.98s $ openssl speed sha1 Doing sha1 for 3s on 16 size blocks: 3088016 sha1's in 2.98s Doing sha1 for 3s on 64 size blocks: 2818497 sha1's in 3.00s Doing sha1 for 3s on 256 size blocks: 1814907 sha1's in 3.01s Doing sha1 for 3s on 1024 size blocks: 751942 sha1's in 2.98s Doing sha1 for 3s on 8192 size blocks: 116496 sha1's in 2.98s PBKDF2, which basically runs the hash function in a loop, can make a difference. But at the end of the day, a leaked password database is bad news, hashes or not. On Thu, Feb 25, 2010 at 11:31 AM, Michael Neal Vasquez m...@alumni.princeton.edu wrote: If I reread your statement, and take it as 70% of people's passwords suck -- I'd have to agree. I'd say though, for the remaining 30%, algorithm choice, even without salting, can make a difference. My password audits go much quicker when LM is enabled, vs NTLM. Same for MD5 vs SHA1. On Thu, Feb 25, 2010 at 9:07 AM, Dan Kaminsky d...@doxpara.com wrote: On Thu, Feb 25, 2010 at 10:39 AM, Michael Neal Vasquez m...@alumni.princeton.edu wrote: On Thu, Feb 25, 2010 at 8:05 AM, Dan Kaminsky d...@doxpara.com wrote: Sai, I see where you're coming from, but what are the most recent statistics on the effectiveness of hash cracking? Isn't it something like 70% of the passwords in the field can be cracked with a minimal amount of brute forcing? 70% ? Plain MD5 perhaps, but I don't think salted, or sha1, etc, have anywhere near such high success rates. The problem isn't in the algorithm -- it's in the passwords themselves. Salting helps in that the attacker can't amortize the work effort across the entire population, but at the end of the day, even PBKDF2 isn't going to do much against 1234567890 and its ilk. To put it another way, if EasyJet *did* have a breach, they couldn't very well say It's OK, because the passwords were hashed. ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
