Emergency-Number Hack Bypasses Android Lock Screen

Discussion in 'HardForum Tech News' started by HardOCP News, Sep 16, 2015.

  1. HardOCP News

    HardOCP News [H] News

    Messages:
    0
    Joined:
    Dec 31, 1969
    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.
     
  2. natos

    natos Limp Gawd

    Messages:
    442
    Joined:
    Oct 1, 2010
    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.
     
  3. kuyaglen

    kuyaglen [H]ardForum Junkie

    Messages:
    9,233
    Joined:
    May 15, 2002
    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.
     
  4. Taco

    Taco [H]ard|Gawd

    Messages:
    1,465
    Joined:
    Nov 2, 2001
    He wasn't entering passwords. He was entering phone numbers.
     
  5. nilepez

    nilepez [H]ardForum Junkie

    Messages:
    11,464
    Joined:
    Jan 21, 2005
    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.
     
  6. Weenis

    Weenis I said WEENIS, not...

    Messages:
    4,807
    Joined:
    Apr 10, 2006
    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.
     
  7. Jim Kim

    Jim Kim 2[H]4U

    Messages:
    3,500
    Joined:
    May 24, 2012
    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
     
  8. atp1916

    atp1916 [H]ard|DCoTM x1

    Messages:
    3,697
    Joined:
    Jun 18, 2004
    Close, but of the same style of overflow attack.
     
  9. mnewxcv

    mnewxcv [H]ardness Supreme

    Messages:
    6,470
    Joined:
    Mar 4, 2007
    guess i shouldnt leave my lg g3 unattended! oh wait, I dont.
     
  10. Protoform-X

    Protoform-X [H]ard|Gawd

    Messages:
    1,203
    Joined:
    Jan 30, 2002
    Next time just say, "I didn't watch the video." Even better, choose not to comment. :rolleyes:
     
  11. SvenBent

    SvenBent 2[H]4U

    Messages:
    3,116
    Joined:
    Sep 13, 2008
    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.
     
  12. nilepez

    nilepez [H]ardForum Junkie

    Messages:
    11,464
    Joined:
    Jan 21, 2005
    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)
     
  13. mi7chy

    mi7chy 2[H]4U

    Messages:
    3,985
    Joined:
    May 22, 2013
    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.
     

  14. That and, from the text, it has to have the camera app active (even if only in the background).
     
  15. xX326Xx

    xX326Xx Limp Gawd

    Messages:
    506
    Joined:
    Jan 30, 2006
    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.
     
  16. SvenBent

    SvenBent 2[H]4U

    Messages:
    3,116
    Joined:
    Sep 13, 2008
    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.
     
  17. Tawnos

    Tawnos 2[H]4U

    Messages:
    3,807
    Joined:
    Sep 9, 2001
    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.
     
  18. nilepez

    nilepez [H]ardForum Junkie

    Messages:
    11,464
    Joined:
    Jan 21, 2005
    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.