Do you know what your ERP is telling us?

Interesting engagement I had a few weeks ago, a client wanted assurance on their ERP – Oracle E-Business suite, to be specific. I spent a few weeks just to formulate an efficient strategy and be able to cover most controls from an insider threat perspective and an external authenticated attacker angle.

For this post, I shall focus on an external unauthenticated attacker angle with a bias to information disclosure, hence the title. No intrusion – give us consent to your environment and I shall be happy to demo. 🙂

The Oracle EBS suite is a pretty massive estate – version 11 for instance is reported to have around 15000 JSP files, 800 enabled PL/SQL packages and procedures,countless forms, countless servlets etc. This, ofcourse, increases the attack surface considerably: attackers are happy, blue teamers should be worried.

Before we dive in to Oracle EBS, I should say SAP also has its own vulnerabilities too, which I should cover in coming weeks especially around permissions, storage of passwords and use of default user credentials –SAP, DDIC, EARLYWATCH, anyone?

What info can we get from Oracle EBS version 11 as an external unauthenticated user?

  1. Log files:

What do most log files usually have? username, source IP/name, destination IP/name, protocols in use, descriptive error messages, service name/properties, right? What if I told you can get all that as an unauthenticated external user?

sqlnetlog_edit

Focus on the blurred parameters and the framed items in the screenshot. Lots of (useful) information, don’t you think?

         2. Upload folder

As an unauthenticated user i.e. guest user one is able to reach an upload page…

upload_master_edit

Looking closely, we can see that we are authenticated.. It would interest you to find out what you can upload and how it impacts the security of your EBS suite. As earlier promised?, I won’t delve much into the exploitation, but rather focus on the amount of information an unauthenticated attacker has access to.

         3. Cookie properties:

Any attacker loves cookies. Main reason: they hold keys to sessions:

cookies_edit

         4. Create form:

Want to create a form? As an unauthenticated user? No problem

createform_edit

           5. Status of servlets:

Want to know version of servlets and if they are working? No problem!

working_edit

               6.  A few configuration files:

pasta_edit

                7. Version disclosure:

servlet version_edit

8. Diagnostics page:

A cool diagnostics page to get even more information 🙂

AOL test_edit

8. Username and Passwords:

Saving the best for last – username and passwords!!!!!!

Passwords_edit

The above passwords are SHA-1 encrypted and are easily decrypted. As a matter of fact the above are the default passwords shipped with the Oracle installation.

Remember this is just got by sampling some of the JSPs, servlets and forms. It is not realistic to scope in an engagement for all the JSPs as an external infosec consultant. As a resident infosec engineer, I would be keen on all the services, JSPs, servlets, forms etc. Remember: attackers need to get it right only once, blue team needs to get it right ALL the time.

Also, keep in mind while doing a security audit for an ERP, focus is how much data can we get and not necessarily an OS shell.

This post wouldn’t be complete without some mitigating controls:

  • Reduce attacker surface by removing the JSPs, servlets, services, forms not in use. This should be a well planned operation and involvement from the business is key. Trust me you should be able to reduce attack surface by up to 95%. I would be happy to hear feedback on this..:-)
  • Apply periodic Oracle EBS critical patch updates CPUs – this is very key.
  • Block access to links that an unauthenticated user wouldn’t need access to – you could start with the ones demonstrated in this post and others that you discover; create a custom 404 page to redirect traffic to these pages.
  • Review access logs and disable unnecessary access

I should be putting up another post on the EBS version 12 pretty soon…cheers!

Advertisements

Should we be worried? Huawei router …Part II

This is a follow-up of this post...

Good. Now we are at par.

After getting the router config as in the earlier post, I got to comb through the router config. Interesting things, I tell you.

One of the parameters, X_HW_MonitorCollector has a server URL of yjyx.gd.edatahome.com and a tftp port of 6169.

edatahome

As shown above, the setting for this configuration seems disabled as the Enable switch is set at 0, and the number of entries being monitored is set at 0. Maybe we should rest easy?Should we?

A quick whois check of edatahome.com is as below.

edatahome2

Hmmm….should we be worried?

Auditing linux , unix OS..in 120 seconds flat

Well, most of us have seen the movie Gone in 60 seconds, so I decided to write a baseline script for auditing linux and most unix operating systems in well under 2 mins – averages about  130 seconds on my test Centos and Red hat distributions.

The script is modeled around most of the operating system controls as recommended by the Center of Internet Security.

What I really like about the script is the ease of downloading, using it and customizing it to fit your security risk appetite, and operating system flavour.

Below is a readme of the tool:

Readme

Below is a screen grab of how it looks like as it starts auditing your operating system:

start1

Enough with screenshots, go have a look for yourself here.

Always happy to hear your feedback, issues and ofcourse pull requests 🙂

Update!

Nix – Auditor 2.0:

Change Log:

