Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: SMS Banking
From: "Thor (Hammer of God)" <Thor () hammerofgod com>
Date: Tue, 9 Feb 2010 20:05:09 +0000

-----Original Message-----
From: Craig S. Wright [mailto:craig.wright () Information-Defense com]
Sent: Tuesday, February 09, 2010 10:54 AM
To: Thor (Hammer of God); pen-test () securityfocus 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 () hammerofgod com]
Sent: Wednesday, 10 February 2010 4:40 AM
To: pen-test () securityfocus com; full-disclosure
Cc: craig.wright () Information-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 () 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/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]