Emergency-Number Hack Bypasses Android Lock Screen

HardOCP News

[H] News
Joined
Dec 31, 1969
Messages
0
You have to wonder how the hell this guy figured this out. Was he just bored one day and started messing around with his phone?

A vulnerability exists in Android 5.x <= 5.1.1 (before build LMY48M) that allows an attacker to crash the lockscreen and gain full access to a locked device, even if encryption is enabled on the device. By manipulating a sufficiently large string in the password field when the camera app is active an attacker is able to destabilize the lockscreen, causing it to crash to the home screen. At this point arbitrary applications can be run or adb developer access can be enabled to gain full access to the device and expose any data contained therein.
 
It doesn't look like it will actually have any real chance of working on a regular basis. This looks like a coincidence of a small possibility where it just happened to crash to the homescreen.

I wouldn't necessarily call this a vulnerability or a security flaw. Yes it works, but its not a conventional security flaw.
 
I can "hack" a car door lock by smashing the window.

But perhaps there's something to be said for password algorithms to recognize blatant incorrect entries.
 
He wasn't entering passwords. He was entering phone numbers.
 
Isn't this an instance of the age old buffer overflow? This is why you're supposed to do checks on your input. My guess is that you couldn't type this in, but pasting bypasses any protection, but that's me assuming that Google would have prevented you from typing more characters than the underlying data type could handle.
 
I can "hack" a car door lock by smashing the window.

But perhaps there's something to be said for password algorithms to recognize blatant incorrect entries.

This is a hack. Going on a rampage at people who say LOL I HACKED YOUR FACEBOOK by sitting at your computer when you didn't have it locked is understandable. This is a legitimate exploit.

In the computer security context, a hacker is someone who seeks and exploits weaknesses in a computer system or computer network.
 
Sweet hack, especially the encryption part. But like they say, if someone has physical access to your device, they own your cheezburger.

quietly checks nexus 7 build, and feels so secure seeing that it's LMY48M
 
Isn't this an instance of the age old buffer overflow? This is why you're supposed to do checks on your input. My guess is that you couldn't type this in, but pasting bypasses any protection, but that's me assuming that Google would have prevented you from typing more characters than the underlying data type could handle.

Close, but of the same style of overflow attack.
 
I can "hack" a car door lock by smashing the window.

But perhaps there's something to be said for password algorithms to recognize blatant incorrect entries.

Next time just say, "I didn't watch the video." Even better, choose not to comment. :rolleyes:
 
Isn't this an instance of the age old buffer overflow? This is why you're supposed to do checks on your input. My guess is that you couldn't type this in, but pasting bypasses any protection, but that's me assuming that Google would have prevented you from typing more characters than the underlying data type could handle.

Sure looks close to it. i believe buffer overflow attack actual tries to make the victim code execute the data you have "typed" in as if it was code. This looks more to just crash the software handling the "typed" data.
 
Sure looks close to it. i believe buffer overflow attack actual tries to make the victim code execute the data you have "typed" in as if it was code. This looks more to just crash the software handling the "typed" data.