Added color variables BLUE, RED, NC (NO COLOR) and GREEN on lines 210 – 213 Applied color variables to “passed” and “failed” results in function func_wrapper on lines 1171 and – 1173

Huawei HG8245H router “privilege escalation”…Part I

This is a prequel to this post here

Well, I got to play around with my router a few weeks ago. My router, a Huawei HG8245H version, is pretty decent for home use.

First things first, the login password is smack on the bottom of router as below.

routerpic

Most routers have a well known default password, infact there are multiple sites dedicated to document that. So I got curious to know what info I could get using these credentials.

A quick google search says that the user root/admin is a normal user with the telecomadmin/admintelecom being the super user. Funny enough, I was unable to log in using the admintelecom/telecomadmin set of credentials. The superuser account allows a user to have access to other options, notably backup configuration settings, edit and load router config file etc.

An explanation I got as to why this is the case is because as soon as the router gets connected to ISP WAN it grabs configuration from ISP and this particular set of admin credentials don’t work. So how do we bypass this?

Proof of concept:

  1. Enter web interface (http://192.168.100.1) using root/admin credentials
  2. Reboot the router.
  3. Disconnect fibre cable as it restarts
  4. As it restarts, try to log in on http://192.168.100.1 as telecomadmin/admintelecom

Voila! You are in, as superadmin, with more options to tweak the router 😀

telecomadmin login

        5. To elevate your normal user root to superadmin status. Download router config file           from System Tools > Configuration File.. This  file named “hw_ctree.xml” is                             encrypted and appears as below:

encrypte

Fortunately, we can decrypt the router config file using any aes decryption tool.

6. Proceed to decrypt as below:

ddecrypt

and here we have our plaintext config file:

interesting users

For this post, our area of concern would be the part highlighted below:

2more users

Notice the different userlevels for the two users (root and telecomadmin), 0 and 1. Now we know userlevel 0 is superadministrator.

        7. Edit the root user line to userlevel 0. Save file and decrypt it

        8. Log in to our web interface, upload the new config file and restart router.

       9.Once restarted, log in as root/admin, and enjoy the new options available  🙂

I called up Huawei to notify them of this and after a rather lengthy discussion they finally emailed me: “We will not track this issue as a vulnerability. If you still have some different option please never hesitate to contact us. Thanks again for your concern about the security problems of Huawei products. If you ever find any potential security issues in Huawei products in the future, we are looking forward to working with you again.”

I would,however like to thank Huawei’s quick response and follow up on their part. Many security researchers would have however have wished that we would fix this issue as we all know how attacks like DDOS are being propagated using default credentials in routers or other IOT devices.

Find Part II here

Lateral movement..Part I

Scenario: you are a normal user in your company’s domain. No admin privileges. Nothing. You can’t even install a program in your machine.

What if I told you, that you can be the local administrator on your machine and probably on MANY more in your organization?

I am not able to count the number of things you are able to do as a local admin (evil / non-evil) :-)…for this post am going to demonstrate how to simply move from a normal user and gain local admin privileges. This is an attack vector I have been using in various security assessments I have been doing. Time to let the cat out of the bag…haha.

 

What are Global Policy Preferences Passwords?

In a nutshell, sys admins have 100 plus machines on a domain, and want to configure all the machines, chances are they are bound to use the same local admin password to install programs and configure the machines in the domain. They use the GPO to do this; hence the use of the Global Policy Preference Password to conveniently push same password to all hosts in the domain. Convenience at the expense of security – how many times do we see that??

 

Ways to find the GPPP password?

To be honest, countless. But I shall show some few here..

  1. Manually traversing to \\<domain name>\SYSVOL\<domain name>\Policies\

Look for *.xml files; specifically Groups.xml or Services.xml.

Groups.xml

Opening one of the Groups.xml files we see a cpassword field which is encrypted. Game over? NO. Microsoft published the decryption AES key here – a whole 32-byte AES key. Let that sink in.

So basically decrypt and have your local administrator password…in CLEARTEXT.

2. Use Powershell tools:

For the lazy ones, there are multiple powershell tools to find the GPPP. An example is the Get-GPPP.ps1 ,shoutout to this smart guy @obscuresec..

Get-GPPP

3. A custom tool designed to explicitly output the password in cleartext – gp3finder by Oliver Morton:

GP3finder

4. Trust metasploit not to get left out…msf FTW!

msf gppp

Okay,we get the point – it’s too easy to get this password.

Now that we have the local admin password..

The mere fact that you have got this password from GPPP tells you one thing – chances are that it is used on most if not all machines in the domain! Think about the lateral movement that is possible, the dumping of passwords – mimikatz, anyone?

That doesn’t so good for the blue teamers, right? In the next post we are going to see practical ways to mitigate this.

Remember this is not a new attack vector, reason I am putting this up is because in all penetration testing assessments I have been doing, this has been a recurring vulnerability.