Magic Write-Up by T13nn3s

My write-up of the box Magic. If you have any improvements or additions I would like to hear! I look forward to learning from you guys!

https://binsec.nl/hack-the-box-magic-10-10-10-185/

Looks good @T13nn3s . Gives me the feeling you lived it through. Some walkthroughs give me the impression it’s an old piece of paper chewed on some new form, but you seem to have struggled through it, which is a good thing.

The one thing where I get the feeling it losses a bit of it’s depth is in the “lshw” part. You know how path hijacking is detected? Would be nice if you elaborated on that and added it to the explanation.

Detecting it is actually fairly simple to do. I don’t have my notes here, so my terminology will be a bit off, but unless this is some exception I don’t know of yet, path high jacking requires 3 conditions to be fulfilled. What makes it easy is that all three of the conditions can be detected with often one tool and the tools suited for the job are fairly commonly available on boxes.

When it comes to tools, you have quite some options: debuggers (if you want to squat a fly with an elephant), strace, strings or even a simple sed and grep can get you there in cases where strings if it isn’t available. But when available on the box, strings is the path of least resistance I know of.
strace may be more verbose then strings, but the downside of strace is that you need to follow a path manually and you may miss what you are looking for or it may take a while to get there, whereas strings will just examine the entire binary and let you know if some system call is made in matter of seconds, wherever it may be hidden.

The three conditions are:

  1. The binary uses the the c-language ‘system’ library. I use a bit more lengthy commands to make my life easier, but a simple “strings sysinfo | grep system” should probably do it. You’ll recognize it when you see it. That’s your first clue.
  2. the binary makes a call to a system command. In the output of strings you can see if this happens. I use some commands to clean up the output and filter for any system command. But a simple “strings sysinfo | grep lshw” should point your nose in the right direction and learn to see the differences between how these calls look like, compared to calls to c-functions.
  3. the third and final condition that needs to be fulfilled is that the call to the system command can not include absolute paths. So if you see a call to (just) ‘lshw’ it would be vulnerable, but if you’d have found a call to /usr/bin/lshw you couldn’t use a path high jack (well… unless you have write access to that folder or file. Always be sure to check that as well). Given the way the operating system works, this means that whatever system call is made, the order of where to look for that system command is: first it will look in the (p)wd, then it will start looking at all places defined in $PATH
    (There is the fourth implicit condition that in order for this vulnerability to be of use when it comes to privesc, the binary needs to run in elevated rights that are of interest to you)

So basically, if no absolute path is defined and a system call is made to a (system) command, you can highjack that command by placing your own executable in the directory where the vulnerable executable is located.
Sysinfo in this case, once it’s trying to run lshw, it will start to look for the command first in the directory it’s executed from, it will find your custom lshw command, be pretty much be satisfied with that and execute it. Since the suid bit is set on the sysinfo, the custom lshw will be executed in that context and so if your lshw produces a shell, it’ll be a shell in whatever context the suid executable is run.

Anyway, think it would be nice if you added something like that in your paper. You can just take the above explanation and make it your own, if you want.
Haven’t tested the above on the box, so you’ll have to see if my explanation is of any worth yourself. This might be some borderline case I’ve never seen. If it is, let me know.

It’s not very often you see people define the exact conditions that need to be met for something to be vulnerable. Walkthroughs tend to be pretty fuzzy in that department most of the time. In some cases the conditions might be so scattered it’s actually a blurry mess in reality, but most of the time, I believe it’s just people trying to cover up their limited knowledge on the vulnerability at hand. If you know a vulnerability well, it will be easy to state the conditions it needs in order to be vulnerable.
I’d very much like to see you raise that bar in your walkthroughs.
Hopefully people realize the importance of that and follow your lead.

In the end: if you clearly know the conditions involved before something is vulnerable, you’ll always have a clear vision of when it is valid to keep looking for something.
In that regard I believe knowing the conditions, is one of the most important works anyone can do if you want to bring clarity and oversight in your work.
And I know it’s not the most simple thing to do, but I believe as a community, we need to start to define those things explicitly and start to communicate them clearly.

Keep up the good work man.

P. S. One interesting thing to note: when checking for path highjacking, to be complete, you actually need to test recursively. For example: the sysinfo with the suid bit set, itself might not be vulnerable, but in theory it could make a call to any non-suid binary that is. And given that non-suid binary will be executed in the suid context of the sysinfo, that non-suid binary that seemed nothing important at first, then suddenly becomes really interesting if it’s vulnerable.
So when I test for path hijacking, I always factor in that recursiveness.
I’ve never seen it used in any box, but still: it’s possible. I do the complete tests described above, including the recursiveness in a I oneliner of code, a pretty long one, but it can be done. I’m sure you’ll find your own way.

Hi gnothiseauton! You have put so much effort in your comment, I really appreciate this. I have learned something from. I will take your explanation and update my write-up with this extra explanation. I’ve left a respect point for you, thanks!!!

Hey. Yeah. He put quite a good content here. @gnothiseauton
Thanks for sharing here with this much quality content.

:slight_smile: Thanks.

How I thought is the binary ‘sysinfo’ is not the original Linux binary. I thought it is a custom compiled binary as you can check it with ‘file’ command.

Am I right? If not, please clarify me.

@gunroot said:

How I thought is the binary ‘sysinfo’ is not the original Linux binary. I thought it is a custom compiled binary as you can check it with ‘file’ command.

Am I right? If not, please clarify me.

This is sort of how I picked it as interesting enough to dig into.

First when I ran file / -perm -4000 2>/dev/null it came up in the list and I didn’t recognise it.

Its file system data was also interesting - and unusual for a binary:

-rwsr-x--- 1 root users 22040 Oct 21  2019 /bin/sysinfo

At the end of the day this is a CTF so it is rare for a box creator to make something stand out and it not be part of the exploit path.

From there it was just a bit of experimentation to find out what worked.

Yes @TazWake . The file tool reveals that the binary is ‘not stripped’.

@gunroot said:

Yes @TazWake . The file tool reveals that the binary is ‘not stripped’.

:+1:

@T13nn3s, @gunroot thanks for your kind words! Great to see or helped.

Take care :slight_smile:

@gnothiseauton, I have respected you.

(Omdat je een Belg bent, ga ik ervan uit dat je Nederlands begrijpt: Ik heb je een respect gegeven)

:smile:

Type your comment> @T13nn3s said:

@gnothiseauton, I have respected you.

(Omdat je een Belg bent, ga ik ervan uit dat je Nederlands begrijpt: Ik heb je een respect gegeven)

:smile:

Thanks man. Most appreciated (heel erg op prijs gesteld! Goed om nederlands te zien op dit forum :slight_smile: Lijkt wel populair te zijn in Nederland huh dit domein)