Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

Symlinks as mount portals: Abusing container mount points on MikroTik's RouterOS to gain code execution- 923

nnsPosted 3 Years Ago
  • MicroTik recently added the ability to containerize application running on their routing. This is the functionality being targeted in this attack.
  • An interesting feature is allowing for mount points between the host and the container. For instance, if you wanted to allow the /etc folder on a disk into a container, the command would look like the following: /container/mounts/add name=<name> src=disk1/etc dst=<container_location> .
  • The author realized a few flaws in this. First, paths are resolved through symbolic links. This means that the directory was being resolved prior to the mounting process. Second, symbolic links are resolved from the hosts root instead of the container root for both the src and dst parameters.
  • Using this facts, many horrible things can be done. First, when performing the mounting of a drive in the container, we can mount arbitrary locations. For instance, we can mount into an arbitrary directory by using symlinks. This should be easy to exploit then, right?
  • The mounts are created with nosuid, nodev and noexec permissions. Practically, this means that even if a binary or shared library was overwritten, it wouldn't matter because of these permission. The executor would simply get "permission denied". Config files would be a good target because of this; but the author couldn't find anything helpful.
  • The author discovered that symlinking existing on the noexec file system but pointing to binaries outside of the filesystem would still be executed. The containers root file system does not have the noexec, which is helpful. So, they created a mount point over an existing binary, such as telnet to create a symbolic link. This link then pointed within the executable part of the container.
  • Now, the next time telnet was ran, it was executed to give the author a reverse shell. This gives arbitrary code execution on the device from within the context of the container. In order to fix this, I assume some patching with the symbolic links was done. Overall, awesome post with very useful explanations.