Cатсн²² (in)sесuяitу / ChrisJohnRiley

Because we're damned if we do, and we're damned if we don't!

Tag Archives: blackhateu

Blackhat Europe: Abusing JBOSS

Abusing JBOSS (Christian Papathanasiou)

Abstract (source: Blackhat.com)

JBoss Application Server is the open source implementation of the Java EE suite of services. It’s easy-to-use server architecture and high flexibility makes JBoss the ideal choice for users just starting out with J2EE, as well as senior architects looking for a customizable middleware platform.

The pervasiveness of JBoss in enterprise JSP deployments is second to none meaning there is an abundance of targets both for the blackhat or the pentester alike. JBoss is usually invoked as root/SYSTEM meaning that any potential exploitation usually results in immediate super user privileges.

A tool has been developed that is able to compromise an unprotected JBoss instance. The current state of the art in published literature involves having the JBoss instance connect back to the attacker to obtain a war file that is subsequently deployed. The tool that will be presented at Black Hat does this in-situ and ultimately uploads a Metasploit payload resulting in interactive command execution on the JBoss instance. On Windows platforms, through the Metasploit framework a fully interactive reverse VNC shell can also be obtained and shall be demonstrated.

Depending on the platform that has been exploited and the level of access obtained, the tool is able to deploy the Metasploit payload as a persistent backdoor in conjunction with the Metasploit framework’s antivirus evasion techniques.

Due to the cross platform nature of the Java language, we are able to compromise JBoss instances running on Linux, MacOSX and Windows.

Talk Abstract –> Abusing JBoss

Speaker Bio –> Christian Papathanasiou

What is JBOSS ?

JBOSS Application server is an open-source implementation of JAVA EE Suite of services

JBOSS is used in enterprise JSP deployments and is insecure by default. It is also often invoked as root/SYSTEM

Typical industries

  • Financial
  • Publishing
  • Gambling
  • Defense

Often overlooked in perimeter hardening policies

Listens on TCP port 8080

Easy to test for presence of JBOSS on this port –> GET /jmx-console

Google dork allinurl:/jmx-console

Remote Command Execution on JBOSS

Reference: Red-Team paper (see links)

By using a similar method outlined in this paper, it is possible to upload a Metasploit payload and gain access to the remote server.

BSH Deployment

The BSH Deployer, or BeanShell Deployer allows you to deploy one-time execution scripts or even services in JBoss. Scripts are plain text files with a .bsh extension and can even be hot-deployed. This gives you scripting access inside the JBoss server.

The BSH script is used to upload a .war file on the remote filesystem. In the case of this attack a JSP shell is uploaded to give remote file-system. Once it’s deployed to the JBOSS server, it provides access to the server command-line.

JBOSS Autopwn

Designed to automate the process of exploiting JBOSS instances.

By uploading a JSP shell it is possible to then run further Metasploit payloads to connect back to an attackers machine.

As a Metasploit payload is used, the same issues found with AV engines discovering the payload. It is suggested to use msfencode to avoid detection.

Suggested encryption:

./msfencode -e x86/fnstenv_mov -c 5 -t raw | ./msfencode -e x86/countdown -c 5 -t raw | ./msfencode -e x86/shikata_ga_nai -t raw -c 5 | ./msfencode -e x86/cal l4_dword_xor -t exe -c 5

Demo –> jboss-autopwn (attacked Linux host – deployed reverse shell)

Apache Tomcat

Apache Tomcat is an open source software implementation of the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed under the Java Community Process.

Much like JBOSS, Tomcat also responds on TCP port 8080

Unlike JBOSS however, Tomcat is secure in it’s default state.

However a number of default username / password combinations exist.

  • tomcat:tomcat
  • both:tomcat
  • role1:tomcat

None of these roles however have the manager role, which is required to logon to the console. It’s commonly found that one of the default accounts is edited to be a manager, instead of the suggested method of creating a new account with complex password.

Once credentials are discovered the process is a lot easier than with JBOSS.

Tomcat Autopwn

Similar in functionality to JBOSS-autopwn.

The tool attempts to check the default username / password combinations to see if they are permitted to deploy through the management console. If they are, a JSP shell is uploaded and used to invoke a Metasploit listener.

Securing the JBOSS Management Console

The easiest way to secure the console, is to remove it completely. This can be achieved by removing the following directories

  • $JBOSS_HOME/server/all/deploy
  • $JBOSS_HOME/server/default/deploy

If this is not possible, then the port should be firewalled and restricted to specific IP’s. A username and password should also be set.

Securing the Tomcat Management Console

As Tomcat is secure out of the box, strict user management should be used to prevent weak username password combinations from being used. I would also suggest removing / changing the default users and firewalling the management console as with the JBOSS system.

