Corelan Cybersecurity Research

Welcome back friends, at day 2 of BlackHat Europe 2012, held in the Grand Hotel Krasnapolsky in the wonderful city of Amsterdam.

Today, I’m going to do things slightly different.  I will try to post write-ups immediately after a presentation (and I’ll add in pictures later).   I will basically update this page all the time, so keep an eye on it every 2 hours or so.

The first talk I attended today, after getting rid of a mild headache, is

Defending Privacy at the US border

Marcia Hofmann and Seth Schoen, from Electronic Frontier Foundation, spent some time working on a paper (published in december 2011) about traveling to the US, and the legal and technical aspects of searches of devices at the US border.  During today’s talk, they will look at :

• What can the US government do at the border ?
• What are the search policies and procedures
• How to choose a strategy for international travel with digital devices
• Technical and common-sense measures

Marcia says that, although she is a US lawyer, most of the things they will talk about in the talk apply to everyone traveling to the US.

Problem description

The border is a difficult place, Marcia says. Border tend to introduce stress, sometimes confrontational situations.  There are certain exceptions to familiar rules about rights when dealing with law enforcement.  At the border, things are different.  In terms of “search and seizure” exercises performed by the government, the 4th amendment states that the government needs to have a warrant to search your stuff.  This rule does not apply at the border. The US courts have held that searches at the border are per se reasonable, so no warrant is needed.  (United States vs Flores-Montano, 541 VS 149 (2004)).  Basically, the US has a special interest at protecting itself from undesirable things and people coming across the border, this has major implications on what they can do.

Various organizations, including EFF, state that this is too expensive.  Electronic devices can contain a lot of private information.  Nevertheless, courts have been quite unsympathetic to the arguments raised by these organizations and are reluctant to limit the searches.  EFF feels that there is a difference between the private things stored in luggage, and what is stored on an electronic device.

Agency search policies and procedures

• TSA : handles domestic security; searches you before you get on a plane in the US. You don’t really see them at the border, but they are the ones who will scan you and your luggage (naked body scanners, etc)
• CBP : primarily responsible for border inspection
• ICE : enforcement agency; primarily investigates immigration and customs violations, but has authority at the border.  When an issue escalates, these may be the ones that might search a device.
• INS : doesn’t exist anymore

Marcia continues by explaining what these agencies can do :

• detain you (temporarily) (up to a few hours)
• detain possessions temporarily  (including devices to analyze & copy data)
• ask lots of questions (though only a judge can actually force you to answer those questions)
• refuse admission

Both CPB and ICE have published public policies.  CBP, for example, can search electronic devices and data at the border “with or without individualized suspicion”.  They are allowed to keep it for a “brief, reasonable” time (usually less than 5 days).  They are allowed to send the device or data to another agency to seek of help (for example in case of encrypted devices).   At the same time, it’s unclear what happens to copies of the data and how sensitive data (medical / privileged information) is handled.

ICE’s policy is very similar. They can also search devices and will generally complete searches in 30 days.  Again, it is unclear how they handle copies of your data.

How should we, travelers, interact with them ?

• Avoid giving border agents excuses to get curious/alarmed about you and your possessions.
• Do NOT lie to border agents
• Do NOT obstruct an agent’s investigation
• Be polite to agents

You may choose not to answer questions.   Keep in mind that it may have adverse consequences.  You may get detained temporarily, lead to heightened scrutiny of future border crossings or even refusal of admission.  Marcia mentions that it’s preferable to have (genuine) external reasons for not answering, such as an employers/company policy that prohibits you from giving a password to a third party.

Also, keep in mind that the public policies often don’t state how agents must handle certain scenario’s, which includes that there is a lack of what they can/will ask.  The key is to remember that you should not lie to agents.

Choose your strategy

As a general rule, your strategy depends on the situation you’re in.   Some things to consider are :

• Your citizenship, immigration status (this might make you more vulnerable)
• Time sensitivities (do you have a connecting flight to catch ?)
• Your personal tolerance for hassle from border searches
• How important is it for you to have access to data during your travel ?  Maybe you can travel with a blank device and download data when you’ve arrived at your destination
• How good will your internet access be during your travel (which may have an impact on the previous point)
• the places you’ve visited on your trip before entering the country
• your history with law enforcement

Strategies for protecting your data at the border

Next, Seth continues the presentation by listing some ideas to try to protect yourself within the legal boundaries available to you :

• keep regular encrypted backups elsewhere
• encrypt the storage media you’re taking along on your trip
• use online network storage only

