Re: [Full-disclosure] SMS Banking

[Sunnet Beskerming <info@xxxxxxxxxxxxxx>]

Hi all,

I don't normally weigh into mailing list arguments, especially not those 
spammed across multiple mailing lists (yeah, I know this reply does that, too), 
and it's hard to find the appropriate point to interject comments, but this 
exchange has stirred the blood and irritated me to the point of throwing out my 
own point of view.  I'm not sure if we have all just been trolled expertly, but 
it seems serious enough to reply.

Thor, the following isn't really directed at you, I just chose your message as 
the one to reply to.

First, some background.  It has been a number of years since I formally studied 
statistics and failure modelling, though I am fairly current on James Reason's 
human failures modelling as it applies to aviation and at least one variant of 
risk management modelling and mitigation (even if it is largely a crock the way 
it is implemented).  As a result, there may be some errors in my arguments 
below.

I read through the post that Craig has placed online and there are a couple of 
seemingly critical faults in the model that have a massive effect on the 
overall reliability / strength against attack / resilience / number of kittens 
per square inch saved that a system displays.

It looks like Craig has defined parts of his model too narrowly, claiming that 
the probability of compromise is only a factor of the risk of compromise of the 
SMS system and the user authentication methods, which he claims are independent.

They are, to a point, and this is where I think Thor has the edge and will 
ultimately triumph in any real world test.  The factors are related, since most 
SMS systems are utilised as a second channel of authentication, but ultimately 
all the critical communications for a transaction session pass through the 
user's web session, where they have already provided their static user 
authentication (it doesn't really matter if we talk about pRNGs, it's static 
for the purpose of the transaction session).  It also doesn't matter whether 
the SMS is provided as transaction authentication, second channel 
authentication, or whatever, it ultimately provides the financial institution 
with a means to try and make the user liable for any subsequent breach.

The common weak point is the computer system.

It could be argued that the system is really part of the user authentication 
method, being critical to the method actually working, but it doesn't really 
fit into Craig's formuala.  The P(compromise) he puts forward is more the 
probability of compromise of the system prior to the transaction commencing, 
since it can be considered completely independent from the computer system at 
this stage.

If the user has had their mobile stolen and the thief also happens to know 
their authentication details, the compromise is complete, and the thief can 
then authenticate happily and Craig's formula holds up.

The downfall is that if this doesn't take place and the system being used for 
the transaction has been compromised, then the model has failed.  It doesn't 
matter what the original probabilities were for the user authentication or the 
SMS system were, the fact that the computer system is compromised means that 
the probability of compromise is now 1. 

Pushing past this probability, the modelling used for expected system life 
(failure modelling) doesn't seem to match with what reality seems to indicate.  
To fit an exponential failure density function, it implies that any system is 
secure when initially released, rapidly becoming more insecure, to an 
inflection point whereupon the rate of insecurity increase tapers off over 
time, never becoming completely insecure.

Again, this is true to a point.  The problem is that the full failure model is 
not taken into account, merely the introduction of the lifecycle when the 
product comes out of Beta testing.  The system starts inherently insecure, 
gradually increasing in security during development, until at release, it is 
relatively secure.  Immediately following release, glaring errors are quickly 
found and this represents the exponential failure density function Craig puts 
forward.  This may or may not be a significant jump, but it does baseline the 
security of the system into the longer term.

A system that is maintained displays more of a sawtooth curve along this 
long-term period, ideally improving reliability following maintenance, but 
history has shown that the curve can trend towards more security or less, each 
time maintenance is applied.  If the system is not maintained, and even if it 
is, then it may be a significant period of time before its security is 
fundamentally broken.  At the point that security is broken, it can be 
considered that the system is completely failed.  With the key requirement to 
enact failure being knowledge and system accessibility, the moment that 
knowledge is public, or shared, then the system is inherently insecure.  Taking 
the overall system lifecycle (including development) into account, this gives a 
bathtub curve, with a sawtooth following system release and following 
maintenance activity.

The ASCII Insecurity vs Time curve.  

\                   /
 \  ____  ___|\----/
  \/    |/
 1 2    3     4    5

1 - Development and release - one of the most secure points in the product 
lifespan
2 - Craig's failure model - immediately post release, insecurity jumps as 
obvious issues are found, but then tapers off into maintenance mode
3 - System maintenance - system security is improved, but bugs are introduced 
that are found over time, returning security to previous levels
4 - System maintenance - reactive maintenance to a security problem (the uptick 
at the start), however the baseline system security is now more insecure
5 - Inherent Insecurity - security is fundamentally broken and either no 
maintenance is possible, or it is no longer maintained.  Sharing of knowledge 
makes any system implementation after this time inadvisable without other 
protections.

The problem faced is how do you know when the curve is going to tick up (or in 
Craig's models shoot down) at the end of the viable secure lifespan?  Thor's 
argument is that you don't.  It is effectively impossible to reliably predict 
when this will take place, but until it does it makes the modelling Craig puts 
forward seem relatively viable.  The downside is that it doesn't work as a 
reliable predictor, and you're going to be left stuck when the uptick takes 
place, having been encouraged to place faith in a model that doesn't appear to 
replicate the overall lifecycle effectively.

The slanging match that evolved has seemed to hinge on this.  Craig argues that 
he can reliably predict system security using his models, while Thor says he 
can't.  In the testing proposed, Craig asserts that his model will work (even 
though it has just been shown to only affect a very small section of the 
overall product lifecycle), while Thor's goal is to bring the end of the 
bathtub curve (the uptick) as far forward as he can.  With the vagaries and 
difficulties associated with development, and the problem that no one really 
understands the security domain well enough to have a really secure product 
that is actually usable, backing Thor and his team would be a very safe bet.  
Even if the bathtub curve can't be completely shortened, enough of an uptick 
can be caused (the sawtooth bits) to exceed any threshold set by Craig.

Ad hominem attacks aside, I think Thor definitely has the upper hand in this 
particular case.  It is not possible to effectively predict when these upticks 
in insecurity are going to take place, nor how significant they are going to 
be, only that they will take place (the old when, not if argument) and this has 
a real, definite effect on system security predictability.  For all the fudge 
factors involved, you might as well use the Drake Equation as a quantitative 
predictor of system security.

Just some discussion points, that's all.

Carl

info@xxxxxxxxxxxxxx
 

Since we're spamming internet posts, the following discuss some of the issues 
with trusting SMS details just a little too much:
[1] - http://www.beskerming.com/commentary/2005/10/31/65/'Tis_a_Fragile_Thing
[2] - http://www.beskerming.com/commentary/2006/01/02/74/An_Inauspicious_Start
[3] - 
http://www.beskerming.com/commentary/2007/05/25/96/Free_Flight_Deal_Exposes_Customer_Data

On 10/02/2010, at 4:09 AM, Thor (Hammer of God) wrote:

> 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@xxxxxxxxxxxxxxxxxxxxxxx]
>> Sent: Monday, February 08, 2010 3:40 PM
>> To: Thor (Hammer of God); pen-test@xxxxxxxxxxxxxxxxx; security-
>> basics@xxxxxxxxxxxxxxxxx
>> 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.

... irrelevance cut for brevity ...

>>> 
>>> 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
>>> 

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