Search This Blog

Wednesday, 31 May 2017

E9 3E 50 4F 53: What comes in red pills and is highly addictive?



Since passing my OSCP exam a few weeks ago I've been debating whether to add to the vastness of reviews on the PWK course and OSCP exam. It, however, feels like a right of passage; so here goes.

What is the PWK course, I hear you ask. To quote from Offensive Security's website:

Penetration Testing with Kali (PWK) is a self-paced online pen testing course designed for network administrators and security professionals who want to take a serious and meaningful step into the world of professional penetration testing.”

It is marketed as an foundational course. Whilst this is correct in the grand scheme of things, don't let this fool you. It isn't “foundational” like many other courses with such branding; it is a course that will ensure you really understand and can effectively use the tools, techniques and theory that you are taught. This includes research and thinking creatively to work round problems.

Why did I do it?

There are two reasons.

First, I had heard of the course, many others in the community raving about how good it is, and that people were saying it was awesome. When someone states something is awesome you may be inclined to think they are over-rating a course that they enjoyed; but when so many people in the community, some of which I know, were telling similar stories; well that is a pattern that cannot be ignored.

Second, a more practical reason. Since I've left my job at a well known global telco I wanted to switch from a core infrastructure troubleshooter of last resort to a full time pen tester / security researcher. Whilst I had several SANS certifications such as GXPN, GPEN, etc, recruiters and companies in the UK were not particularly interested in them, but instead OSCP and CREST. CREST was very expensive. As I'm self funded with no income, both this and the reviews of OSCP meant OSCP was the way to go.

What do you get?

In addition to the expected course PDF and lots of video, you get access to what is probably the biggest plus for the course; access to a lab with in excess of 50 hosts across a number of networks. This lab has a whole range of challenges, from different operating systems to applications, designed to practice everything the course aims to teach you. There are rumours that a Solaris box lurks in the shadows.

Think of the PDF course as a solid and well-written step-by-step guide and the lab as the “now you know the principles, go pwn all the boxes”.

You can book lab time in 30, 60 or 90 day blocks. Each comes with an exam attempt.

The PDF has a number of exercises for you to do. Some are independent of the labs, some aren't. When it comes to the labs you are not given that much help (unless you really need it); it is a case of you need to figure out where and what is the vulnerability and how to exploit it; just like in real life.

If after, to quote their catchphrase you have “Tried Harder” but still need help, the OffSec admins will give you hints if asked. The forums, where other students can be found, will give you more obvious hints. Though the admins will edit out any “spoilers” that a student may inadvertently add. You won't get the answer; that is for you to figure out. After all, if you want to be a penetration tester, this is a key attribute you need to have.

In the exam though; you will get no hints.

When doing the exercises and the labs it is good to document them. If you document all of the required exercises and ten lab boxes in a penetration test report (there is a template), you can potentially get an extra five bonus points for each towards the exam mark for a total of ten bonus points.

I would strongly recommend you write this report, and before your exam. You don't want to be worrying about that as well during the report writing phase of the exam.

The Exam

The OSCP exam consists of a 23 hour 45 minute block of time to achieve a number of objectives within the exam network; which includes obtaining the proof.txt file in a shell for a number of targets (with evidence and recording of this in the appropriate form) proving you have admin rights. There can be other objectives for the targets such as a local.txt for an unprivileged shell.

