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.
oh for the days of 2600
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.
The computer equivalent of shouting "jump" at a stock broker who's out on a ledge during a massive margin call...
"Hello, welcome to abc trading. Please press 1 for customer services, 2 for finance and ##*?\\ for anything else."
User input needs to be filtered, and the interface should ONLY accept certain values (the known inputs) before moving onto the next stage of processing.
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.
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
So as far as I can gather the "SQL injection" relies on using the star key to enter a PIN which is converted to a numeric sequence that translates to true (1) or false (0). e.g. 1234*0, 1234*1
And what IVR is stupid enough to do this? The one that he wrote himself - there is absolutely no real world example of any of these vulnerabilities being real world vulnerabilities.
Anyone know which IVR systems they're targeting? I work at a mid-sized provider and am curious :D
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
The fingers you have used to dial are too fat. To obtain a special dialing wand, please mash the keypad with your palm now
I'll leave it as an excersize to catch errors (http://www.w3.org/TR/2002/WD-voicexml20-20020424/#dml6.1 -- vxml only/ I think he wanted maxspeechtimeout).
Many of the concerns are valid but not well explained. I also didn't see much mention of Speech-to-Text / Audio Mining. This focuses mainly on ASR
(automated speech recognition). Also, there isn't much mention the many diferrent ways these applications can be written (pure vxml / dynamically generated / non-vxml etc).
The main problem is that IVRs are more vulnerable than operators and systems. It is quite easy to brute force an IVR w/ a few digium cards and a bit of ANI spoofing. Just ask a coporate pbx tech. If they are paying attention, they should see these all the time (mostly trying to find a way to hijack free international long distance).
At the voice prompt, yell "Format c" followed by "yes!".
"at the tone please say your name" *BEEEEP* "admin"
"press 1 to make me your bitch"
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.)
this was in March....
I kid you not, I'm watching the embedded video on the web page with Firefox 15.0.1, NoScript (with partial temporary disables on the page), Adblocker, and adjust the volume control on the video.
Wouldn't you know it, my screens go black, the audio continues intermittently, and I couldn't CTRL-ALT-DEL my way out of it. I had to do a hardware reset.
Nice hack!
Some of the voice-driven menu systems I've encountered, will take you to an agent right away if you swear angrily at them. "Fuck You! Fuck You!" works pretty well.
It's funny, I know... I think they know that the automated system can't help a customer who is already enraged at it, and only a human has the chance to keep them from going and venting on the interwebs about it.
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
Their demo doesn't show anything useful at all.
I just inspected some IVR software and found that one of the exception handlers contained a Java statement System.exit()... it seemed feasible enough to reach this part as well... In general I would say, this kind of software is at the level of junior developers. Probably because it's seen (and paid for) as an afterthought.
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.