Spoken Commands Crash Bank Phone Lines 178
mask.of.sanity writes "A security researcher has demonstrated a series of attacks that are capable of disabling touch tone and voice activated phone systems, forcing them to disclose sensitive information. The commands can be keyed in using touchtones or even using the human voice. In one test, a phone system run by an unnamed Indian bank had dumped customer PINs. In another, a buffer overflow was triggered against a back-end database. Other attacks can be used to crash phone systems outright."
Re:Good (Score:4, Interesting)
Especially if after pressing all possible combinations and you finally get to the part where it says "I'll connect you to a human being" the while system blows up and you have to start over. Which in my experience happens approximately 100% of the time.
Video of the talk (Score:5, Interesting)
You can you watch a video of the talk on YouTube [youtube.com] - or read the slides at BlackHat [blackhat.com].
Fairly interesting to see how buffer-overflows can occur in the most unlikely places.
Re:SQL Injection via voice? (Score:3, Interesting)
My money is on it not being purely by voice, but prepped with online banking. The attacker probably set their name or security question to Bobby Tables, then used the standard voice prompts to have the voice system attempt to say the name/security question/etc, which then ran the queries un-escaped
Re:One trick (Score:5, Interesting)
If you have the knack for it, whenever you encounter and IVR is to repeatedly scream a phrase at it, something like 'agent'. Good systems recognize the word and put you through to a human post haste. Shit systems, which are the predominant type, have something like a 30 or 60 second timeout before requiring human help.
Some systems may actually be responding to the vocal stress cues. In an effort to pretend to care, while minimzing the number of actual humans needed, some designs will prioritize the ones that sound increasingly angry so as to get them dealth with and out of the way. I find that it generally isn't difficult to convincingly emulate boiling rage, and(depending on whether the phone drone knows he is being dumped into a rage call or not) immediately switching to polite-and-businesslike when the human comes on usually works pretty well.
Re:One trick (Score:5, Interesting)
Re:Good (Score:5, Interesting)
I bitched about that once. Turns out, they are killing time while your screen comes up from their glacially-slow system.
seen it done. not new. (Score:5, Interesting)
Working in the industry, and having to read low level logs all of the time, I see this frequently.
People will call up, wait for a silence, and after 500ms start pumping down DTMF signals. Often they do this with seemingly random patterns 3-4 times before giving up.
often times they retry promps with longer and longer strings. This is old news.
I am guessing there is a wardialler in ther that is looking for specific systems at the other end. Sort of known phreak attacks.
Weird things like this exist and have existed for a long time. Hardware and software suppliers check for this now. We routinely check for stuff link this in dev and QA.
The submitter is doing nothing new, nothing unknown or even clever. These sorts of phreaks are older than I am. meh.
Re:Good (Score:4, Interesting)
[It's] a human who then asks you all of the same questions as the automated system that I really hate.
I have a supplier whose automated system asks for contract number and system ID's and the like. Once, my system was totally down and the different numbers I had were refused by the supplier's IVR. I remembered hearing that some IVR systems detect swearing. I quite deliberately swore a few times at the system, and it beeped and asked "Are you currently experiencing a severity-1 production outage, press one". I did and got a human immediately. I'll never again complain about their system . .
The elephant in the room - C (Score:4, Interesting)
The problem remains the C language. C (and C++) is the only remaining major language prone to buffer overflows.
This can be fixed. See "Safe arrays and pointers for C through compatible additions to the language" [animats.com]. This is a proposal for a "strict mode" for C which prevents buffer overflows. It's been discussed on Lambda the Ultimate, the C standard newsgroup, and the GCC development list, and with each round of criticisms, the design is tightened up.
This proposal includes a "strict mode", in which the rules are tighter, and ways to talk about the size of arrays. Non-strict code can call strict code, and vice versa. So there's a gentle migration path to all-strict programs, one source file at a time. It's an extension to C, not a new language. Some of the necessary features for this are already in C99 or are GCC extensions, so I'm trying to get this into GCC as an extension so it can be tried in the real world.
It's no longer acceptable to say that this problem can't be solved. It can. It just takes the will to solve it. Prodding from the security community will help.
Strict code is mostly about declarations. For example, the Linux "read" function, which is now declared int read(int fd, void* buf, size_t len); would be declared int read(size_t len; int fd, void_space (buf&)[len], size_t len); Instead of passing a pointer, you pass a reference to an array, a reference with an associated size. So the language knows how big the array is. Incidentally, the first "size_t len;" is a forward declaration of len. That's an existing but rarely used GCC extension. It's needed because so many C, UNIX, Linux, and POSIX APIs have the buffer param before the buffer size.
(For those few of you who know what a C99 variable length array parameter is, you'll wonder why this syntax differs from that. It's a long story. C99 VLA params are demoted to pointers at function entrance, losing the size info. It turns out nobody uses C99 VLA params; repeated searches have failed to find any of them in open source code. Also, Microsoft refused to implement them in Visual C/C++, they're incompatible with C++, and they've been demoted to an optional feature in the latest C standard draft.)