You then have a further 24 hours to write the report and submit it in the required format (mandatory); along with the lab and exercise report (optional; which you did prior to the exam, didn't you).

All this is documented on the Offsec website; details of what I had in my exam (specifics) are under an NDA. See the exam guide for more info.

When am I ready for the exam?

OffSec are deliberately non-prescriptive on this since “it depends”.

They do recommend that you should get all the lab boxes except the “big three” of pain, sufferance and humble; at which point you should have the minimum necessary for the exam, but that is no guarantee. My view is that if you get all the main lab boxes and complete the exercises in the PDF you have covered all the key areas so should have the skills necessary, but; see my hints and tips later.

For me, I came from a non-pentesting role, despite my SANS certs. My expectation was that networks and systems level stuff would be relatively easier than the web app stuff, since it is in the infrastructure level stuff that my previous experience is at. Most of my application level experience  involved the services rather than the apps (e.g. Java JVM analysis/tuning). Also, in my day job I had all the keys to start with so would need to improve that “black box” approach to systems.

The result, some web app targets I would initially spend a couple of days to root whereas pain and sufferance were straightforward (privilege escalation including the recon was less than 15 minutes on one of them).

So I guess what I'm trying to say is that we all have different backgrounds and experiences. Something that is easy for some of us will be hard for others and visa-versa. Find your weaknesses and focus on those but don't neglect any area. Use the course PDF and labs as a guide to assess and practice those skills.

What did I do?

I took the 90-day lab option. I also took a couple of weeks off about half way through to recharge; you cannot “pause” the lab time but I felt a gap was important.

Once I had all of the labs boxes bar a small number I booked the exam for a months time. This meant the exam was a few days prior to the end of the lab. I figured if I failed the exam I could then extend the lab without interruption. Others may take a different approach.

I then spent the first two weeks writing the lab and exercise report for the bonus points; including re-testing the approach in the lab from a clean target to ensure a reliable exploit and that the process documented was correct. In some cases I simplified the approach as my initial success was more convoluted than needed.

After that, up to the exam, I used the lab time to finish off the lab boxes I hadn't got (or had only got via Metasploit) and then redid between 3 and 6 per day without looking at the machine specific notes I had. This gave me a lot more confidence heading into the exam; especially when I was finding other ways in and doing all in a good time (sufficient that if they were exam boxes I would have passed).

In the UK it looks like the earliest exam time you can book is at 10:00 (BST), so I went for that.

So, exam day comes after a reasonable sleep the night before. I get up and have a few hours before it starts, I try to take things easy and not rush anything; chill out as best I can.

10:00 the exam starts and the emails duly arrive from OffSec. I set up the VPN, connect and read the exam objectives I have been given. Each objective has a points value and you need a total of 70 out of 100 to pass (did I mention there are potentially 10 further bonus points for the lab / exercise report).

I notice one of the high value objectives is a very strong area for me but may take a bit of time, so for the next two hours I focus on that one whilst performing some background recon on the others.

Once that is in the bag I go for lunch, during which time the first problem occurs. A power blackout!!! Arrrrgh. I shall not quote the words that came out of my mouth.

Fortunately this only lasted just over five minutes, which meant my UPS was able to handle the issue (the perils living in a rural location). Time to get my blood pressure back under control and relax for the rest of my lunch.

I then spend the next hour and a bit on a low value target and getting a low priv shell on another. Time for another rest.

It is another 4.5 hours before I get my next success. Cycling through the remaining targets doing a bit of analysis until I feel I'm not making progress and moving on; then I suddenly spot the way to escalate privs on the one with the low priv shell. Yey; I am root. Time for dinner.

Back from dinner it is then not until 21:01 that I get low priv on my next target. Hint. If you think that you have tried something and it should have worked, retry it very carefully. You may find that you could have avoided wasting some precious time.

21:19 and I now have root. Yey. Time to take another rest.

I now have the final target that has been teasing me for most of the exam. However, I can now focus on this one; exclusively.

02:21 and I get low-priv. My mistake - OSCP is a foundational course so you appreciate that the solutions are easy (once you know how); this doesn't mean that if something appears complicated it is.

Then 03:04 I finally get root on the last box. Final root dance.

It ain't over yet.

Whilst I still have access to the exam network, I review all the objectives and make sure I have met them, submitted my proofs and have all the information I need for the report. Circa 03:30 I can now finally make a direct b-line for the bed and don't need to worry if I over-sleep.

The next day, or should that be later that day, I get up knowing that I now need to write the report; as no report = no pass.

As I've already written the lab and exercise report I only need to do the same for the exam objectives. I can afford to take my time and not rush things. Once written I can re-read it then update until I'm happy that it is up to an acceptable standard for submission.

I submit the report later that day and get confirmation from OffSec at 17:48 they have received it. At 19:47 the following day I get the results.

“We are happy to inform you that you have successfully completed the Penetration Testing with Kali Linux certification exam and have obtained your Offensive Security Certified Professional (OSCP) certification.”

Nice :D

Hints and Tips

      Read the other reviews out there. Collectively they paint a good picture about what to expect from the course and exam and hopefully you'll find at least one that is a good match for your background and learning method.
      Remember this is a foundational course; so the “way in” is going to be straightforward. You still need to find it, but don't need to write a 0day or anything close to that.
      If you are writing a 0day or similar it is probably a rabbit hole.
      Don't over-think things.
      If it is too obvious to be the way-in; it might be the way in.
      Whilst not required to take the exam, getting all the lab boxes except the “big three” is a good measure as to whether you are ready; though there are no guarantees.
      Did I mention there are bonus points for the lab / exercise report. Writing this before the exam removes the pressure of being just short of passing and having to write that report in addition to the exam report in the 24 hour report period you have.
      If you need to seek out help to get a lab box, figure out how you could have done things differently so as to avoid needing that help. Avoid if possible being too specific for that particular target. Remember; there are no hints on the exam.
      Document everything; a searchable reference other than Google may come in handy.
      Take regular breaks. Aim to spend no more than two hours at a time on the computer. You need to recharge, rest, relax to aid in concentration. This is a 24 hour exam after all.
      Plan meals, etc beforehand so you only have to think about the exam on the exam day.
      Try not to panic or stress out. If you are stuck or struggling take a time-out or move on to another target and re-visit that one at a later date. That distraction can lead to a eureka moment or allow you to re-focus on that problem when you return to it.
      Read g0tmi1k's article for 'alpha' on the PWK forum (contains spoilers; so perhaps not straight away but certainly before the exam). Focus more on the strategy and approach he uses and think about how you can apply that to the other lab boxes and the exam boxes.
      If you don't pass the first time don't give up. Know that many people have been there before, have come so close, but not let this stop them. If you feel like it, blog about it and how you dealt with it. This is something missing from most reviews that several people have stated would have helped.
      …. and finally; beware, penetration testing comes in red pills and is highly addictive.

Conclusion

I can safely say that the PWK course and even the OSCP exam were some of the most enjoyable I've experienced (how often can you say you have thoroughly enjoyed an exam?).

What I especially like is that it is designed to get you to think for yourself. The exam tests this; and in my view is vastly more valuable than an exam that tests whether you can remember the exact switch or option to a command that you would normally just look up if you didn't know.

Next Steps

Well, I was thinking covfefe ….. er CTP/OSCE. I got bored waiting for the PWK course to start so had a go at the pre-registration challenge and liked it. I start in a few days.

Tuesday, 6 September 2016

Linux Ransomware and SSH



I recently came across this article on the FAIRWARE ransomware attacking Linux servers by brute forcing SSH according to the referenced article here. I thought why in this day-and-age is brute forcing SSH from the Internet working? Surely we are not exposing SSH administrative interfaces to the big bad Internet, let alone in an insecure way (rhetorical)?

So, whilst by no means a complete How-To, I thought I would go through a few areas that I hope may improve the security of systems running SSH. Though, as we all know, what you actually do depends on your risk appetite among other things.

In summary this is really about defence in depth. Not only make good security decisions, but also don't rely on a few. My view is if there is a shortcoming, no matter how minor, deal with it (assess it, then either fix it or accept the risk (with possible mitigations)).

For SSH, in no particular order.

1. Don't bind to all interfaces and certainly not your Internet facing one

In today's world of virtualisation, there really should be no excuse for not re-configuring a management service such as SSH to only listen on a management interface. Such a management network must not be directly accessible via the Internet; you should need to go via a VPN, Citrix or other strong security gate as a minimum to access such a network.

If your management services are only listening on your management interface, then even if your firewalls, or other Internet facing protections are breached, it is still going to be a bit of a challenge for an adversary to get shell access via that service.

This can be achieved using the Listen directive in sshd_config.

2. Never, ever, allow direct privileged logons

Being able to directly SSH (login) as root or a privileged user is just asking for trouble. Would you build a safe so that the door was accessible via an outside wall that the public walk past? I hope not; so should we really be doing the same thing with our servers holding our sensitive information assets?

The easiest way to prevent this is to only permit normal users (typically having a common group). i.e. we whitelist accounts rather than blacklist, so if a new account is created it needs to be assessed first.

PermitRootLogin should always be set to no, but we also need to take account of other 'unprivileged' users that may be applications (thus have access to or “own” potentially sensitive information) and users with enhanced 'root' rights (such as having capabilities in Linux, or via sudo).

3. Multi-factor authentication

It is always a good idea to examine a technology to fully understand what it can do. So, in this case, even if you don't have true multi-factor authentication, you would have spotted the RequiredAuthentications or AuthenticationMethods directive in SSH, which states what methods must succeed to allow access.

So the following on CentOS 7 requires both a publickey and a password to successfully log on (or more precisely the use of the associated private key on the client where the public key is configured on the user's account on the server).

AuthenticationMethods publickey,password

So, even if the public key does not have a paraphrase, we have the following, showing the public key authentication is not sufficient; you also need the account password.

$ ssh -x localhost
Authenticated with partial success.
auser@localhost's password:
Last login: Tue Sep  6 10:59:49 2016
$

I hope you would agree, even brute forcing that “poor-man's 2FA” is a bit more challenging.

4. Bar tunnelling over SSH

A tunnel allows you to tunnel any connection in any direction, via the SSH connection. Indeed the man page describes how to set up a VPN as well! This allows trivial bypass of firewalls and other security devices, by using the trusted encrypted SSH connection.

Unless you have very specific requirements, which are documented and limited by the configuration such as PermitOpen or the use of a directive in a cert, disable SSH tunnelling via PermitTunnel no. Don't forget the tap devices, if supported.

Even if you have a captive client, the user can press ~C to open an SSH “command line” to dynamically add a tunnel. So, if it isn't disabled at the server side a user can still add it in a captive setup. See the man page on ssh.

5. Require strong MACs and Ciphers

If both the client and server supports it, shouldn't we actively prevent the use of weak MACs and Ciphers?

The default configuration on CentOS 7 allows MD5 and SHA1 as MACs. It also allows sha2-256, sha2-512. Perhaps we should specify only the strongest subset and thus put a mandatory bar on MD5 and SHA1, for example.

6. Use only SSH version 2

Fortunately most modern configurations only enable version 2 (Protocol 2). Protocol version 1 has known design flaws, so should not be used. See an example from CERT here.

7. Client side

Don't forget the client side configuration as well.

If a client also only allows strong MACs and Ciphers, for example, and you suddenly can no longer access a host due to cipher support, does this suggest a problem? Certainly worth investigation.

More

This is just a small sample of the options open to you. There are many other configuration options for example, including Match statements for finer-grain configuration, adding options in the authorized_keys file, client IP lockdown, and SELinux tweaks, to name a few.

Oh, and monitoring. An unmonitored log is a useless log.

What would be your top recommendations?

Friday, 2 September 2016

A look at an SELinux error message



As a fan of the SELinux security framework that runs as part of Linux, I thought it would be a good idea to improve my skillset in this area, and go beyond the basics.

Part of that is research, subscribing to SELinux mailing lists, playing with test setups and, of course, reading what others are saying via Google searches.

One, whilst going off at a tangent to my goal, sparked my interest as all the posts I saw didn't have the answer. It was this type of error:

libsemanage.validate_handler: MLS range s0-s1:c1,c3 for Unix user XXX exceeds allowed range s0:c1,c3-s1:c1,c3 for SELinux user XXX
libsemanage.validate_handler: seuser mapping [XXX -> (XXX, s0-s1:c1,c3)] is invalid
libsemanage.dbase_llist_iterate: could not iterate over records

For example here, just search for libsemanage.validate_handler.

The answer should be straightforward, and relies on the fact that SELinux enforces mandatory access controls; aka stop you doing stupid or bad things (or at least what policy states are stupid/bad things), plus the tools stop stupid/bad configurations (again, at least what the developers state are such).

We can look at three types of user concept here. First, we have the traditional UNIX user as defined in /etc/passwd or your favourite password backend. Secondly, we have the concept of an SELinux user, which is more akin to a class or UNIX group. Finally, we have mappings which map the UNIX user to the SELinux user, which themselves (can) specify ranges.

SELinux users are managed by semanage user, whilst the mappings are managed by semanage login.

If we map a UNIX user to a SELinux user, we are stating that the UNIX user has a particular range of clearances to access and do stuff on the machine. However, when we set up the mapping we can further constrain the user, but cannot (shouldn't be able to) grant more than the base SELinux user they are mapped to.

So, here's an example on one of my test boxes.

The test box is running the mls policy and is using poly-instantiated directories of /tmp /var/tmp and $HOME based on the context (i.e. we can only see a home area or temp area commensurate to our current level.

First, lets create an SELinux user of devuser_u which has the standard user role of user_r:

[root@centos-7-2-t1 ~]# semanage user -a -R user_r -r s0-s1:c1,c3 devuser_u
[root@centos-7-2-t1 ~]# semanage user -l

                Labelling  MLS/       MLS/                         
SELinux User    Prefix     MCS Level  MCS Range            SELinux Roles

devuser_u       user       s0         s0-s1:c1,c3          user_r

Now  let's create a user that is of that type:

[root@centos-7-2-t1 ~]# useradd -m -Z devuser_u dev1
[root@centos-7-2-t1 ~]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          user_u               s0                   *
dev1                 devuser_u            s0-s1:c1,c3          *

Now lets say that we wish for the user to be able to access a new category (compartment) of c8. We may state that we do this with the mapping, but as this user is an SELinux user of devuser_u this isn't going to work:

[root@centos-7-2-t1 ~]# semanage login -m -r s0-s1:c1,c3,c8 dev1
libsemanage.validate_handler: MLS range s0-s1:c1,c3,c8 for Unix user dev1 exceeds allowed range s0-s1:c1,c3 for SELinux user devuser_u
libsemanage.validate_handler: seuser mapping [dev1 -> (devuser_u, s0-s1:c1,c3,c8)] is invalid
libsemanage.dbase_llist_iterate: could not iterate over records
ValueError: Could not commit semanage transaction

Instead we either need to create a new SELinux user (and map the unix user to it) or modify the existing one. So, lets modify the existing one so that it includes this new category:

[root@centos-7-2-t1 ~]# semanage user -m -r s0-s1:c1,c3,c8 devuser_u
[root@centos-7-2-t1 ~]# semanage user -l

                Labelling  MLS/       MLS/                          
SELinux User    Prefix     MCS Level  MCS Range            SELinux Roles

devuser_u       user       s0         s0-s1:c1,c3,c8       user_r

Cool, that worked. Note that this does not update the individual mappings.

[root@centos-7-2-t1 ~]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          user_u               s0                   *
dev1                 devuser_u            s0-s1:c1,c3          *

So, lets do that.

[root@centos-7-2-t1 ~]# semanage login -m -r s0-s1:c1,c3,c8 dev1
[root@centos-7-2-t1 ~]# semanage login -l

Login Name           SELinux User         MLS/MCS Range        Service

__default__          user_u               s0                   *
dev1                 devuser_u            s0-s1:c1,c3,c8       *

So now all is well.

Providing the MLS/MCS range of the SELinux user is a superset of the range an individual user has, then you shouldn't have a problem.

A side note, I have found it is occasionally possible to sometimes modify the SELinux user to no longer be a superset; but then all other modifications against that user breaks until you fix it (i.e. make it a superset, then clear the categories or sensitivities you wish to remove from the member UNIX user mappings, then update the SELinux user); a bug perhaps.