Re: SMS Banking

["Thor (Hammer of God)" <Thor () hammerofgod com>]

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 () Information-Defense com]
> Sent: Monday, February 08, 2010 3:40 PM
> To: Thor (Hammer of God); pen-test () securityfocus com; security-
> basics () securityfocus 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 () securityfocus com
> [mailto:listbounce () securityfocus com] On
> Behalf Of Thor (Hammer of God)
> Sent: Tuesday, 9 February 2010 3:15 AM
> To: pen-test () securityfocus com; security-basics () securityfocus 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 () securityfocus com
> > [mailto:listbounce () securityfocus com] On Behalf Of Craig S. Wright
> > Sent: Sunday, February 07, 2010 8:06 PM
> > To: 'Markus Matiaschek'; 'M.D.Mufambisi'
> > Cc: pen-test () securityfocus com; security-basics () securityfocus 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 () securityfocus com
> > [mailto:listbounce () securityfocus com] On
> > Behalf Of Markus Matiaschek
> > Sent: Saturday, 6 February 2010 9:08 AM
> > To: M.D.Mufambisi
> > Cc: pen-test () securityfocus com; security-basics () securityfocus 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/