Today I'm taking on Nest. This was all about some code analysis and reverse engineering.
To date, I've been trying to stick to a couple personal limitations while tackling these boxes. First and foremost, obviously, is to not "cheat" and look up any exiting writeups. So far so good on that front... I did so once, but it didn't give me any useful information (in fact, it showed me what I was ALREADY doing on my own, and it wasn't working). I've also been trrying to stick to ONLY the OSCP-approved tools (so Nessus and Metasploit are off the books), despite not doing JUST the OSCP-like boxes. Lastly, I've tried to... "stick to 1 machine", ie, all my hacking and work and research and whatnot is all done from 1 single machine. I'm trying to demonstrate that it doesn't take a crazy setup to accomplish these things. In fact, it could all be done from a single bootable Kali install, aybe even a Raspberry Pi. This time, I had to resort to pulling some files back to a Windows machine, both for some Visual Basic code review (and compilation and running), as well as some DEcompilation of a binary. While I have typically disdained Microsoft and Windows, I cannot argue how useful it is to have a Windows box handy to help along with things like this. To be honest, this is a bit of a surprise to me, I had fully expected to be able to tackle everything using just Kali, and while that still may be possible to this kind of code analysis/compilation/decompilation using JUST Kali, having a Windows box handy sure made my life easier.
It's comical... until today, I had always hated reviewing others' code... I ALWAYS found myself having SO much trouble trying to sort out what that person was trying to do with that bit of code. But this time around, I found the code review SUPER easy... I just... READ it, and followed what functions were being called and what those functions did. Never before have I had such an easy time. Granted, this may be because I've also spent a little more time coding and "reviewing" (much) simpler single-file code since I last tried to seriously do so, but I didn't think it'd be THIS easy for me. The longest part, really, was in trying to stubbornly stick to using JUST Kali, and trying to do the analysis and compiling in Kali. Had I simply opted to use Windows the moment I saw it was VB code, I would have (probably) saved myself literally HOURS of frustration. As it is, I'll just have to learn this lesson, and accept that a Windows box can be useful in hacking-type activities.
As for the box itself, we didn't actually get any real SHELL on the machine. We got some kind of custom reporting app, but we also got the source code, so were able to exploit that. Without the source code, we probably would not have been able to reverse those passwords (I tried).MAYBE using just the decompiled binary, MAYBE, we could have figured it out, but that's a chance, not as sure ats the source code itself. So this really highlights the importance of access control, controlling who does and doesn't have access to resources, and source control, effectively controlling access to source code(s). With these in place, full system compromise would have been nigh upon impossible.
 HTB-Nest Report
|
|
Report for Nest on HTB |
|
 Tuesday, 11 August 2020 17:22  150.89 KB  373 |
Download |
Today, again, has a bit more focus on the report itself. I included the false herrings I followed here as well, though I am unsure on whether or not, or how I would, include this for a client. On one hand, it's a bit more transparency, and in theory, would potentially identify where some things are "safe". But there's an argument that it may show some of the reporter's (mine) failings and limitations (Oh what!? You couldn't this thing *I* find super easy??), and I'm not sure how "professional" this may be. But in the effort of showing not just WHAT the solution is, but HOW it was derived, I will continue to include all that information.