Some additional ideas are listed in the aforementioned paper.  They include

• Separate travel OS images.  Use one at home, use one at travel.  (‘dd’ or ‘ghost’ the image when you need it)
• upload data & download it later.  You may want to check how your data will be encrypted in the cloud and decide to use your own encryption if needed.
• Send your devices (encrypted) by mail/common carrier.  It might still be subject to inspection, but they can’t ask you for your password.  They probably have no authority to alter/bug equipment without a warrant.

Use strong networks for full disk encryption.  Government agencies have computing power that allow them to crack a lot of passwords.  Use sentences as passphrase (long, something meaningful to you… for example parts of a lyric, a book, etc.  If you use more words, the more complicated it becomes to crack the password, while it’s still easy to remember the password.

How about forced decryption ?

In the US, only a judge can force a person to reveal information to the government and only where the person doesn’t have a valid constitutional right against self-incrimination…  In other words, you have the constitutional right not to be a witness against yourself.  Keep in mind that this is not the case in all countries around the world (France, Belgium, the Netherlands, UK, Australia, etc  can force you to disclose your key).  Also, the type of information needs to be “something in your mind”, not on paper or another physical location.  It applies to a password that you have memorized.

Even if you have the right not to disclose information, it might still have adverse consequences.  You may get detained, questioned, or even refused admission.    It’s important to set your strategy before you leave and think about how you will deal with requests to decrypt.   IT policies can be helpful : Don’t let travelers know their passwords until they reach their destination and have the password reset when the have arrived.  Or, at least, implement a policy that prohibits employees to share their passwords with anyone else.  This made me think that maybe some sort of NDA might be helpful as well in this case.

Not knowing your password  (randomly reset it and have it sent to you via an out-of-band mechanism) may be a strategy… but it’s a gray area strategy.  It’s unclear how border agencies will react to it or will believe you if you state that you don’t know your password.   Seth demonstrated a technique to add a keyslot to an encrypted drive with a random password, send it at home, and destroy the original keyslot before starting your travel.  That way, you cannot decrypt the volume or disk even if you wanted to, until you get home.

Without an actual criminal investigation, they can’t force you to go home, get your password and decrypt your data.  They would need a warrant to do that.

Seth also talks about KeyPad, a design by Roxana Geambasu et al, providing an alternative way to “not knowing your password”, and offers some additional advantages/benefits for theft-prone devices.  Definitely worth while checking this out.   He also mentions that it would be nice if Google would implement this in ChromeOS.

Special considerations

Keep in mind that it’s relatively hard to delete stuff, forensic techniques are quite advanced today.   Thinking about a secure delete procedure is important.   Investigate if the “secure delete” feature in your OS actually IS a secure delete.  Some experts say the only way to do it is by using encryption.   Even performing a multi-pass overwrite may not be needed… the key is that you have to make sure your blocks are actually overwritten… the OS might prevent you from doing that.

Auto-save features may save unencrypted copies of files (which can be retrieved later), so it’s preferred to implement full disk encryption if you can.

Mobile devices often lack a lot of features to protect the data residing on them.   Most of them don’t have full disk encryption, secure erase, …   Don’t forget about camera’s either !

An interesting questions raised by one of the attendees was  : “If the border agency gets your password, can you they use it to read your email in the cloud ?” Marcia believes they would need a warrant to do that, but also says we’ll probably see cases like this in the future, so it remains to be seen how a judge will deal with this.

Seth concludes the presentation by mentioning that a Canadian organization recently published a similar whitepaper on this topic, applying to border searches in Canada.

This was truly a great talk and answered all of the questions I’ve had about this topic for a while.

 

 

An assortment of database goodies

David Litchfield (from Verity software, now acquired by Accuvant) started out in buffer overflow exploitation and is well known for finding ways to defeat safeseh protection introduced in the Windows OS a couple of years ago.  He has moved into database security and forensics.

One of the things he worked on was building a tool to own databases and report findings in a nice way, which triggered the acquisition of the V3rity Software company by Accuvant.

The 3 main topics for today are :

• Lateral SQL Injection revisited
• 20/20 Vision to blind SQL Injection in Oracle PL/SQL gateway
• Detecting blind SQL injection in logs in the absence of POSTDATA or QueryStrings

David explains that most of his talk is going to be based on demo’s (so I will try my best to catch the important items and translate them into text in this post).

Lateral SQL Injection

He starts by explaining that the date format in Oracle SQL queries are an often overlooked area that might allow for injection. Datetype objects are often considered as being safe, and demonstrates how setting the nls_data_format to ‘””  (double quote followed by single quote, wrapped inside single quotes) followed by “and scott.get_dba()=1–” throws an error message when date_proc(sysdate()) is executed after that, you can get execution of code by changing what get_dba would do (using the injection).

By changing how numbers are represented (NLS_NUMERIC_CHARACTERS), a vulnerable procedure that takes a number & concatenates it (assuming that input is safe), allows for code injection & execution as well, allowing you to gain dba privileges.

Blind SQL Injection

Blind SQL is the condition where can inject arbitrary SQL but you have no knowledge of the results (because nothing is returned, not even error messages).  This often happens in login pages. If authentication doesn’t work, it just redirects you back to the login page, or just tells you whether authentication was successful or not.   By default, Oracle will throw a 404 page if something goes wrong, without providing an error message regarding the issue.

Since Oracle will not batch multiple commands in a SQL Injection scenario, you can use the dbms_xmlquery.newcontext() function to have it execute a block of SQL instructions).   Using that functionality, and the fact that the web server may show a “invalid login” message (using a htp.print statement), it might be possible to get more information about what happened in the background, about the environment and context.  In general : instead of triggering an error page, it might be possible to use a backend database htp.print statement to write something to the screen;  output taken from the response of your SQL query to show it on the screen).  In other words, you can use this functionality to report back information, thus increasing visibility (and turn the blind SQL injection into a full vision SQL injection)