Additional Links

For more information please see the Blackhat Europe website

Advertisements

Blackhat Europe: Practical Crypto Attacks Against Web Applications

Practical Crypto Attacks Against Web Applications (Thai Duong & Juliano Rizzo)

Abstract (source: Blackhat.com)

In 2009, we released a paper on MD5 extension attack ([1]), and described how attackers can use the attack to exploit popular web sites such as Flickr, Vimeo, Scribd, etc. The attack has been well-received by the community, and made the Top Ten Web Hacking Techniques of 2009 ([2]). In the conclusion of that paper, we stated that we have been carrying out a research in which we test-run a number of identified practical crypto attacks on random widely-used software systems. To our surprise, most, if not all, can be attacked by one or more of well-known crypto bugs. In this talk, we present the latest result of that research, where we choose another powerful crypto attack, and turn it into a new set of practical web hacking techniques.

We show that widely used web development frameworks and web sites are using encryption wrongly that allow attackers to read and modify data that should be protected. It has been known for years in cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks. Finally, we list several popular web development frameworks and web sites that are vulnerable to Padding Oracle attacks, including, but not limited to, eBay Latin America, Apache MyFaces, SUN Mojarra, Ruby On Rails, etc. These are all 0-day vulnerabilities. We show that even OWASP folks can’t get it right, how can an average Joe survive this new class of vulnerabilities? We strongly believe that this is just the tip of the iceberg, and the techniques we describe in this research would uncover many more vulnerabilities for years to come.

Talk Abstract –> Practical Crypto Attacks Against Web Applications

Speaker Bio –> Thai Duong, Juliano Rizzo

Practical Padding Oracle Attacks

First introduced by Vaudenay at Eurocrypt 2002

Two assumptions

  • Adversary can intercept padded messages encrypted in CBC mode.
  • Adversary has access to a padding oracle.

Demo (fail) –> Exploiting RubyOnRails ActiveSupport::MessageEncryptor

Finding potential padding oracles

  • Crawl the target to find BASE64 strings that look like ciphertext
  • Look for known source code keywords like javax.crypto.BadPaddingException
  • Look for routines that perform encryption and decryption that have some code to handle error while decrypting

Confirming the existence of padding oracles

  • Confirm the block size b
    • All padding oracle attacks need a correct b
    • Most common attack sizes are 8 and 16 bytes – Trial and error

POET – Padding Oracle Exploitation Tool –> Not yet publicly released

Cracking CAPTCHA

Some CAPTCHA systems are open to the padding oracle attack demonstrated earlier. A method to perform this has been developed using just JavaScript (in the browser).

Decrypting JSF viewstates

JavaServer Faces (JSF)

Although the JSF specification advises that view state should be encrypted and tamper evident, not many implementations follow that advice.

This means the Padding Oracle attack can be used to decrypt the view states of most JSF frameworks

By default, all JSF frameworks would display a very detailed error message if it fails to decrypt a view state

If error messages are turned off, it is still possible to perform the attack

JAVA ignores the extra (padding blocks) while decrypting and deserializing the viewstate. This allows for sending random padding at the end of the string to see the response. If the viewstate returns the same information the padding is valid. If the server returns a HTTP 500, then it’s invalid.

CBC-R

CBC-R turns a decryption oracle into an encryption oracle

Only a single bit of information is necessary to exploit a padding oacle

Cross-domain leakage bugs in web-browsers can help

Summary

  • Padding oracle attacks allow one to decrypt ciphertext without knowing the key.
  • We can use padding oracle attacks to crack CAPTCHA, and decrypt JSF view state, etc.
  • CBC-R turns a decryption oracle into an encryption oracle, and allow us to create malicious JSF view states.
  • Distributed cross-site padding oracle attacks allow one to distributively build a code book to map all ciphertexts to corresponding plaintexts.

Note: Blogging Crypto talks is almost impossible….. I’d suggest grabbing the slides, whitepaper, video and a lot of coffee!

Additional Links

For more information please see the Blackhat Europe website

Blackhat Europe: Attacking JAVA Serialized Communications

Attacking JAVA Serialized Communications (Manish Saindane)

Abstract (source: Blackhat.com)

Many applications written in JAVA make use of Object Serialization to transfer full blown objects across the network via byte streams or to store them on the file system. While Penetration Testing applications communicating via Serialized Objects, current tools/application interception proxies allow very limited functionality to intercept and modify the requests and responses like in typical web applications. I’m trying to introduce a new technique to intercept such Serialized communication and modify it to perform penetration testing with almost the same ease as testing regular web applications. For achieving this I have developed a plug-in for Burp Suite as a proof-of-concept. What makes this technique unique is that it is completely seamless and gives the penetration tester the same control and power that an application developer has.

