Local authorization without a password in Ubuntu
Today we’ll talk about how we found local authentication without a password in Ubuntu, which never seems to be closed. How it all happened, read under the cut.
One fine summer evening, the author of the article closed the lid of a working laptop with Ubuntu 16.04 Desktop on Unity and went home. The evening was so beautiful that I decided to take a couple of days of vacation, threw an SMS to my boss, and he let me go.
As it turned out, not all of my colleagues this evening was just as beautiful. The c4n had a broken laptop, so he asked me to lend it to me, but with his hard drive. I, of course, allowed.
This is where our fascinating investigation began.
What happened?
The next morning, c4n disassembled my laptop and inserted my hard drive there. He opened the lid and saw, instead of starting to load his OS, the login window to my system. It was clickable, and c4n began to enter random passwords, however, all was unsuccessful. Frustrated, he pressed the shutdown button, and a miracle happened .
Instead of rebooting the computer, a successful login to my system was performed , and the latest programs and documents that I opened were shown. It is worth noting that the documents were not just shown, they worked for themselves! You could scroll through the documents and go through the browser tabs. c4n immediately threw me a screenshot.
In fact, the screenshot was different. I, leaving work, do not leave open KeePass and company website.
On the face of local authorization without a password!
When I came out of vacation, I wondered what was the matter of this phenomenon, whether it always plays and always plays the same way, whether it plays on all systems.
The reasons
As it turned out, the fault of this phenomenon was that when the lid was closed, my laptop did not go into hibernation, but to sleep (i.e., left power to the RAM), and after opening the lid in the RAM, the loaded OS and the last files remained by which I worked. The OS knows nothing about the removal of the hard disk from the computer and continues to work until it is necessary to access the hard disk.
Why is it possible to pass authorization, remains a mystery for us. We sin on the work of the modules PAM (Pluggable Authentication Modules),
Is it always played and is it always the same?
Our experiments began with Ubuntu 16.04. The actions were as follows:
- We send the computer to sleep mode.
- We take out the hard drive.
- We remove the computer from sleep mode.
Further, as it turned out, there may be several options for the behavior of the system:
- The computer shows the login window, enter a random password => see the windows of users before the slip (all windows are working).
- The computer shows the login window, we enter a random password => the system says that the password is wrong => press the power button once => see the windows of the users in front of the slip (all windows are working).
- The computer shows a black screen (the cursor runs over it), press random keys and Enter => we see the windows of the users in front of the slip (all the windows are working).
- The computer shows a black screen (the cursor runs over it), press random keys and Enter => nothing happens => press the power button => once we see the windows of the users in front of the slip (all windows are working).
Most likely, items 3-4 are similar to items 1-2, just for some reason the graphics do not draw the login window.
The experiment was conducted many times, and all times it was possible to gain access to the user's windows, i.e. reproducibility is 100%. This is very cool for such a strange bug. However, it is worth noting that only active windows are available, we were unable to switch to minimized windows. Also, some windows disappeared after a while, and sometimes there was a ralogging effect, but one of the four entry methods allowed you to go back.
Poc
We shot a small video that demonstrates the entire attack process.
Is it reproduced on all systems?
The condition for testing was the presence of all the latest updates on the system. Why do we need a bug that has long been closed?
For a start, it was decided to check whether the bug is played on regular PCs (not laptops) with Ubuntu 16.04 with Unity. There was a theory that showing windows could be somehow connected to a video card. Therefore, the test was carried out with a PC with both an integrated and a discrete video card, in all cases the result was the same - the bug works fine.
Next was taken Ubuntu 16.04 with GNOME. And then we were disappointed: the bug did not work out. Sometimes, when exiting a slip, the system showed the last windows for half a second (it’s quite realistic to videotape), the researchers reported about it back in 2011 , and it’s not closed yet.
Then we took Arch with Wayland and Xorg - disappointment, does not work. Debian 9 with GNOME and again disappointment. Also, it did not work on the new Ubuntu 04/18 - not surprising, because by that time we already began to suspect that the problem was in Unity. Therefore, we decided for the latest tests to take Ubuntu 14.04, and also see what happens with Ubuntu 18.04, if you change the window manager from GNOME to Unity. On Ubuntu 14.04, everything worked fine (although the lifetime of the windows was significantly less than at 16.04). On Ubuntu 18.04 with Unity, after leaving the slip, the system immediately crashes, and no experiments can be carried out any further.
Conclusion: we decided that Ubuntu versions with natively installed Unity are vulnerable; versions
- 10.10
- 11.04
- 11.10
- 12.04
- 12.10
- 13.04
- 13.10
- 14.04 (tested by us)
- 14.10
- 15.04
- 15.10
- 16.04 (tested by us)
- 16.10 (tested by us)
- 04/17 (tested by us)
Pretty impressive list, isn't it? We tested not all. If someone has the opportunity to check on other versions that we have not tested, we are happy to add to the post.
Why do we think this is bad
Vulnerability allows you to get only local access to data, and then not to all, but only to those that are open in applications and deployed. However, this is still quite critical, because:
- The data used may not be saved to disk (for example, an editable document).
- The data may be located in an encrypted home directory (for example, a password file).
- Data can be on an encrypted flash drive.
- Data may require additional authorization (as in our PoC with KeePass).
In addition to this, any person can send a computer to Unity in Unity, simply from the login screen (without authorization). Those. quite a real situation that a person locks the screen and goes to dinner, at this moment the attacker sends the computer to slip, takes out the hard drive and looks at what the person did before he went to dinner. After it remains to restart the computer already with the disk, and the person will not guess that his data could have been compromised.
Skeptics will say that this result can be easily achieved by conducting a cold boot attack, and the results will be even better, but how often does one of you carry a thermos with a couple of liters of liquid nitrogen?
We decided that the problem is critical and we need to write to Ubuntu.
How do we write in ubuntu
To get a bug, we had to register on launchpad.net , then create a description of the bugs and add video with PoC. We got 406 rating points and a campfire badge (whatever that means). Began to wait. Bug we brought 2018-06-18.
After a lengthy correspondence, comrade Marc Deslauriers ended our controversy with a message, the essence of which was reduced to: “We will not correct anything. It's the same thing as having physical access. ”
Attempts to convince failed. We were sent to total ignore for a week. Then we were given permission to publish this study:
UPD: July 9, 2018, at 16 o'clock we decided to make the bug public (thanks amarao). In the discussion on launchpad, the bug was confirmed for Mate 18.04, and not just for Unity. Also, the community insists that the bug exists and should not be ignored.