Oh dear...
People not bothering to sanitise their input...
Miscreants can crash or infiltrate banks and help desks' touch-tone and voice-controlled phone systems with a single call, a security researcher warns. Rahul Sasi, who works for iSight Partners, said audio processing algorithms in office telephone networks and speech-driven command software are liable to crash when bombarded …
..who thinks these security bod's are quite often more interested in self promotion/scare mongering than actually going about fixing things. Do these people want standing ovations or some kind of Nobel prize for their work? I find bugs all the time, do I jump up and down sharing it with everyone hoping that I'm going to become more famous and earn more money from it? Nope.
These sort of things are usually significantly oversold to an IT press whose readership really want big business and in particular banking to be show up as a bunch of incompetents. The trouble is that while very important research is done, the overclaiming of the significance of the research leads other security professionals to presume that everything is overclaimed. Anyone who knows anything about banking IT would have Ross Anderson at the top of their list for people to help defend them in court, but whenever his name is trotted out alongside a report would think something along the lines of "what's actually been done, rather than what has been claimed?"
"what's actually been done, rather than what has been claimed?"
Yep, I fail to see any evidence of PIN exposure or SQL injection in that video.
He has an account with PIN 31337. It's already his account. OK, the system bizarrely applies arithmetic on the input - 31337 * 1 *1 *1 = 31337 (woo, a match!), 31337 *1 *1 *1 *0 = 0 ( no match - wowsers).
OK, the system should be dealing with the PIN as a string. The error is in dealing with it as a number. That arithmetic is performed does not imply SQL injection - it could just as easily be an 'intelligent' string to integer conversion.
seriously? I know people like to play devils advocate but this is silly. Why would anybody implement arithmetic (think how hard this is to do) on pins vs the very simple possibility that pins end up in a query such as:
select * from Accounts where PIN = 31337 * 1 *1 *1
For the record, when testing parameters for injection the first approach is indeed to use math operators and see if they get evaluated. There is no legitimate reason why these would be evaluated other then if they end up in a sql statement in raw form. The fact that it's a blind injection doesn't make it any less dangerous because you are very well known methods of obtaining table and field names using this boolean result. There are automated tools designed for this.
When I get a cold caller, who assures me his name is "Simon", what are the chances of sending the right tones/commands to his voice-recognition system such that his computer's mouse will rise up and strangle him?
I'm sure that whoever created these autodiallers and VR systems will have programmed in such a back-door (at least, just as soon as they became it's targets - maybe in the v1.1 release). I guess they're keeping that information to themselves.
Well, I bet a lot of the phone systems won't deal correctly with the DTMF tones for 'A' 'B' 'C' and 'D' (the original DTMF keypad had four extra keys on the right side to make a 4x4 grid -- I remember the phone we had as a kid after our dial phones were replaced having those keys) In my first fulltime IT job I was at a hospital and we had an local numberic pager system that hung off the phone system and you sent DTMF codes to display on the pager. The additional codes (which you couldn't get from the phone keypads, but a modem would generate) displayed interesting symbols (not the letters abcd) on the 7-segment displays on the pagers. We used this as a prank on a colleague by making his pager display odd messages... Ahhhh the old days.....
The article should be marked at advertising/marketing ... there's no real story here. If you send crap to a system that is not build properly bad things can happen ...
In next weeks instalment, don't invite strangers into your home ... as you could put yourself in danger and they might steal from you. In October no doubt they'll be an article about the dangers of crossing the road without looking both ways ..
Out of the box thinking indeed. This article is about automated phone systems. Why would uk companies run their automated systems in India? And if they did, what difference would moving the servers here make?
Still, why let logic (or reading the article) get in the way of xenophobia...
Change is a goal in itself - Companies move the servers to india cause it's cheaper (and to teach the IT-bods a lesson perhaps), then they move them back home again because it's more effective; with enough churn like that the organisation can grow at a steady 5% per year yielding new career opportunites for everyone involved.
- with enough "change" one cannot compare the books from year to year either, which is really convenient if one is working in f.ex. finance.
HSBC has a great system.
Computer logins have Forgotten Password? prompts. Well HSBC is just as handy.
If you know the card holders name (it's printed on the card!), access a convenient genealogy web site, ascertain the card owners date of birth and Mother's maiden name, then call Customer Service (the free 800 number is also on the card) .,, and Bingo!
Banks call it security.
As Rahul Sasi himself says in the PDF, it is Sci-Fi.
To recognize a DTMF code you use a chip like MC145436. Easy: telephone line in,
4 bits out, single 5V supply.
To use a secure or unsecure software implementation of the Goertzel algorithm you first have to digitise the telephone signal.
"To use a secure or unsecure software implementation of the Goertzel algorithm you first have to digitise the telephone signal."
You might like to check how modern PBX's receive incoming calls from telco's.
Anything above a couple of lines into a company in most developed countries has been digital by *default* for at least a decade.
Mine will have a copy of "Phone Systems for Dummies" in Kindle format.
Surely the hardware doing all of this is going to have a thread-per-call scheduling ?
Thread-per-call (-per-conversation, -per-session, etc) doesn't scale well. It's terribly wasteful - most of a thread's time is spent waiting (the time between sending a prompt and getting a response from a user is an eternity in CPU cycles), so the thread's working set just lies idle in memory most of the time. And unless you have a large address space, your thread stacks will chew it up quickly. It also tends to introduce a load of potential races, so you need to protect shared resources, and you end up with lots of synchronization overhead.
A real proper design uses cooperative multitasking with asynchronous processing of long-running tasks, or at worst a worker thread pool and asynchronous I/O.
I think it's the ABB' protocoll where you divide your tones into 2 slots and change one of the 2 frequencies. Not sure if anybody decodes that.
Besides there is some total bullshit in that article. Integer overflows in DSP algorithms don't cause DOS, they are just ignored (or clipped). That Memory exhaustion thing also total bullshit. The Sine and Cos tables are typically in ROM, or if you have older systems, you have a dedicated analogue chip decoding DTMF.
I mean there certainly are insanely badly coded systems out there, but since dealing with phone calls directly is such a hassle, I'd assume that most more complex systems are made with high level frameworks.
SQL injection and artithmetic interpretation of input might however we a problem.
This post has been deleted by its author
There are 16 assigned digits to DTMF code pairs. IE 4x4.leaving 4 available for control purposes, which *nominally* are available, but not through a *normal* telephone keypad (although specialist keypads and phone apps are widely available). Duration of *each* tone is part of the *full* spec.
Modern telephone systems use "out of band" signalling through separate data channels. Which is not to say those servers are not accessible through the *right* telephone number.
But DTMF has been in use since the 1960s. The Bell System's decision to drop *their* DTMF sensors (DTMF filters driving the routing hardware) opened up the market for end user gadgets to use the protocol.
Perhaps it's time the end user servers started dropping *their* filters (or rather the software code detection modules) out of the circuit as well.
Actually those "data" channels for signaling are fairly separate from the phone system. They carry SS7. You cannot "dial" into them, however you can buy access from some phone companies. In fact if you have one of those nano-cells it's likely you get some, supposedly heavily guarded, access to the SS7 network.
However normal ISDN has little to do with SS7. So all the features and services get translated from ISDN to SS7 and vice versa. The phone switch is supposed to only let through things it understands.
So the path to SS7 over ISDN would have to be over bugs.
"out of band" signalling ranges from tones outside the normal subscriber line pair pass band to a parallel network on separate cabling, like SS7.
The days of "dialling in" from a regular subscriber line and "seizing" a trunk line using specific control tones are *long* gone, although it's possible some of the activities they spawned may still be with us.
*However* what we're looking at here are effectively PBX's so remote access by the mfg for diagnostics is certainly possible, as is unpublished numbers allowing remote lo-call rates
"If the guy claimed that certain phone systems have back-doors (intentional, or left open by error) or bugs that respond to the 4th column DTMF signals (keys marked A B C D on the extended keypads), then I'd believe it."
He's not. Although that's possible too.
The PDF is a trailer for his talk *however* reading between the lines he's implying that *most* servers are using a software DTMF decoder and quite a few of them make *unwise* assumptions about what they will have as input.
Examples would include "long" tones or tone pairs (EG 1 sec long rather than a few cycles of each pair of combined tones) or a burst of *all* 8 tones together. Impossible with a tone generating keypad (key scanning logic would not allow it) but pretty simple with a pre-recorded sound file.
AFAIK in both cases the standard is *undefined*. Good embedded apps *should* ignore them and carry on (flushing relevant buffers as needed) but I'll bet (in some cases) that's not quite what happens.
We'll have to wait for the full paper to see the details. And weather he'll name the suppliers who can be crashed.
A backup key question would be can he crash just this *instance* of the DTMF software, which should get flushed when the call hangs up, or *all* instances of it, and hence the whole service.
The former makes this a storm in a tea cup. The latter is a whole lot more serious.
...I'm convinced much attention is being paid to garbage. He didn't successfully attack any system. He had a test system he bounced some goofy crap off of that really didn't do anything. Since most IVR systems I've used use # and * for the vast majority of the actions you can do, * is rarely interpreted as "times." I tried this YAY MATH approach with the IVR for my bank just now, and as soon as I mash *, I'm greeted with a lovely voice telling me I've entered an invalid response.
Much dumd in this.