Date: Tue, 9 Feb 2010 20:32:44 +0000
From: "Thor (Hammer of God)" <Thor@...merofgod.com>
To: "craig.wright@...ormation-Defense.com"
	<craig.wright@...ormation-Defense.com>, "pen-test@...urityfocus.com"
	<pen-test@...urityfocus.com>, 'full-disclosure'
	<full-disclosure@...ts.grok.org.uk>
Subject: Re: SMS Banking

In line.

> "Exactly.  So, before the incident, you would have come up with Some
> Number
> and said, "this is your risk."  After the incident your number would
> (hopefully) change to Some Number + Some Other Number, and you could
> say
> "Oops.  Didn't think of that.  Sorry."
>
> Are you trying to be clueless? [R(t)-> 0] means that the system was
> inherently unreliable. That is no change before or after. I recommended
> a
> probability distribution that links to a financial model.

Well, if I arrive at clueless, it will definitely be because I tried.  Maybe you can teach me how to attain that disposition naturally.

So, ANY deployment of SQL server is inherently unreliable?  And the SMS model is also inherently unreliable. What system then is NOT inherently unreliable?  Might we assume that your own formula falls into this category?


> " Fine.  Let's do it this way then.  We'll have someone implement an
> SMS
> solution for banking that we don't have anything to do with.  I'll
> assess
> risk my way, you assess risk with your calculator.  Since *someone* has
> to
> pay, are you saying that you are willing to assume responsibility for
> financial losses when your numbers come out wrong?"
>
> Yes simply I will. In case you have not as yet had a clue, I stated
> reliability limits towards 0. That means the SMS solution is inherently
> insecure.
>
> "So which is it?  Is quantifying the probability of compromise "fairly
> simple using a formula" or is it "not an economic function pure and
> simple?""
> Both.

Typical.

> " Since *someone* has to pay, are you saying that you are willing to
> assume
> responsibility for financial losses when your numbers come out wrong?"
> I am working on a hedging instrument at present, and yes, where I am
> paid to
> model systems I will negotiate for losses.

Excellent.  Bring your checkbook along with your math.

> So where are all the lives being lost through a banking app?

They are not.  They will be when you start consulting to CIP.  Do us a favor though, test it out on your own country first.  But let me know before you do, my friends David and Greg are in AU.


>
> "Surely as the most highly certified security professional in the world
> you
> don't need me, a mere working stiff, to find you a sponsor."
> If you want me there, yes. I work by the hour, I am not going to waste
> time
> paying for this "opportunity". How about you come to an IEEE
> conference?

So, the most highly certified security professional in the world, and the greatest global mind in computer security refers to an open debate where you could defend formulas that have been publically ridiculed and openly called ignorant as a "waste of time"?  I don't need to pay you to substantiate my claims, sir.  You just did it for free.

t