Not sure if that's true or not. That sounds more like something you'd do for some sort of injection hack. For example, you might type \`rm -rf *\` somewhere in your input. Assuming atp1916 is correct and it's an integer overrun, then the program crashes when the value changes from a positive number to a negative number.

Regardless, this is probably a bug that should have been caught in testing, but I'm sure I've written code that wouldn't survive such an attack...fortunately, most of my s/w is for internal use (because there's no way they'd tolerate good coding practices/testing...that costs money...sadly that's not a joke)
 
The bypass only seems to work under limited conditions. Those are:

- Nexus devices or possibly devices running stockish Android
- Set for password unlock (not pattern or pin)

On other devices copy/paste isn't even an option in emergency dialer and even attempting to manually dial a long series of asterisks will return 'not a valid emergency number' which is the result I got on two different non-Nexus devices.
 
The bypass only seems to work under limited conditions. Those are:

- Nexus devices or possibly devices running stockish Android
- Set for password unlock (not pattern or pin)

On other devices copy/paste isn't even an option in emergency dialer and even attempting to manually dial a long series of asterisks will return 'not a valid emergency number' which is the result I got on two different non-Nexus devices.


That and, from the text, it has to have the camera app active (even if only in the background).
 
The bypass only seems to work under limited conditions. Those are:

- Nexus devices or possibly devices running stockish Android
- Set for password unlock (not pattern or pin)

On other devices copy/paste isn't even an option in emergency dialer and even attempting to manually dial a long series of asterisks will return 'not a valid emergency number' which is the result I got on two different non-Nexus devices.

As the original post says. "A vulnerability exists in Android 5.x <= 5.1.1 (before build LMY48M)".

Any Nexus device should be at 5.1.1 at this point. LMY48M has been out for quite a while now. Devices running stock Android perhaps, but most devices running stock Android gets updates straight from Google and are likely up to date as well, e.g. Google Play phones.
 
Not sure if that's true or not. That sounds more like something you'd do for some sort of injection hack. For example, you might type \`rm -rf *\` somewhere in your input. Assuming atp1916 is correct and it's an integer overrun, then the program crashes when the value changes from a positive number to a negative number.

Regardless, this is probably a bug that should have been caught in testing, but I'm sure I've written code that wouldn't survive such an attack...fortunately, most of my s/w is for internal use (because there's no way they'd tolerate good coding practices/testing...that costs money...sadly that's not a joke)

I don't know why you keep mentioning integer overflow its highly unlikely to have anything to do with this hack.
Integer overflow is just merely running out of bits in your dedicated memory area/variable to hold your data. e.g if you try to count beyond 65535 in a 16 bit variable ( or 32767 if its a signed integer)
I think you are confusing buffer overflow with integer overflow perhaps ? buffer overflow IS an injection hack. when the sever accepts a certain amount of data the code has to keep hold of where the code is in memory. it can do that by keeping a counter of how far it needs to jump back from the data its is currently receiving lets say that counts is 8 bits so you can receive up to 255 characters/bytes of data. But if you keep filling the buffer beyonf 255 character/bytes, you get an integer overflow, and the counter reset to 0 and keep counting from there.
So lets say you hand it 320 characters of bytes. the counts hits 255, cant counts higher so its resets to 0 and cant from there and ends at 65.
now the server code looks int othis counter and see its has to jump 65 bytes back. but that is NOT back to the beginning but smack into the data you just provide it ( since its 320byts long) and its continues executing from here. Which is now YOUR code.

That is why the NX bit got developed because now we can assign this data area as a DO NOT EXECUTE. and in case the jumped would lead into a assign NX area the program will instead crash rather than executing strange code.

There are other injection and buffer overflow tricks out there.


Now why i don't think this hack is based on just a simply in integer overflow is that it seems highly unlikely you would work with integers in a call ap. You would rather work with an array of bytes/character. if you did indeed work wit the phone numbers as a single intergear you would need a very big intergear and also instead of just assign one tone for eack of the 10 characters ( 0-9) you would have to assigm tones combinations for all possible combinatinons withing that intergear since you are no longer lookin at each dial number as an individueal units. OR you would have to decode that big intergear back into single characters.
Both solutions being more cumbersome to code, less effective. than just workings with an array of bytes/characters to begin with.

Maybe the counter of the arrays get an integer overflow but then we are right back on the case of its basically becoming a buffer overflow hack. because we are filling the buffer with more than it can handle.


Please correct me if I'm wrong or misunderstood you.
 
Sure looks close to it. i believe buffer overflow attack actual tries to make the victim code execute the data you have "typed" in as if it was code. This looks more to just crash the software handling the "typed" data.

There are different types of buffer overflow attacks. A brief overview:

The classic one is what you refer to, where the stack is executable, and there's some function that takes unconstrained (or at least under constrained) user input and writes it to the stack such that the return instruction pointer can be overwritten to point at an address you control, such as back into the stack. The attacker then writes <shellcode><padding><return address to start of shellcode>, so that when the executing function returns, it returns into the shellcode.

In response mitigations such as stack check cookies and non executable stacks became normal. A stack check cookie is a value that is stored in an address that would be overwritten by the process attempting to overwrite the return instruction pointer. Since the value it is checked against is generally outside of attacker-controlled space and the value itself is generally unpredictable, overwriting it causes a stack check exception. Non executable stacks mean that you can't just write your shell code into the stack then jump back into it - the stack isn't executable!

So then you start getting into things like return to libc, rop oriented programming, and the countermeasures of things like ASLR.

However, this appears to be much simpler - it appears the lock screen and emergency call overlays are simply programs that, when they crash, leave you at the desktop. By putting a large enough string into the input field, at some point a function call, exception handler, or similar apparatus dereferences the junk that was entered, crashing the lock screen app. No arbitrary code execution, just a simple app crash that takes advantage of the OS's behavior on lock screen exit.
 
I don't know why you keep mentioning integer overflow its highly unlikely to have anything to do with this hack.

All I did was refer to what atp1916 post. I originally said Buffer overflow. Rewatching the video, it looks like he pasted over 5000 characters (assuming he overwrote all the old characters each time). Too much for a byte and too small to overflow an int. That holds true even if each paste added to the existing characters.

As I understand it, an int overflow attack works if your program is expecting a positive number and you have an overflow, it'll feed it a negative number, which could cause the program to crash. I didn't look at it closely, because before apt mentioned it, I'd never heard of an int overflow attack (though I recall doing checks for it when I wrote C code.
 
Back
Top