Message-ID: <optid.5657cf2550.A876923A2C9CD44BA76505F58ECF089D03FEE57C@gandalf.optimum.bm>
Date: Wed, 10 Feb 2010 19:01:46 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: 'full-disclosure' <full-disclosure@...ts.grok.org.uk>
Cc: "craig.wright@...ormation-Defense.com"
	<craig.wright@...ormation-Defense.com>
Subject: FW:  SMS Banking

So, looks like SANS has dumped you Craig.  Anyone else you want to get to set the system up for you?

t

> -----Original Message-----
> From: Stephen Northcutt [mailto:stephen@...s.edu]
> Sent: Wednesday, February 10, 2010 10:56 AM
> To: craig.wright@...ormation-Defense.com; Thor (Hammer of God)
> Subject: RE: [Full-disclosure] SMS Banking
>
> Sorry, I do not have time for this, please do not let this spill over
> into
> our advisory board list either.
>
> Stephen Northcutt, President
> The SANS Technology Institute (www.sans.edu)
> 808.823.1375
>
> Register today! Over 30 infosec courses at SANS 2010 - March 6-15,
> Orlando
> FL http://www.sans.org/info/51269
>
> "This is the way you need to learn: roll up your sleeves, dig in to the
> fundamentals and the nitty-gritty  technical details, and then go
> 'hands-on'
> to practice and reinforce what you've been taught." - Joseph Price, DoD
>
>
> -----Original Message-----
> From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> Sent: Wednesday, February 10, 2010 1:54 PM
> To: 'Thor (Hammer of God)'; 'full-disclosure'
> Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.com;
> stephen@...s.edu; 'Jeff Frisk'; 'Ben Wright'
> Subject: RE: [Full-disclosure] SMS Banking
>
> " You are changing the bet in mid-stream "
> Not at all. This was and is the bet. The initially proposed 2 tasks
> remain
> unchanged.
>
> The statement on SMS was that this is a time degrading risk function.
> That
> is, the proposed SMS solution would become less secure over time. The
> longer
> it ran, the more attacks. It would also be a function of users, the
> more
> users, the less secure. In case you cannot understand what the SMS
> quote you
> have means, it simply means that adding an independent 2nd factor
> lowers the
> inherently high risk of a purely SMS based system.
>
> "The risk of deploying any given solution takes into account FAR too
> many
> real-world elements than any formula can address. "
> The SMS formula is not the be all - it was a simple extrapolation based
> on a
> highly insecure proposal. My model as I have put it is an expert
> system. The
> risk associated with each application on a system is derived as with
> dependence and path.
>
> Please as stated, choose the 100 software applications.
>
> Regards,
> ...
> Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> Information Defense Pty Ltd
>
>
>
> -----Original Message-----
> From: Thor (Hammer of God) [mailto:Thor@...merofgod.com]
> Sent: Thursday, 11 February 2010 2:54 AM
> To: craig.wright@...ormation-Defense.com; 'full-disclosure'
> Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.com;
> stephen@...s.edu; 'Jeff Frisk'; advisory-board-open@...ts.sans.org;
> 'Ben
> Wright'
> Subject: RE: [Full-disclosure] SMS Banking
>
> Outstanding.  Things to take into account while drafting the contract:
>
> First and foremost, the most important question, followed by a
> subsequent
> statement addresses this:
>
> > Code vulnerabilities is but a single risk measure (see below for
> where
> > this > fits). My Question to Tim is are you implying that you cannot
> do
> this?
> > Knowing the likelihood of code vulnerabilities and the rate comes to
> > patching and hence implementation issues. I am stating that I can
> model
> > this. I will put my reputation etc on the line (as well as a large
> > quantity of cash) on the assertion that I can model the risk of
> software
> within
> > a set > confidence bound given the a prior information on the
> product,
> user
> > base and such other information against a qualitative determination.
>
> You are changing the bet in mid-stream.  You are now saying you can
> model
> likelihood of code vulnerabilities based on past discoveries.  Several
> points:
>
> Code vulnerabilities does not equal risk.  They are code
> vulnerabilities.
> You said you could predict the "risk" of an SMS banking solution with
> your
> formula.  I say that you, unequivocally, cannot, and that such a
> statement
> is ridiculous.  Hence the bet.
>
> The risk of deploying any given solution takes into account FAR too
> many
> real-world elements than any formula can address.  For instance -
> Let's take a system; any system that allows unencrypted login via the
> internet.  Your formula cannot determine "risk" in any way.  If the
> system
> is storing the names of the Seven Dwarfs, then there is not much risk.
> If
> the same system allows one to shut of grid power to NYC, then the risk
> is
> increased.  To the point of you being able to "predict" what future
> code
> vulnerabilities are, I'm even dubious on that.  You can indeed create a
> model, but will it be accurate?  No - you have no idea what
> vulnerabilities
> lie in wait.  Will it be statistically accurate based on math?  I don't
> know, and more importantly, I don't care.  Whatever "number" you come
> up
> with will be worthless in its application to risk without other
> factors.
>
> My $100,000 bet, that I accept, is based on the fact that your results,
> whatever they are, will be WRONG when ascertaining true risk, which
> this is
> all about.  I am extremely gratified that this has gotten the attention
> that
> I desired it would, because it brings to light the true dangers of
> having
> people with your mindset involved in critical infrastructure protection
> -
> the OTHER reason I got involved with this.  If you are so eager to give
> away
> (which you will) $100,000 of your money to support such a foolhardy
> stance
> such as calculating risk based on past software vulnerabilities, what
> would
> you do when making the same decisions that protect water and power
> systems?
> To that end, I am happy to see not just your money, but your
> "reputation" as
> you put it, at stake here.
>
> The results I generate will have nothing to do with whatever numbers
> your
> model spits out.  The bet is not if you can come up with a formula that
> produces numbers.  The bet is that THOSE NUMBERS will be proven wrong.
> You
> cannot gauge risk with the "simple formula" you posted on your site.
> Period.  THAT sir, is the bet, and that is the bet that you already
> accepted, in writing.
>
> Breaching the system that you put up further has nothing to do with you
> calculating risk.  But that's fine with me.  A few questions to the
> board on
> SANS before I get into that.  I'm assuming that Craig's enlistment of
> your
> input is sanctioned?  Craig speaks for you in regard to having your
> students
> be the ones that set up a system that gets hacked into and $100,000
> lost?
> Am I to understand that SANS endorses Craig's Magic Risk Formula, and
> that
> this is something you recommend your clients/customers use to determine
> risk?  I need to know this in order to ensure that all the parties are
> properly referenced in my acceptance speech.  I further suppose it
> would be
> rude not to extend invitations to the parties involved to the party
> following.
>
> Since SANS is involved, at least by proxy and extension, shall I assume
> that
> you (Craig) will embrace SANS' raison d'être when building this system?
> I
> ask because this is where the "Thor can do whatever he wants" again,
> that is
> already in writing, comes in.  SANS's exists to help companies
> determine
> risk and analyze the security of systems in the "real world."  If
> people
> didn't configure systems incorrectly, deploy unpatched systems, and
> write
> poor code, SANS wouldn't exist.  I'm assuming that the historical data
> you
> presume to include in your Magic Number will be extended to this
> installation?  Meaning, one can expect to see the typical
> vulnerabilities
> found in deployments present in this system?  Or do you intend to
> create an
> uber-hack-proof system to substantiate your reputation, thus obviating
> the
> usefulness that SANS as an organization provides?  Clearly, if all
> systems
> in the world were set up how one might assume you will set up yours,
> there
> would not be a need for SANS anymore (if that idea is taken to the
> extreme).
> In fact, the need to calculate risk would be obviated.  But I supposed
> that
> is another story.
>
> Not only will I take your money, and ruin your reputation in this bet,
> but
> I'll tell you how I will do it UP FRONT.  Will that be fair enough?  Go
> ahead.  Set up your system.  If I have someone show up at the door with
> a
> shotgun and ask for the hardware, do I win?  Or will you cry "Hey,
> that's
> not fair.  Do over!"  Do you not think the criminals of the world do
> things
> like that?  Where in your formula do you plug that in?  Do you even
> know
> what the majority of the breaches in the world are from?  What about
> when I
> call a student and say "Hey dude.  There's $25,000 cash in it for you
> if you
> give me the admin password."  Would you cry foul?  Where in your
> formula do
> you plug that eventuality in?  Don't forget that you said "Thor can do
> whatever he wants."
>
> We don't need to bother with the 100 packages.  Bring in your SANS
> students,
> assuming you speak for SANS since you looped them in on the Full
> Disclosure
> list, and presumably trust you enough to weather the backlash of their
> students being the ones to configure the system that will be hacked,
> configure your system, and put it up.  Hell, Craig - I don't even care
> if
> you turn it on; just leave the check taped to the hard drive (I'm being
> facetious of course on that part - I just can't help but have fun with
> this.)
>
> To keep it even more simple, and so everyone here sees, this is what I
> will
> disprove beyond a shadow of a doubt.  I quote you directly:
>
> "Where a system uses an SMS response with a separate system (such as a
> web
> page), the probability that the banking user is compromised and a fraud
> is
> committed, P(Compromise), can be calculated as: P(Compromise) =
> P(C.SMS) x
> P(C.PIN)
> Where: P(C.SMS) is the probability of compromising the SMS function and
> P(C.PIN) is the compromise of the user authentication method"
>
> That is the "probability of compromise."  COMPROMISE.  Not "model that
> just
> might predict software code vulnerabilities."  I will PROVE that your
> figure
> is WRONG and in the process, PROVE that your formula cannot be used in
> any
> meaningful way,  Period.
>
> Please let me know when you've got the contract ready.
>
> T
>
>
> > -----Original Message-----
> > From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> > Sent: Wednesday, February 10, 2010 12:22 AM
> > To: Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; 'full-disclosure'; security-
> > basics@...urityfocus.com; stephen@...s.edu; 'Jeff Frisk'; advisory-
> > board-open@...ts.sans.org; 'Ben Wright'
> > Subject: RE: [Full-disclosure] SMS Banking
> >
> > Hi Again Thor/Tim and now others,
> > I have added a few people to this email. As a summary to those
> joining,
> > "Thor" (really Tim) has the notion that you cannot quantitatively
> > measure
> > information system risk and thinks Bayesian statistics, computational
> > chaos
> > and heteroscedastics (my fields) cannot measure risk.
> >
> > From the "discussion" that has ensued, Tim and I have ended in a
> gamble
> > where I shall be using the my skills in math and those of both
> > practical
> > experience and importantly all I have learnt from SANS over the many
> > years
> > against anything he wishes to being to the table.
> >
> > There is some information included below, but as a summary, myself
> and
> > another party will measure the risk of software and systems. This
> will
> > be
> > 100 software products and 50 systems to be independently deployed.
> >
> > Code vulnerabilities is but a single risk measure (see below for
> where
> > this
> > fits). My Question to Tim is are you implying that you cannot do
> this?
> > Knowing the likelihood of code vulnerabilities and the rate comes to
> > patching and hence implementation issues. I am stating that I can
> model
> > this. I will put my reputation etc on the line (as well as a large
> > quantity
> > of cash) on the assertion that I can model the risk of software
> within
> > a set
> > confidence bound given the a prior information on the product, user
> > base and
> > such other information against a qualitative determination.
> >
> > I have stated an independent third party will configure systems.
> > Neither Tim
> > nor I will set the systems up. This will be done correctly without
> > bias. I
> > have added Stephen to this discussion as I will be proposing an
> > exercise for
> > SANS Students. I will elaborate this later. The basic gist is that
> SANS
> > conference attendees and students generally could be involved. The
> idea
> > is
> > that neither party to the test will have an insight or knowledge that
> > exceeds the others from any unfair means.
> >
> > I will up the bet to the 100k amount if this is Tim's desire. We will
> > set
> > this as an escrow. That is, an independent party (merchant bank) will
> > hold
> > the money. We each pay in advance. The money will be held earning
> > interest
> > until this exercise is complete. Ben is included in this email as he
> is
> > one
> > of the most IT savvy and security knowledgably attorneys around. He
> is
> > NOT
> > my attorney, but he knows more than enough to (for valid
> consideration
> > that
> > I will fund) set the escrow conditions.
> >
> > Tim states below, "they will be 100% vulnerable to immediate
> > "exploitation"
> > My question to him is are you stating that the systems will be 100%
> > vulnerable? Is this your response or would you like to actually test
> > the
> > system?
> >
> > I will give Tim an out or at least an advantage if he wishes. I will
> > still
> > do all I have stated, but I will also give him an additional option.
> > This
> > is, I will configure a server running a BI (Business Intelligence)
> > application and Database accessed over the web with an SSH server for
> > admin
> > access and management. If either I fail to predict risk within a 95%
> > confidence interval OR you breach this system in the time period (a
> > whole 6
> > months), I lose the bet.
> >
> > As stated, the money will be escrowed. Once started, we each put our
> > money
> > where our mouth is so to speak. If you EITHER predict correctly OR
> > compromise a single system - you (Thor/Tim) win. Otherwise - Tim has
> to
> > admit error.
> >
> > This has escalated to a US$ 100,000 bet. The contract will be
> > formalised,
> > but this is an offer (in fact, the other offers are also accepted at
> > lower
> > values, but we each have too much testosterone).
> >
> > There are two components;
> >
> > 1     A selection of software products are tested using both
> processes,
> > that is I use a model for the risk of these products, and "Thor" can
> > make up
> > whatever guesses he wishes. We model (or "Thor" guesses, pulls from a
> > hat...) the vulnerabilities over a time period. The number of bugs in
> > software as well as the risk are to be presented as a monthly
> estimate.
> >
> > 2     We model a few systems (say 50). We can use Honeypots (real
> > systems
> > set to log all activity without interference) run by an independent
> > party to
> > each of us. I use probabilistic models to calculate the risk. "Thor"
> > does
> > whatever he wants to test these, audit them etc and predict risk.
> These
> > systems are to be logged and all the data recorded. The full rules
> and
> > restrictions, setup processes etc will be incorporated into the
> > contract.
> >
> > I put my knowledge from Bayesian Statistics, Computational Chaos,
> > financial
> > modelling and heteroscedastics that is coupled with around 30 SANS
> > courses/certifications and all the other bits against Tim's arsenal.
> >
> > Part 1
> > Tim has to select 100 commonly deployed software products. I will not
> > intervene, but I will have these challenged if they are NOT commonly
> > deployed. Hence CC'ing the SANS Advisory Board. I propose these
> > individuals
> > as the people who can veto a choice if the software is obscure.
> >
> > I shall be listing these in the contract that we will each sign as a
> > deed.
> >
> > Regards,
> > ...
> > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > Information Defense Pty Ltd
> >
> >
> > From: Thor (Hammer of God) [mailto:Thor@...merofgod.com]
> > Sent: Wednesday, 10 February 2010 5:42 PM
> > To: craig.wright@...ormation-Defense.com; Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.com
> > Subject: RE: [Full-disclosure] SMS Banking
> >
> > See my follow up email first.
> >
> > Are you asserting that your entire basis for what "risk" is comprised
> > of is
> > the number of new vulnerabilities found in code?   Risk=code
> > vulnerabilities?  Please tell me you know more about this industry
> than
> > that.   Actually, DON'T tell me that.  I don't want to start to feel
> > more
> > sorry for you than I already do.
> >
> > We don't need six months.  Pick whatever 100 you want.  Come up with
> > your
> > risk factor.  I'll deploy them, and they will be 100% vulnerable to
> > immediate "exploitation" and I'll laugh at your "risk figures" all
> the
> > way
> > to the bank.    This is getting better by the minute.
> >
> > Care to up your bet?  I'll wager 4:1 for you.  Let's make it my $100k
> > to
> > your $25k, even though you've already set the terms and the amount in
> > writing previously.  I'm happy to amend this.
> >
> > t
> >
> > From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> > Sent: Tuesday, February 09, 2010 10:28 PM
> > To: Thor (Hammer of God); Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.com
> > Subject: RE: [Full-disclosure] SMS Banking
> >
> > I will happily do this.
> >
> > "That it can be hacked, or will be hacked"
> > Anything CAN be hacked.
> >
> > Software first. Choose 100 common software products. I will define
> > scale
> > here first. This will be number of vulnerabilities (new) that are
> found
> > in
> > each piece of software each month. This will also be related to the
> > common
> > metrics for the level of the vulnerability. This will be for 6
> months.
> > Choose the number of vulnerabilities and the impact of each of these
> > for 6
> > months. It has to be commonly run software with a user base that I
> > cannot
> > count on one hand.
> >
> > My predictions will be for these products and will have a confidence
> > bound
> > set at 95% (or alpha=5%).
> >
> > "I further assume that the "loser" will be financially responsible
> for
> > the
> > "audits" done my way."
> > Are you saying that you will pay MY fees when you lose?
> >
> > "won't look at the software code"
> > When you can get MS to give me their code this may be an issue, but
> it
> > is
> > not as yet.
> >
> > Regards,
> > ...
> > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > Information Defense Pty Ltd
> >
> >
> > From: Thor (Hammer of God) [mailto:Thor@...merofgod.com]
> > Sent: Wednesday, 10 February 2010 3:59 PM
> > To: craig.wright@...ormation-Defense.com; Valdis.Kletnieks@...edu
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.com
> > Subject: RE: [Full-disclosure] SMS Banking
> >
> > Now you're talking.  But first let's work up an actual contract.
> > Neither of
> > your components define anything.  When you say that you are going to
> > predict
> > "risk" with your  magic formula, do you mean if the software has
> > vulnerabilities?   That it can be hacked, or will be hacked?
> >
> > Be sure to define this properly and definitively - if you end up
> saying
> > that
> > a system has a 1% change of being hacked, and I (or my auditors) hack
> > it,
> > would you claim you were "right"?  I question if you can even define
> > the
> > parameters of this bet, much less apply your formulas, but we'll see.
> >
> > I also want to know what "scale" you plan to use.  So far, even
> though
> > I've
> > asked, you've not provided what the "answer" to your formula is, or
> how
> > it
> > will be applied.   I'm assuming, unless you are going to change your
> > tune
> > which I wouldn't doubt, that you won't look at the software code or
> > threat
> > models, but rather apply your formulas.  I further assume that the
> > "loser"
> > will be financially responsible for the "audits" done my way.
> >
> > I'm more than happy to take your money, and I look forward to doing
> > so.
> >   Since one of your masters degrees is in law, I'm assuming you can
> > clearly
> > define the terms of the contract.    I will, of course, insist upon a
> > contract, and I hope you won't mind that I have my own attorney look
> it
> > over.    I'm not immediately trusting of the competence of one with a
> > doctorate degree and multiple masters degrees who can't spell
> > "technology"
> > or "experience" correctly on his on-line CV.
> >
> > You are officially "on."  And I'm looking forward to it.
> >
> > t
> >
> >
> >
> > From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> > Sent: Tuesday, February 09, 2010 7:41 PM
> > To: Valdis.Kletnieks@...edu; Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; 'full-disclosure';
> > security-basics@...urityfocus.com
> > Subject: RE: [Full-disclosure] SMS Banking
> >
> > I have a simple answer to this. Forget the debate, rhetoric is not a
> > scientific method of determining truth.
> > "Thor" wants a challenge, let's have one - a real one and not one
> based
> > on
> > verbalisations, abuse and unfounded assertions.
> > I suggest two components;
> > 1       A selection of software products are tested using both
> > processes,
> > that is I use a model for the risk of these products, and "Thor" can
> > make up
> > whatever guesses he wishes. We model (or "Thor" guesses, pulls from a
> > hat...) the vulnerabilities over a time period. The number of bugs in
> > software as well as the risk are to be presented as a monthly
> estimate.
> > 2       We model a few systems (say 50). We can use Honeypots (real
> > systems
> > set to log all activity without interference) run by an independent
> > party to
> > each of us. I use probabilistic models to calculate the risk. "Thor"
> > does
> > whatever he wants.
> > Each of the predictions is published by all parties. The one who is
> > most
> > accurate wins. Fairly simple?
> > I will even give a handicap to "Thor", I will offer to predict within
> a
> > 95%
> > confidence interval and that for me to win, at least 90 of the 100
> > software
> > products and 45 of the 50 systems have to lie within my predicted
> range
> > that
> > I calculate and release. "Thor" has to simply guess better than I do
> no
> > matter how far out he is.
> > I will put up $10,000 Au for my side. Let's see if "Thor" has
> something
> > real
> > to offer.
> > Regards,
> > ...
> > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > Information Defense Pty Ltd
> > _____________________________________________
> > From: Valdis.Kletnieks@...edu [mailto:Valdis.Kletnieks@...edu]
> > Sent: Wednesday, 10 February 2010 7:03 AM
> > To: Thor (Hammer of God)
> > Cc: pen-test@...urityfocus.com; full-disclosure;
> > craig.wright@...ormation-Defense.com
> > Subject: Re: [Full-disclosure] SMS Banking
> > * PGP Signed by an unknown key
> > On Tue, 09 Feb 2010 17:39:39 GMT, "Thor (Hammer of God)" said:
> > > how about accepting a challenge to an open debate on the subject at
> > Defcon?
> > "Alright folks just make yourself at home, Have a snow cone and enjoy
> > the
> > show"
> >                                 -- Webb Wilder
> >
> > * Unknown Key
> > * 0xB4D3D7B0
>

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

Powered by blists - more mailing lists