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.
I noticed that in the video, the sequence 1337 appeared regularly. So either phone systems are especially vulnerable to this sequence, or it is a fake video where they thought it would be 1337 to use that sequence.
The 127.0.0.1 in the top line makes me suspect even more that the video indeed is fake.
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
The commands can be keyed in using touchtones or even using the human voice.
To bad i'm very much tone deaf
Wow - surely you could find a way to work in a Cap'n Crunch whistle?
Three Squirrels
To bad i'm very much tone deaf
Get all the details in next quarter's 2600!
Set your phasers on "funky"!
Seriously, phone support? That's a waste of all time and effort. So is online chat support, email and talking to anyone in person if they even exist.
"All your PINs are belong to us!"
Have gnu, will travel.
buffer overflows etc
I'm a big retard who forgot to log out of Slashdot on Mike's computer! LOOK AT ME.
Penetration Testing?
Must not know of such things in India yet. Seriously behind China.
If humanity has any luck left this will spell the end of shitty automated phone systems (which is about 99.9% of them). With Windows as my bell weather, I'll not be holding my breath.
Nobody reckognizes TFA as being about phreaking? You know, this kind of stuff dates back ages. Kevin Mitnick even had the superpower to whistle nuclear missiles into flight... True Story(TM).
FCKGW 09F9 42
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.
are em minus f slash root
Permission Denied
sudo are em minus f slash root
no home directory
At the voice prompt, yell "Format c" followed by "yes!".
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.)
Must have been talking to my mother-in-law.
Planning to be moderated ± 1: Bad Pun.
China is confused on the subject. You mean you are supposed to pen test you own stuff, not just the competitors?
Learn to love Alaska
The subject line basically says it all, lol. Yeah, yeah, yeah payphones and voice maskers...whatever lol. As if someone wouldn't hear you yelling SQL commands into a pay phone, lol.