Detecting Blind SQL

David demonstrated a C# tool he wrote (will be released later) to search logs.

By parsing log information, he can show IP addresses, requests and the time it took to execute a certain query.  By graphing the results, the tool can show sql injection attacks in a very visual way.

Even if the attacks are spread over time, you would still be able to detect slower attacks (if you are using the tool for detection purposes).  If you also bulk upload the web server logs into the database, you have the ability to drill down, looking at URI/Response Code and Counts associated with connections from certain IP address, and see what exactly happened.  Finally, by looking at a given URI, you can look at the timestamps, the response time and codes associated with a connection and find attacks, even if the attacker used some kind of delays in between connections to hide his activity.   The response time value indicates success or failure  (< 999 = 0, > 999 (more seconds) might indicate a query that took longer and might be successful).

 

At the end of the talk, David explains that he intends to finish the tool, complete a whitepaper to go with it and make it available on the Accuvant website soon.

Before going to lunch, David and the guys from Accuvant were kind enough to go on a picture with me :

(Ryan – Dave – Me – David – Shawn)

 

Cyber-Attacks & SAP Systems : Is our business-critical infrastructure exposed ?

In the first talk after lunch, Mariano Nunez (Onapsis).  I always feel some sympathy for people who need to present right after lunch, and Mariano realizes this is a very difficult time-slot  (and says it’s okay to take a nap if it’s too difficult to stay awake :) )

He starts his presentation by a short introduction on Onapsis and some of his previous talks and activities, including his work on the first open source ERP/SAP security auditing tool.

SAP, with more than 140000 implementations and more than 90000 customers, is the largest provider of business management solutions in the world.  It’s often part of business critical infrastructure, a fact that is well recognized by attackers.  If an SAP platform is breached, an intruder would be able to obtain a lot of internal sensitive information, sabotage processes, engage into financial fraud, etc.

In fact, SAP is critical for our lives.  Over 70% of the world’s beer and chocolate companies run SAP… :)

5 years ago, SAP security was purely based on segregation of duties controls. From an implementation point of view, the segregation of duties matrix got mapped with SAP transactions and authorization objects.  Most large organizations had “SAP security” in place : They spent thousands/millions of dollars to pay consultants.   On top of that, most “SAP Security” related documents only focused on the SoD implementation.

Mariano tells that, he was hired to do a web app pen test back in 2005.  The web app was running on an SAP Web Application Server (which was the first time he got to play with an SAP system).  He discovered issues on the framework itself, checked with various vulnerability report services online and discovered the issues were not reported anywhere.  He published his findings at BlackHat 2007.  At that time, the total nr of SAP vulnerabilities reported was 90.

The reality is, Mariano continues, that SAP Security is a complex matter that must be addresses holistically.  SoD controls are necessary, but are certainly not enough. An often overlooked part of the implementation is the business critical infrastructure supporting the SAP installation.  It is clear that, no matter how strong the SoD layer is configured… if one of the system components gets compromised, the hacker would have the ability to bypass any of the SoD controls.

