

Spoken commands crash bank phone lines - maskofsanity
http://www.scmagazine.com.au/News/315844,phonetic-attack-commands-crash-bank-phone-lines.aspx

======
raldi
I'm going to have to request a citation for the claim that it's possible to do
SQL injection via DTMF or IVR. The article doesn't seem to provide any
explanation as to how that might work.

~~~
patio11
As a past practitioner of Big Freaking Enterprise Apps who has seen the
sausage get made, and also as someone who has shot his own foot off with
telephony APIs, this does not cause me any doubt whatsoever. Here's a fairly
straightforward implementation:

String[] availableActions = ["raw SQL for read last payment date" , "raw SQL
for read current balance", ...]

String sqlToExecute = availableActions[toNumber(dataFromCaller)];

return new SQLStatement(sqlToExecute, bindParams).execute(); #Hah I am imune
to SQL injections because I used bind parameters; I am the awesome

I mean, clearly I've given you the ability to crash this method already,
right? (You can cause ArrayIndexOutOfBoundsException, trivially.)

There's all sorts of fun available if six months later a different team
updates the utility method that actually defines availableActions to, e.g.,
add in SQL which is only used by sysadmins, through the web interface.

~~~
wdewind
Can you explain this further? I'm sure I'm missing something obvious, but what
exactly would dataFromCaller be (I'm assuming the result of a function that
maps an analyzed audio sample [input] to a number), and how could I manipulate
it to cause the ArrayIndexOutOfBoundsException?

~~~
brazzy
By saying "six" when the system just listed options 1 through 5 to you - or,
as patio11 hinted, that may actually allow you to execute SQL statements not
inteded to be accessable to cutomers at all.

~~~
wdewind
Ah, I misunderstood because I read the misleading title, which implied that
input was human voice, not touch tone. Totally makes sense, thanks.

------
brown9-2
This "attack" seems to use DTMF only, which contradicts the title of the
submission.

------
dexen
Time and time again, don't `trust' user data -- sanitize it before passing to
subsystem or DSL. No matter how unprobable it seems for user to be able to
insert unexpected characters.

~~~
lmm
Don't "sanitize" either, it's next-to-impossible to get right. Treat anything
that came from user input as tainted (your language should be able to help you
with this), and never pass a tainted string to a database except as a
parameter.

~~~
evincarofautumn
Whitelisting works better than blacklisting, I think. You can accidentally
make a whitelist too permissive, but at least you can correct it after the
fact. A blacklist might never be restrictive enough, and you will end up
fighting a losing battle. So a function “sanitize :: Tainted a → Filter a b →
b” is acceptable as long as individual filters are secure.

~~~
patio11
I'm not sure I'm reading your notation right. Do I understand correctly that
you think two sanitization functions applied in sequence are safe if both
functions applied by themselves are safe? I think that that is true as a
mathematical statement but often gets explosively disproven in production
systems, because e.g. you can exploit different assumptions made by the
filters in ways which were not anticipated (to say nothing of formally proven
to be impossible), such that once-safe input becomes viable attack code.

For example, if you have both a) unicode canonicalization and b)
escape_single_quotes() running around your application, I really do not like
your chances of beating a fuzzer (plus, optionally, a pen-tester who
understands encoding issues).

~~~
evincarofautumn
Sorry, perhaps you may find “template<class A, class B> B sanitize(Tainted<A>
tainted, Filter<A, B> filter)” more readable. I was saying that “sanitize” is
fine in principle—it’s unexpected interaction between filters that’s
dangerous, as you say. The problem is that input filters _seem_ more
composable than they actually are. I think the best you can do in practice is
attack your code with a large number of random inputs and assert that the
expected properties hold.

