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.
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.
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.
buffer overflows
Not everyone on here is a programmer.
No colour or religion ever stopped the bullet from a gun
I'm not a programmer and I know what a buffer overflow is...
It's when you use too much polishing compound on your buffer and it squirts out everywhere and ruins the paint on the car, right?
Do not look into laser with remaining eye.
DNWTFV...
I'm sorry, but "shower scene" and "Dilbert" do not belong anywhere near each other.
I had an involuntary mental image that it'd be like the shower scene from Starship Troopers but with the Dilbert characters, and then I threw up a little bit...
Do not look into laser with remaining eye.
Meh, why not?
It fulfills the car-analogy requirement for this article at least.
No colour or religion ever stopped the bullet from a gun
Ever contemplate how much pizza you really eat, by volume?
Let "a" be the thickness of the crust, and let "z" be the radius.
So, the volume of your slice, depending on how it's cut, is a fraction of pi*z*z*a.
Do not look into laser with remaining eye.
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.
Press one if you'd like to see those links again.
"I like to lick butts!" by MobileTatsu-NJG (#32700246) (Score:5, Informative)
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.)