Talk Abstract –> Attacking JAVA Serialized Communication

Speaker Bio –> Manish Saindane

Objectives

  • Simplify the penetration testing process of thick clients and make it completely seamless
  • Enable the pentester to edit JAVA objects in the same way that a developer would
  • Enable all of this using the currently available tools

What is JAVA Object Serialization ?

Protocol implemented by SUN for JAVA objects in a stream of bytes to be stored in a file or transmitted across a network.

JAVA Object Serialized data can be easily identified by the 0xac 0xed stream header

Challenges faced today

Used by thick clients or JAVA applets.

It’s not as simple as inserting a transparent proxy into the path. Current tools or applications do not offer seamless testing.

What can be done currently?

  • Modify raw HEX using a HEX editor
    • Limited usefulness
    • Not practical for complex applications
    • May corrupt data
  • Decompiling the class file
    • Can allow access to application logic
    • Certain values can be recovered (hard coded credentials, crypto algorithms, …)
    • Decompiling may not be straight forward (signed or obfuscated)

Belch –> plugin for Burp to transfer JAVA serialized communications to a HEX editor of your choice.

Assessing JAVA clients with Beanshell

  • Technique developed by Stephen D’ Vires from Corsaire
  • Made use of the BeanShell scripting language that was plugged into the client
  • Could be handy in identifying client‐side securitycontrols

Runtime Protocol Analysis (RPA)

Presented by Shay Chen from Hacktics at an OWASP Israel mee

  • Sniff traffic over the network
  • Split each request/response into individual packets
  • Modify the destination URL or Host within the packet with a HEX editor to a local server (protocol analyzer)
  • Send it to the Protocol Analyzer using netcat

This method is not completely seamless. Lots of steps involved, takes time to setup.

So what can be done? Suggested Solution

A plugin for the interception proxy using JRuby shell.

Solution based on JRuby 1.4.0, Burp Suite 1.2.x, Buby 1,8,x, A text editor

Why JRuby?

  • Easier syntax than a pure JAVA plugin
  • Can call almost all JAVA libraries
  • Interactive shell
  • Dynamic Type language

Advantages

  • Allows modification on the fly
  • Ease of use – Seamless
  • Hooks the JAVA development environment in your proxy
  • Can be used for other things with a little creativity

The demonstration looked interesting and certainly something I’ll be playing around with in the future. The Ruby interface makes things easy to use, and the connection with Burp Suite is an added benefit.

Tool to be made available on the Attack and Defense Labs site in the next few days

Additional Links

For more information please see the Blackhat Europe website

Blackhat Europe: SAP Backdoors: A ghost at the heart of your business

SAP Backdoors: A ghost at the heart of your business (Mariano Nuñez Di Croce)

Abstract (source: Blackhat.com)

In any company, the ERP (Enterprise Resource Planning) is the heart of the business technological platform. These systems handle the key business processes of the organization, such as procurement, invoicing, human resources management, billing, stock management and financial planning. Among all the ERPs, SAP is by far the most widely deployed one, having more than 90.000 customers in more than 120 countries and running in Fortune 100 companies, governmental and defense organizations.

The information stored in these systems is of absolute importance to the company, which unauthorized manipulation would result in big economic losses and loss of reputation.

This talk will present an old concept applied to a new paradigm: SAP Backdoors. We will discuss different novel techniques that can be deployed by malicious intruders in order to create and install backdoors in SAP systems, allowing them to retain access or install malicious components that would result in imperceptible-and-ongoing financial frauds.

After the description of these techniques, we will present the countermeasures that should be applied in order to avoid these attacks and protect the business information, effectively reducing financial fraud risks and enforcing compliance.

Furthermore, we will release a new Onapsis free tool that will help security managers to automatically detect unauthorized modifications to SAP systems.

Is your SAP backdoored? If your answer is “I don’t know,” then you may consider attending to this talk.

Talk Abstract –> SAP Backdoors: A ghost at the heart of your business

Speaker Bio –> Mariano Nuñez Di Croce

Introduction

SAP is the largest provider of business management solutions around the world

  • More than 140,000 implementations globally
  • More than 90,000 customers in ~120 countries

Used by fortune-500 companies, government, defense agencies

Backdoors

What makes backdoors in SAP so important?

Very little public information on how they can affect SAP platforms. Just because it’s not publicly discussed, doesn’t mean it’s not being used. We need to talk about this to understand the risk.

The biggest mis-conception in SAP security is that SAP security is simply about segregation of duties.

However SAP suffers from vulnerabilities like any other software.

Security is more than just about the user privileges.