Of course, if the SoD controls are not properly set up, the hacker may be able to do more with the system by default than what he’s supposed to do… but it assumes that the hacker has a valid account.  That’s why the attacker will focus on the underlying infrastructure because he wouldn’t need a valid account.

Today, the number of reported SAP vulnerabilities have increased to 2068.  A side effect of this is that the number of patches has increased as well, and we all know applying patches to critical systems such as SAP may not be easy.

Internal and External threats

Today, it’s not uncommon anymore to find SAP systems online.  (Tip : use shodan to look for “SAP”, you’ll find more than 2000 SAP Web Application Servers online).

Is it more than just SAP systems?  When you acquire SAP software, the agreement specifies that you have to allow remote access through a special component, called SAProuter.  It means that there needs to be some kind of public exposure already, by design.

Other network services (Dispatcher, Gateway, Mgmt console, etc) often end up being accessible over the internet as well.

Mateslab, a non-profit research group, analyzes the availability of ERP systems on the internet.  Based on their research, they discovered at least 16 systems exposing the SAProuter to the internet in the Netherlands.

Current security level of SAP implementations

How good or bad does it look in real life ?   Mariano explains that, since starting doing pen tests on SAP in 2005, more than 550 systems have been audited so far.   In all their audits, they

• only got network access to the regular end-user network segment
• only received a list of target IP addresses
• did not receive user credentials

Results :

• Over 95% of the systems were vulnerable, in a way that would allow full system compromise or at least providing trivial ways to steal data, modify data, etc.
• Only 5% has proper security audit logging in place
• None of the systems had the latest patches applied.

Top 11 vulnerabilities

Next, he introduces Bizec.org, a non-profit organization, which gathers and maintains the TEC/11 list, which explains the most common mistakes/security vulnerabilities in SAP implementations.  You can use this overview as a checklist to perform proper configurations to secure the SAP environment.

To make things more tangible, Mariano demonstrated an attack against an unsecured SAP Gateway, using bizsploit.  First, he performs a SAP portscan (using the discovery connector).  The bizsploit framework offers a variety of modules that allow you to identify weaknesses and exploit them.  Using a few simple commands, he successfully exploited a vulnerable RPC service on the SAP gateway, spawning a remote shell, running with SAP admin privileges.   Since the database trusts this user account, you can further gain access to the database without further authentication. Game over.

Defending the SAP platform

The company often faces a huge number of issues to properly defend the environment :

• Knowledge : SAP requires very specific knowledge & understanding on how to secure an SAP system.
• Scope : the entire platform must be secured :
• Every landscape (ERP, CRM, SCM, …) in the organization, and every SAP system in each landscape (dev, staging, production, …), every client and every server, and every parameter (1500+)
• Periodicity : Audit & secure on a regular basis, at least after each SAP Security Patch Day to verify if the issues have been fixed.

Also, because of the integration with other platforms (AD, etc) and the size/magnitude of the SAP installation, it’s often unclear who is responsible for what.  Unclear roles & responsibilities in terms of administration, configuration and security, will undoubtedly introduce issues & leave loopholes.

What makes SAP so different, for the regular IT Security teams to be NOT be in control of it ?

Conclusions :

• Segregation of duties are necessary, but not enough
• SAP infrastructure layer can be exposed to technical security vulnerabilties
• The attacker often does not need a user/password (increased higher threat profile)
• Patching is difficult
• Companies state that their SAP systems have not been hacked… but at the same time, statistics show that 95% of the companies don’t have logging/auditing enabled.

SAP has published some security guidelines which, if implemented well, will certainly increase the overall security level. At the other hand, vulnerabilities in other parts of the environment (Oracle database, Active Directory, etc) might still allow a hacker to take full control of the SAP layer.

 

Attacking IPv6 implementation using fragmentation

Antonios Atlasis (from CSCSS – Centre for Strategic CyberSpace + Security Science) starts with presenting the agenda for his talk :

• fragmentation in IPv4
• fragmentation in IPv6
• examination of fragmentation issues in IPv6 implementation in some of the most popular OS
• conclusions

IP Fragmentation

Fragmentation is required to allow traffic to carry more data than a single datagram can contain (default MTU: 1500 bytes).  The packets will get reassembled by the receiver.  By using flags (D = Don’t fragment, M = More fragments to follow) in the IP header, the sender & receiver can agree on how to handle fragmented packets, and the intermediate routers will know how/what to do.

