Slashdot Mirror
Spoken Commands Crash Bank Phone Lines
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."
I hate those automated prompts.
How is the turing test doing for social engineering an automated system?
Maybe the system commited suicide after listening to those humans and just decided it was not woth it anymore.
You decided to link to explanations of touch-tones and buffer overflows? On Slashdot? Really?
And yet the article basically parrots the summary with no more information.
To hear the PINs of our other customers, please press 1, or say "yes" now.
I'm sorry, but your opinion seems to be wrong.
"In one test, a phone system run by an unnamed Indian bank had dumped customer PINs" Sounds like a SQL injection attack, via voice. Lol. Little Bobby Tables strikes again.
Wonder of something like this happened.
You can you watch a video of the talk on YouTube - or read the slides at BlackHat.
Fairly interesting to see how buffer-overflows can occur in the most unlikely places.
If a square is really a rhombus, why aren't all triangles purple?
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.
Long Live Captain Crunch!
Heh. For some reason this reminds me of the "shower scene" from the very first episode of Dilbert (the animated series), where Dogbert is attempting to hack Dilbert's voice-activated shower temperature control.
http://www.youtube.com/watch?v=7MqhBL9eEts
To bad i'm very much tone deaf
Get all the details in next quarter's 2600!
Set your phasers on "funky"!
"All your PINs are belong to us!"
Have gnu, will travel.
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.
Signature v3.0, now with 42% less memory usage.
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". 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.)