>
> 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: Wednesday, 10 February 2010 7:05 AM
> To: craig.wright@...ormation-Defense.com; pen-test@...urityfocus.com;
> 'full-disclosure'
> Subject: RE: SMS Banking
>
> > -----Original Message-----
> > From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> > Sent: Tuesday, February 09, 2010 10:54 AM
> > To: Thor (Hammer of God); pen-test@...urityfocus.com; 'full-
> disclosure'
> > Subject: RE: SMS Banking
> >
> > First,
> > 'Thor', get me sponsored and I will be more than happy to debate you
> at
> > Defcon. Being in Au, it costs a little more for me to get there than
> a
> > simple interstate flight.
>
> Surely as the most highly certified security professional in the world
> you
> don't need me, a mere working stiff, to find you a sponsor.  As the
> greatest
> mind on the face of the globe, I'll leave that one for you to figure
> out.
>
> > I am happy to be an egoist. I am not an altruist, I invest, I do not
> > sacrifice. So no insult.
>
> No, we sacrifice for you.  Or will, that is, if you or your formulas
> have
> anything to do with real human safety.
>
> >
> > "Your "risk formula" is ridiculous." Why? How is IT different to all
> > other
> > aspects of life and the world. Why is it sacrosanct and unable to be
> > modelled? As for real experience, I have been doing this over several
> > decades. I may be teaching at CSU (csu.edu.au - gratuitous plug), but
> > that
> > is a side line, not what I do.
>
> Because it fails to take into account simple reality.  Risk is assessed
> as
> the result of human interaction, not calculated by some formula.
> Information security is about people as much as it is about technology.
> Your math fails here, and it fails grievously.  Have you ever been in
> love
> and acted out of that?  If so, then prove it mathematically.  Show me
> the
> variables that take into account human actions and reactions.
>
> > " What number would your formula have yielded 2 weeks before SQL
> > Slammer was
> > released?"
> > The same as at any time before the incident. SQL was a time degrading
> > function similar to the SMS example. The end result is a reliability
> > value
> > [R(t)-> 0] that approaches 0 and is prone to catastrophic failure.
> The
> > rate
> > of failure being related to the no. of access paths, no. of systems
> and
> > the
> > number of users.
>
> Exactly.  So, before the incident, you would have come up with Some
> Number
> and said, "this is your risk."  After the incident your number would
> (hopefully) change to Some Number + Some Other Number, and you could
> say
> "Oops.  Didn't think of that.  Sorry."
>
>
> >
> > "Where is the variable for unpatched systems?"
> > This is a function of both local and remotely accessible services.
> Some
> > of
> > these are dependant. This calculation has to account for each of
> these
> > services on the host as well as a vulnerability model for each
> service.
> > I am
> > publishing a paper on this later in the year.
> >
> > "What number do we plug in for malicious employee factorization?"
> > A prior data from similar industries, areas etc.
>
> So you just take historical data that may or may not have anything to
> do
> with anything, and apply it to your formula just because it is what has
> happened before?  Your source is from only reported incidents or
> discovered
> incidents?  Does it take into account anything of value?  Are you
> saying
> that with all of your education, and your globally superior intellect,
> the
> only value-add you bring is to tell us what has already happened in the
> past?  Seems a bit obvious if you asked me irrespective of the fact
> that
> it's basically worthless in the absence of an assessment.
>
>
> > Now, the real issue is that you (thor) seem to have this idea that
> > multiplying risk is a function of multiplying one made up number by
> > another
> > made up number. The 'expert' who cannot be wrong.
>
> Sure I can be wrong.  I'm wrong all the time - it gives me an
> opportunity to
> learn.  And I'm not the one who claims to be an "expert" Craig.  Let
> the
> readers of this thread look at my site and then yours to make that
> comparison.  The actual proof in one's capacity to learn is simple.  No
> one
> who has actually done this in a meaningful way would ever think that
> they
> can quantify risk with a formula when they haven't even bothered to
> qualify
> it.  A child can read volumes of books on how to ride a bicycle and
> immerse
> themselves in the physics behind balance and force, and the way the
> cilia of
> the inner ear works to communicate movement to the brain.  But they
> will
> NEVER learn how to ride until they get on and start pedaling.   Let me
> know
> when you stop peddling and start to pedal.
>
> >
> > The example spanning this is simple, a single SMS based function with
> > open
> > access. This example was a trivial example in modelling. Firewalls
> and
> > other
> > choke points make calculations simpler, multiple paths offer
> > complexity.
> > What I see from this is that a lack of understanding = a dangerous
> > level of
> > ignorance.
>
> I could not agree with you more, sir.  A lack of understanding does
> indeed
> equal a dangerous level of ignorance.  Which is why I so look forward
> to an
> open debate on this subject where I can hopefully intervene on the
> adoption
> of your formulas when human life is at stake.  Your formulas can't even
> be
> reliably assigned to the SMS model; to apply them to your CIP
> contributions
> will certainly be dangerously ignorant.
>
> >
> > Like it or not, security is an economic function, pure and simple.
> > There is
> > a cost for all actions and at the end of the day, somebody has to
> pay.
> > Perfect security is not a goal, optimal security is. They are not the
> > same
> > thing and the later requires better modelling.
> >
> > Welcome to the future, there will be math.
>
> Fine.  Let's do it this way then.  We'll have someone implement an SMS
> solution for banking that we don't have anything to do with.  I'll
> assess
> risk my way, you assess risk with your calculator.  Since *someone* has
> to
> pay, are you saying that you are willing to assume responsibility for
> financial losses when your numbers come out wrong?
>
> And you actually making my argument for me;  YOU are the one who stated
> this
> to my question, and I quote:
>
> T: "And just how do you come up with the probability of compromising
> the SMS
> function and the user authentication method?"
> C: "Actually, fairly simply using Bayes' formula."
>
> So which is it?  Is quantifying the probability of compromise "fairly
> simple
> using a formula" or is it "not an economic function pure and simple?"
>
> T
>
> >
> > 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: Wednesday, 10 February 2010 4:40 AM
> > To: pen-test@...urityfocus.com; full-disclosure
> > Cc: craig.wright@...ormation-Defense.com
> > Subject: RE: SMS Banking
> >
> > I'm looping in the FD list because often my replies don't make it to
> > Pen-Test, and this has hit a nerve with me.
> >
> > I've looked over your post at:
> >
> > http://gse-compliance.blogspot.com/2010/02/modelling-risk.html .
> >
> > Once I was able to get past the overwhelming egoism and self-
> > substantiating
> > claims of your contributions to the industry, I arrived at the
> > conclusion
> > that the only portion of the aforementioned page that is not complete
> > drivel
> > and even laughable to anyone who has actually worked towards
> > ascertaining
> > actual risk in production environments, is where you describe your
> own
> > words
> > as "ravings."  Ravings, of course, means "delirious, irrational
> > speech."
> >
> > I'm fine with you sitting back and gloating about the Security Hero
> > award
> > you got from Northcutt, but when I see that you are actually
> > contributing to
> > ANY level of Critical Infrastructure Protection, it makes me fear for
> > anyone
> > who might be counting on your presumed skillset to actually make
> > intelligent
> > decisions about risk where human safety is at stake.  Your "risk
> > formula" is
> > ridiculous.  What number would your formula have yielded 2 weeks
> before
> > SQL
> > Slammer was released?  Where is the variable for unpatched systems?
> > What
> > number do we plug in for malicious employee factorization?   More
> > importantly, where is the calculation for self absorbed snake-oil
> > selling
> > academics with no real experience using their calculator to come up
> > with
> > magic numbers that represent the risk of a nuclear power plant being
> > hacked?
> >
> > Since you are (self-described) as "currently the only GIAC GSE
> > (Compliance)
> > holder globally and the most highly accredited Global Information
> > Security
> > Professional" and thus (presumably, if only in your mind) the
> greatest
> > security mind in the world, how about accepting a challenge to an
> open
> > debate on the subject at Defcon?  People like you are dangerous and
> > need to
> > be exposed before someone in a position of power actually believes
> that
> > you
> > know what you are talking about.  Bring your abacus.
> >
> > t
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Craig S. Wright [mailto:craig.wright@...ormation-Defense.com]
> > > Sent: Monday, February 08, 2010 3:40 PM
> > > To: Thor (Hammer of God); pen-test@...urityfocus.com; security-
> > > basics@...urityfocus.com
> > > Subject: RE: SMS Banking
> > >
> > > " And just how do you come up with the probability of compromising
> > the
> > > SMS
> > > function and the user authentication method?"
> > >
> > > Actually, fairly simply using Bayes' formula.
> > >
> > > I have posted on this at:
> > > http://gse-compliance.blogspot.com/2010/02/modelling-risk.html
> > >
> > > The comment was that GSM itself can be made more secure if it is
> > > coupled
> > > with another means of securing the transmission.
> > >
> > > "if one can position one's self anywhere in the transmission
> chain."
> > > This is a select number of locations. It is not everywhere. Though
> > the
> > > number of locations may be large - it is not infinite. It is also
> not
> > > all
> > > points on the globe.
> > >
> > > As can be seen in the post, what the effect of an SMS only based
> > > solution is
> > > a time degrading function. This is, the longer that the SMS
> > application
> > > runs
> > > (alone), the greater the risk until eventually, the risk is
> maximised
> > > at
> > > certain failure.
> > >
> > > Adding a second function, such as a non-SMS based sub-function can
> > help
> > > to
> > > mitigate this, but a well chosen sub-function is more effective
> alone
> > > without the addition of the SMS measure and hence a better option.
> > >
> > > The SMS function alone can befit from a second function, but this
> is
> > > only
> > > warranted if the SMS function is an essential process for some
> > reason.
> > >
> > > Regards,
> > > ...
> > > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > > Information Defense Pty Ltd
> > >
> > >
> > > -----Original Message-----
> > > From: listbounce@...urityfocus.com
> > > [mailto:listbounce@...urityfocus.com] On
> > > Behalf Of Thor (Hammer of God)
> > > Sent: Tuesday, 9 February 2010 3:15 AM
> > > To: pen-test@...urityfocus.com; security-basics@...urityfocus.com
> > > Subject: RE: SMS Banking
> > >
> > > And just how do you come up with the probability of compromising
> the
> > > SMS
> > > function and the user authentication method?
> > >
> > > While little formulas may go well in meetings, this hardly helps
> the
> > OP
> > > with
> > > his question.  You also failed to note that the overall risk figure
> > you
> > > calculate has to be compared to something - what are you comparing
> it
> > > to?
> > > If P(Compromise) turns out to be 42, what does he do with that
> > > information?
> > >
> > > Regarding GSM, what "far more" information are you talking about?
> > The
> > > account number and PIN is all that is needed in the example given
> by
> > > the OP,
> > > and that is exactly what one would get from a GSM attack.
> > >
> > > You should also note that "compromising GSM" is completely
> > unnecessary
> > > if
> > > one does in fact have a select number of locations where the actual
> > GSM
> > > signal is redirected.  Cracking GSM itself does NOT require being
> at
> > a
> > > "select number of locations" if one can position one's self
> anywhere
> > in
> > > the
> > > transmission chain.
> > >
> > > t
> > >
> > > > -----Original Message-----
> > > > From: listbounce@...urityfocus.com
> > > > [mailto:listbounce@...urityfocus.com] On Behalf Of Craig S.
> Wright
> > > > Sent: Sunday, February 07, 2010 8:06 PM
> > > > To: 'Markus Matiaschek'; 'M.D.Mufambisi'
> > > > Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.com
> > > > Subject: RE: SMS Banking
> > > >
> > > > The solution needs to be based on risk.
> > > >
> > > > 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
> > > >
> > > >
> > > > The user can be compromised by Trojan apps, poor pins that are
> > pasted
> > > > to a
> > > > monitor etc.
> > > >
> > > > P(C.SMS) and P(C.PIN) are statistically independent and hence we
> > can
> > > > simply
> > > > multiply these two probability functions to gain P(Compromise).
> The
> > > > reason
> > > > for this is that (at present) the SMS and web functions are not
> the
> > > > same
> > > > process and compromising one does not aid in compromising
> another.
> > > With
> > > > the
> > > > uptake of 4G networks this may change and the function will not
> > > remain
> > > > as
> > > > simple.
> > > >
> > > > It may be possible to compromise GSM, but the truth is that this
> > must
> > > > be
> > > > done from a select number of locations and the attacker also
> > requires
> > > > far
> > > > more information than the PIN and account number. This makes the
> > > attack
> > > > far
> > > > more difficult and far costlier to the attacker.
> > > >
> > > > This also means that the attack has to be targeted in place of
> > > scripted
> > > > (as
> > > > many bots already are).
> > > >
> > > > On the other hand, the probability that an SMS only system can be
> > > > cracked is
> > > > simply the P(C.SMS) function and this is far lower than a system
> > that
> > > > deploys multiple methods.
> > > >
> > > > This SMS only means would not be a good means of authentication a
> > > user.
> > > > As a
> > > > secondary factor, SMS adds complexity. By itself, SMS is a poor
> > means
> > > > of
> > > > controlling risk.
> > > >
> > > > Regards,
> > > > ...
> > > > Dr. Craig S Wright GSE-Malware, GSE-Compliance, LLM, & ...
> > > > Information Defense Pty Ltd
> > > >
> > > >
> > > > -----Original Message-----
> > > > From: listbounce@...urityfocus.com
> > > > [mailto:listbounce@...urityfocus.com] On
> > > > Behalf Of Markus Matiaschek
> > > > Sent: Saturday, 6 February 2010 9:08 AM
> > > > To: M.D.Mufambisi
> > > > Cc: pen-test@...urityfocus.com; security-basics@...urityfocus.com
> > > > Subject: Re: SMS Banking
> > > >
> > > > Hi,
> > > >
> > > > I'd just like to make some comments, i didn't think about a
> > solution
> > > > for your problem.
> > > >
> > > > First of all i think that my Budi wibowo got something wrong
> > > regarding
> > > > who is sending the PIN.
> > > >
> > > > Second, GSM is cracked: http://reflextor.com/trac/a51 and can be
> > > > intercepted and decrypted. You should take this into account.
> > > >
> > > > Third i think the only farely safe way to make money transfers is
> > > with
> > > > transaction numbers, TANs. German banks send mobileTANs to
> > > > preregistered cell phone numbers to allow a transaction (through
> > > > online banking though).
> > > > A "three-way-handshake" with a mTAN should pretty much prevent
> > > > transactions through spoofed numbers.
> > > >
> > > > regards,
> > > > Markus Matiaschek
> > > > Absolute IT Consulting S.A.
> > > > San José, Costa Rica
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -
> > > > Securing Apache Web Server with thawte Digital Certificate
> > > > In this guide we examine the importance of Apache-SSL and who
> needs
> > > an
> > > > SSL
> > > > certificate.  We look at how SSL works, how it benefits your
> > company
> > > > and how
> > > > your customers can tell if a site is secure. You will find out
> how
> > to
> > > > test,
> > > > purchase, install and use a thawte Digital Certificate on your
> > Apache
> > > > web
> > > > server. Throughout, best practices for set-up are highlighted to
> > help
> > > > you
> > > > ensure efficient ongoing management of your encryption keys and
> > > digital
> > > > certificates.
> > > >
> > > >
> > >
> >
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be44
> > > > 2f727
> > > > d1
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -
> > > >
> > > >
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -
> > > > This list is sponsored by: Information Assurance Certification
> > Review
> > > > Board
> > > >
> > > > Prove to peers and potential employers without a doubt that you
> can
> > > > actually do a proper penetration test. IACRB CPT and CEPT certs
> > > require
> > > > a full practical examination in order to become certified.
> > > >
> > > > http://www.iacertification.org
> > > > -----------------------------------------------------------------
> --
> > --
> > > --
> > > > -
> > >
> > >
> > > -------------------------------------------------------------------
> --
> > --
> > > -
> > > Securing Apache Web Server with thawte Digital Certificate
> > > In this guide we examine the importance of Apache-SSL and who needs
> > an
> > > SSL
> > > certificate.  We look at how SSL works, how it benefits your
> company
> > > and how
> > > your customers can tell if a site is secure. You will find out how
> to
> > > test,
> > > purchase, install and use a thawte Digital Certificate on your
> Apache
> > > web
> > > server. Throughout, best practices for set-up are highlighted to
> help
> > > you
> > > ensure efficient ongoing management of your encryption keys and
> > digital
> > > certificates.
> > >
> > >
> >
> http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be44
> > > 2f727
> > > d1
> > > -------------------------------------------------------------------
> --
> > --
> > > -

_______________________________________________
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