dowerx/www
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

fix markdown warnings

Browse Source
This commit is contained in:
BENEDEK László 2025-05-18 17:26:11 +02:00
parent 5376333233
commit 1fcda62f3a
1 changed files with 8 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
docs/blog/posts/irinyi-security.md
View File

@ -16,12 +16,15 @@ Do not use these for anything, please.
<!-- more -->
## Some context
Since I am studing at SZTE's TTIK, I had a few classes in the Iriny cabinet. They have a few classrooms full of PCs. These run some kind of Linux as a hypervisor, the actual classwork is done on VMs running on these PCs in VirtualBox. The disks inside these VMs is reset after shutdown so no permanent files can be created (in theory).
## The exploits
I found out about these exploits on my own, however I never used them for anything. The cabinet's terms state that experimenting with gaining privileges is a punishable offence. These are so fundamental errors in configuration that I wouldn't count my actions as *experimentation*, but I know that this won't save me if they ever come after me.
### 1. Docker, my beloved
The guest user was in the *docker* group and could start containers with privilleged access. That's it. You *could* start a container with root rights and do anything you want. You can even mount the host's *sudoers* file and add the guest user or edit any file for that matter.
``` docker-compose
@ -43,6 +46,7 @@ Since then, they updated their VMs and forgot to add the guest user to the *dock
No problem. We will get our docker access back another way.
### 2. Mount
Since the VMs reset after every shutdown, you need a place to store your projects. For that reason they created a script that mounts the users NFS share after authentication.
I looked inside the script. It calls mount using sudo. So we know that the user has access to mounting NFS shares, surely that's all. I checked the sudoers file and I was dissapointed. The guest user has access to mount without restrictions. :facepalm:
@ -64,11 +68,13 @@ sudo umount "/etc/sudoers.d"
You just gained root access inside the VM. You can run docker again. :smile:
### 3. VirtualBox
This was a real bad one, but I think they fixed it since then.
Basically VirtualBox captured some key combinations like ++ctrl+p++. ++ctrl+s++ opens the currently running VMs settings. :facepalm: From there you could have changed networking settings or mounted a folder from the host. I didn't test this, but you might have been able to mount the *sudores* or *shadow* file and edit it from the VM.
### 4. Scanning
All the PCs in the building are on the same network and have routing setup between the classrooms. Every host and every VM has its own hostname generated from a pattern (eg. pc22505-03 -> room 225, PC 5, VM 3 (Windows 10)).
Using a simple bash script you can scan the whole building end determin which PCs are online and what VM they are running.
@ -76,6 +82,7 @@ Using a simple bash script you can scan the whole building end determin which PC
In theory you could ssh into one of these VMs and use it as a proxy to bypass CooSpace's IP restriction on exams, but ssh is not allowed for the guest user (but we saw how to edit it earlier, so you might be able to).
## Conclusion
These exploits are not really dangerous on their own apart from the VirtualBox one. However, I didn't exactly put a lot of effort into finding these. So what if I did, how many vulnerabilities could I find?
Also there is a server for the students that you can ssh into. It runs the same Debian VM that the PCs run, so same exploits.
Also there is a server for the students that you can ssh into. It runs the same Debian VM that the PCs run, so same exploits.