Fragmented packets have an offset (relative start in the unfragmented data) and a length field to allow the receiver to reassemble the packets.  The last packet will have the M flag set to 0 (to indicate the last packet of the fragmented data)

Fragmented traffic is often used to fool IDS/IPS systems.  Commonly used techniques include

• injection attacks
• evasion attacks
• disordered arrival of fragments
• IDS flooding with partial fragmented datagrams
• selective dropping of old and incomplete fragments
• overlapping fragments

How about IPv6 ?

We all know the available IPv4 address space is soon to be exhausted, so companies and providers are slowly starting to implement IPv6. It’s important to understand how IPv6 works and what potential issues could be.

IPv6 header length is limited to 40 bytes (constant), but the use of extension headers has been introduced, which add additional functionality.

Fragmentation fields (offset, D & M bits) have been moved to the fragment header (or removed).  There can be multiple extension headers in a packet.  From a packet point of view, the header + extension headers are unfragmentable.  An IPv6 packet contains the unfragmentable part, and is optionally followed by a fragment.

IPv6 tries to minimize the use of fragmentation. The RFC states that, in case of fragments, the size of the data must still be larger than 1280 bytes (except for the last part of course) If required, link-specific fragmentation and reassembly must be provided at a layer below IPv6.  In addition to this, there is a 60 second time limit.  If not all fragments are received within that timeframe, the packets are discarded.  Some additional rules apply as well (related with size of the datagram etc – each packet, except for the last one, should be an integer multiple of 8 octets)

RFC5722 recommends that overlapping fragments should be totally disallowed.  This includes discarding all packets related with the current session.

Let’s play a bit

Antonios elaborates on some tests he performed using scapy, against a variety of targets/popular OS’s, including OpenBSD, Ubuntu, Windows 7, FreeBSD, all simply configured with an IPv6 address using default settings.

Scenario 1 : Tiny fragmentation (without overlapping)

What happens if you send packets with fragments smaller than 1280 bytes ?  In his tests, he noticed that all OSes sent an echo reply back to the sender and accepted the packet, while they shouldn’t according to the RFC.

So, what’s the big deal ?

in IPv4, a fragmentation attack, providing different flags in consequent packets, using overlapping fragments, it was possible to bypass firewall rules.

With IPv6, he explains, without deep packet inspection (complete IP datagram reassembly before forwarding it),it’s even possible to evade firewall rules without having to overlap any fragments.  You need 8 byte fragments and split the Destination Option headers to 33 fragments to do it, and the layer-4 protocol header will start at the 34th fragment.

Using a scapy script to reproduce the issue, he discovered that FreeBSD, Ubuntu 11.10 and Windows 7 were immune to the attack. Ubuntu 10.04 and OpenBSB were susceptible because they accept the fragmentation overlapping with the first fragment overwriting the second one.   As a result, you can use this behavior to do some basic OS fingerprinting and/or perform IDS Insertion/Evasion.   The fact that the 1st fragment overlaps the second does not introduce an issue in terms of evading firewall rules.

Next, he introduces the Paxson/Shankar model, and presented his test results which indicate issues again with Ubuntu 10.04 and OpenBSD 5.

So far, the linux kernel 2.6.40, FreeBSD 8.2/9 and Windows 7 seem to be immune to fragmentation attacks.   Using an different, simple 3-packet model, he did notice that Windows 7 complies with RFC522 (discarding all fragments when overlapping occur), unless only the 1st fragment is overlapped.

He finished the presentation by showing some test results on using reversed fragments and double fragments, and by doing some demos.

Conclusions :

• All Operating Systems accepted tiny fragments
• None of the Operating System is RFC 5722 compliant
• Ubuntu 10.04 and openBSD 5 were proven the most susceptible to fragmentation overlapping attacks among the test OS, each one following the reassemble policy
• FreeBSD discards any overlapping fragments and appears to behave consistently (a lot better than the other tested Operating Systems)… but still does not apply with RFC 5722
• Windows 7 seems to have fewer issues, but there are cases where you can get responses back (and thus accept certain overlapping fragments).
• The impact of the issues discovered vary and can lead to OS fingerprinting, IDS insertion/evasion and in some cases even firewall evasion.
• OS vendors : please create fully RFC compliant products.

 

That’s all folks

Apparently, Jerome Athias’ talk was cancelled, so that concludes my report of day 2 at BlackHat EU.  Check back tomorrow for my coverage of the 3rd and last day at BlackHat EU 2012 !

 

© 2012 – 2021, Peter Van Eeckhoutte (corelanc0d3r). All rights reserved.