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 …
People not bothering to sanitise their input...
Poor old Boby Drop Table.... kkkrrrrk [ERROR]...
Rule Number 1 of programming: Never trust external/user supplied data.
can we blame the RBS/Natwest crash last month on R2D2 trying to check his account balance?
Nothing to do with me.
I don't even bank with them. Since they outsourced to India, I've been keeping all my money under my pilau.
..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.
You have to be careful...I remember reading about a case where someone blew a whistle down the phone to a cold caller and got sued...the salesperson claimed hearing damage and the court believed it.
Ah yes. There is an xkcd for all seasons :D
The reg comments section is starting to feel as if it's sponsored by XKCD. It's an occasionally funny comic, do we really need a link every time?
.. and yes again.
As a matter of fact, I think we can elevate this to a standard. No topic is complete without an XKCD link.
I wondered if he was talking about control tones and that reminded me of the Bluebox et al and I was delighted to see you can get them as programs on smart phones... phreaky!
I don't think so. My understanding is that blueboxes worked back in the day when exchanges sent control/routing information in the voice channel. Nowadays, all the control traffic is run separately to the voice traffic.
I was wondering more about the non standard DTMF tones and whether they could be used to crash the system, not so much to try and control it. Otherwise is it just random noise used to crash the audio processing system or have I missed the point of the article?
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 ..
Thanks for that. I was going to pay attention to this but now I know that some anonymous internet geniuses don't think it's important I won't bother. Phew!
You're welcome. I'm also uninterested in contemporary music and iPhones if you fancy ignoring them as well....
They are obviously so clever that use of the past tense is beneath them.
no doubt they'll be an article about the dangers of crossing the road without looking both ways
If it wasn't for cyclists that could work on a one-way street..
Phone phreaking used to be so much fun back in the day. Free local or long distance from any pay phone, oh the memories...
Let's more the vulnerable call centers out of India and back home to create a few jobs locally.
I know. Out of the box thinking there.
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.
When I call a bank or anything with IVR I just press # repeatedly until i got transferred to a person. Me not computer, me like'y talk to person!
The guy did nothing. There is no story here: he didn't access anyone else's account, he didn't get the system to cough up unsecured data.
All he has is a bunch of unsubstantiated claims.
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.
And they post it to your house....
Yeah, because someone wouldn't notice loosing they keys AND their cards.
@DJ Smiley: Don't get in the way of a good rant, who cares if the banks are in the right or the wrong as long as some Internet commentators can have a rant about it.
... but if a DTMF tone is malformed/distorted then wouldn't/shouldn't it be treated as voice -- assuming the resulting distortion was in the voice range?
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.
Your privileges for apostrophe use are hereby revoked.
"To recognize a DTMF code you use a chip like MC145436. Easy: telephone line in,"
For a personal project perhaps.
Not for commercial scale operations.
Surely the hardware doing all of this is going to have a thread-per-call scheduling ? So crashing one call wouldn't bring the whole system down ?
Well, if the thing was written properly to start with.
"Well, if the thing was written properly to start with."
Modern stuff will be a DSP app running on a server farm *not* hardware.
And I'd agree *if* the software is written properly.
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.
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
Can we have a demonstration, preferably on Big Celebrity Factor on Ice?
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.
Any other claims are "extraordinary" (code word for garbage).
"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.