Skype Lockscreen Bypass Bug

Tested with Skype version 3.2.0.6673 (released 1st July 2013) on various
Android devices (Sony Xperia Z, Samsung Galaxy Note 2, Huawei Premia 4G

The Skype for Android application appears to have a bug which permits the
Android inbuilt lockscreen (ie. pattern, PIN, password) to be bypassed
relatively easily, if the device is logged into Skype, and the "attacker"
is able to call the "victim" on Skype.

This can be reproduced as follows with 2 Skype accounts, and 2 separate
devices to use with Skype. The target phone is presumed to have an Android
lockscreen configured and in use, and to be locked during the test.

1. Initiate a Skype call to the target device, which will cause it to
wake, ring, and display a prompt on the screen to answer or reject the call
2. Accept the call from the target device using the green answer button
on the screen
3. End the call from the initiating device (ie. the device used to call
the target phone)
4. The target device will end the call, and should display the
lockscreen.
5. Turn off the screen of the target device using the power key, and
turn it on again
6. The lockscreen will now be bypassed. It will remain bypassed until
the device is rebooted

Similar to (ironically enough):
http://arstechnica.com/security/201...een-lock-on-up-to-100-million-android-phones/.
Seems that internet based calling apps might well be "unlucky".

I suggest logging out of skype when not using it, until there is a fix.

Thanks to Turl for originally bringing this to my attention.

SamsungPisser said:

Does andybody know which wrong usage of the Android-API might be used here? I'm developing myself an app which switches the Screen on and shows information without the need to unlock the device. Know I'm concerned that I might use the API wrong, too. There were also such bugs in other apps in the past month, so there must be some wrong usage type. Saidly I didn't find anything about it via googling. If you have links, please share.

Click to expand...

Click to collapse

It seems to be related to the use of the permission to disable the lockscreen.

I.e. http://stackoverflow.com/questions/12021800/disable-delay-android-lock-screen-programmatically

You want to ensure you definitely disable the option once done. I suggest you create a test plan and ensure even if everything goes wrong, the lock will still get enabled again in the end.

c0rnholio said:

Hi egzthunder1,

I don't take your post personal. My post was not made with the intent to be a bugfix. I just want someone else who also has access to provisioned devices to confirm my observation. Additionally if my observation is correct then it should be mentioned in a security advisory that enterprise provisioned devices with an enforced password seem to not be affected by all these lockscreen bypasses. I'm just discussing here

Click to expand...

Click to collapse

Hmmm that is interesting actually.

I need to see if I can replicate this by forcing provisioning manually.

I don't have an exchange server unfortunately (I use my own mail server that uses the protocol but doesn't do the complex provisioning.)

I'll have a look though as I think it supports provisioning in the configuration where it emulates Exchange. I believe this likely is a workaround for enterprise users.

This would be enough motivation actually to look at setting up proper provisioning of my devices.

Thanks for letting me know