After initial compromise –> see previous presentations

After gaining access, the attack can install a backdoor to maintain access.

Due to intrinsic Trust relationships, a high-privileged

takeover of one technological component results in a

complete compromise of the whole platform.

By owning the OS or the Database, an attacker can install a backdoor and use it to maintain control of the system.

A Ghost in the User Master

The User Master is accessed when a user connects to the SAP system using the SAPGUI. The password provided by the user is checked against the password stored in the User Master.

SAP has however used a number of hashing mechanisms. Due to backwards compatibility these older (insecure hashes) are still stored in the User Master. This opens the system up to a number of attacks.

  • Initially SAP supported an 8 char password stored as MD5
  • Current versions support a 40 char password stored as SHA-1

By default, the User Master stores the older version alongside the newer SHA-1

The system uses a profile parameter – login/password_downwards_compatibility to set the has to be used

  • 0 – Downwards compatibility disabled
  • 1 – Downwards compatibility enabled (Weak hashes not evaluated)
  • 2 – If the hash fails to match, the older hash is checked – Log and Deny access
  • 3 – Same as 2, but logon is successful with the older hash (still logs)
  • 4 – Same as 3, but no log is created

This parameter can be modified dynamically without a restart

Demo –> Resetting the old hash –> Altering the profile –> attacker logs on with old hash

As the attacker has only changed the old hash, the administrator can still logon without problems (using his password). The attacker however, can still logon using the old hash password he changed. This gives the attacker an almost invisible backdoor, as there is no new account, and logs will not show the logon using the old hash (with profile set to 4).

Protection

  • Monitoring the system values and check for changes. If the profile value is altered, there is a problem
  • Implement dedicated authentication group for U* tables

Backdoors in SAP Business Modules

Once you are logged in, you interact with the system running transactions. These transactions are run using ABAP Programs/reports.

ABAP programs are divided into 2 types:

  • Standard (Shipped by SAP)
  • Custom (in-house apps -starts with Z* or Y*)

Standard programs can be modified, but it’s strongly discouraged

ABAP programs are stored in the System’s database

  • Table REPOSRC contains compressed sourcecode
  • Table REPOLOAD contains ABAP load (bytecode)

Typically SAP prevents changes to the system in PRD systems. All changes are made in DEV.

Unauthorized modifications at the SAP layer are possible, but not trivial

Why go the hard route, when an attacker can go straight to the database. There are no CRC or signature checks on ABAP code stored in the database.

Demo –> Alteration of code in the database that changes payment information for newly added user

PoC attack inserts ABAP bytecode into the database. The SAP system will then compile and use it the next time the functionality is used.

Backdoors in the Authentication Procedure

Certain critical ABAP programs are protected to prevent access to the sourcecode.

The SAP system checks for a magic value (*@#@@[SAP]) in the first line of the code. If it’s present, then the content is not returned. Alongside this check, there is also a hard-coded kernel check to prevent access to the SAPMSYST (User Authentication Procedure) and 2 other key functions. The check is however performed on the ABAP program name. To bypass this, an attacker can create a new program in SAP and copy the code from SAPMSYST to his newly created program. This will then bypass the kernel protection as the name matching no longer triggers the protection.

Demo -> Reading and alteration of the SAPMSYST program to permit a backdoor –> backdoor logs credentials to a logfile

As the SAPMSYST program is core to SAP, a restart of the process is required to force the new bytecode to be created and the new backdoor functionality to take effect.

Protection

  • It’s not possible to detect and protect against backdoors from within the SAP system itself.
  • External tools are needed.

Onapsis Integrity Analyzer for SAP

Tool due to be released in 2 weeks (after HITB conference)

Why you need it? It’s not feasible to detect backdoors from inside the SAP system itself:

  • Backdoors can leave the Program’s “Last modified date”unchanged
  • The analysis programs may have also been manipulated to hide a backdoor’s presence

Onapsis Integrity Analyzer connects with the Database and performs “snapshots” of sensitive ABAP report tables — Signature only, no ABAP code stored

Periodically, new snapshots are compared

These checks obviously need to be implemented before your SAP system is backdoored.

Conclusion

  • Backdoored systems are not just an SAP problem, they can affect any kind of system
  • If an attacker can gain total access to your database system, then it’s very difficult to restrict their access to SAP
  • Backdoored applications can be a serious business impact
  • It’s all about the money

Best protection is to minimize the chances initial compromise

  • Automatic controls
  • Regular security checks
    • Vulnerability assessments
    • Penetration Tests
    • Security Audits
  • Onapsis’s Integrity Analyzer for SAP can help you to implement more in-depth reactive controls.

Additional Links

For more information please see the Blackhat Europe website