Daily Archives: June 21, 2015

SAP HANA Database Uses Static Encryption Key By Default

Earlier this month leading ERP (Enterprise Resource Planning) vendor SAP released an updated version of their HANA database (a database that is stored in RAM (computer memory) for very fast performance (although the database is periodically written to a hard disk for the purpose of recovery checkpoints)). However it has been revealed that in the vast majority of installations of this product the data encryption key is left at the default value. Thus if an attacker obtains access to the database, they can potentially obtain access to all of the data since the encryption key is static (unchanged) for a very large number of database installations. In addition, the databases have been known to have SQL injection flaws (however one such flaw has been recently resolved).

Please note that I don’t consider the fact that a default encryption key is used by SAP HANA a failing on SAP’s part. It is up to the individuals who manage the HANA database to understand that important default settings should be changed. However I do acknowledge that such important default settings should be set (and that such steps cannot be bypassed) during the installation/setup of the HANA database and that the installer/setup routine should enforce very strong criteria in relation to the complexity of the encryption key since all of the information within the database will be protected by this key.

How Can I Protect Myself From These Issues?
It is recommend to have the most recent version of SAP HANA installed and ensure that it has all of the necessary security updates installed (recent updates are detailed in this blog post). In addition, please follow the advice within the SAP security handbook as well as the administration book specifically the following pages:

SAP HANA Security Handbook:

Page 115 to 120: Encryption keys and admin encryption tasks
Page 121 to 126: Protecting user credential stores and SAP HANA Studio Workspaces

SAP HANA Administration Guide:

Pages 479 to 485: Managing data volume encryption (ignore section 3.3.4 Disable Data Volume Encryption)
Pages 486 – 492: Managing/Changing Encryption Keys

Finally I would also recommend following the advice in the Cross-site Scripting (XSS) flaw blog post (part 2 of that blog post should be published at a later date). The main blog index may also contain posts that you may find useful for your environment. If you are in any doubt or would like further advice, please contact SAP Support for more information.

Please note that the links to the blog posts written by ERPScan were not functioning when the post was added to this blog but were operational when I originally referred to them. The availability of links provided within my blog is a factor outside of my control. I will update this post when these links become functional again. Apologies for the inconvenience.

Update: 5th July 2015: I’ve verified that the blog posts written by ERPScan linked to above are now functional again.

Thank you.

Drupal Releases Security Updates

The very popular website Content Management System Drupal has released security updates to resolve 4 CVEs within versions 6 and 7 of their product. Their pervasiveness of Drupal and thus the huge scale of the risks posed by these issues is detailed in this blog post.

For a definition of the term CVE, please see the first short aside within this blog post for an explanation.

The first security flaw relating to the impersonation of legitimate users (of the Content Management System) is the only flaw to be rated critical by Drupal and should be patched/updated immediately. This flaw could allow a malicious user to log in as an authenticated user (i.e. users who are legitimately accessing the Content Management System) and could be especially severe if that authorized user has high privileges.

A further 2 less critical flaws could cause authenticated users to be re-directed to 3rd party websites of the attacker’s choice without the user’s consent/permission and could place your users in danger of being exploited by other unpatched vulnerabilities on their devices. The final flaw is an information disclosure issue that could allow malicious users to view the content that was previously cached (when they legitimately viewed it) by authenticated users.

Drupal users should upgrade to versions 6.36 or 7.38 to resolve to these issues. Further information and steps to install the updates are available in the Drupal Security Advisory.

Thank you.

Apple App Store Apps Vulnerable to Elevation of Privilege Vulnerabilities

A group of 6 researchers from Indiana University have made available a report that details 4 sets of flaws within apps available in the Apple App Store. The researchers named these collections of flaws; unauthorized cross-app resource access or XARA.

What Are These Flaws and What Data Can They Steal From Me?
The first flaw which lies within Apple’s KeyChain is one mechanism that is used to share information between separate apps (such separation is called “sandboxing” where each app resides in a separate defined area/sandbox). Apps can store information in a private cookie on the computer but this flaw allows a malicious app (which must have been approved by Apple to be available in the App Store) to delete the existing relationship the genuine app has with KeyChain (and thus to it’s private login cookie) and then re-create the relationship but this time with additional permissions given to the malicious app (the app’s ACL) that allows the malicious app to access data that it otherwise couldn’t. As an alternative to deleting the existing relationship, it is also possible to create a relationship with KeyChain for the legitimate app (and including the malicious app) before the legitimate app creates such a relationship in the first instance. This is the elevation of privilege flaw since the malicious app now has more access than it should. The researchers used this flaw to obtain Apple iCloud and Facebook passwords.

What is an ACL?
An Access Control List (ACL) is a list that is present with an object and this list controls who has access to that object and what kind of access they can have (e.g. read only, write, delete etc.). An object is something (e.g. a computer, a folder, a file etc.) that you wish to protect by controlling who has access to it.

The second flaw, Container Cracking is where one app’s private data store e.g. the contents of your Evernote folder can be accessed by another malicious app simply by that malicious app masquerading as the genuine app by assuming the genuine app’s BID (Bundle ID). If the malicious app can be launched first with the genuine app’s BID, then the operating system will add that malicious app to the ACL that will allow that app to access the private data store, in this case your Evernote folder.

The third flaw, IPC Interception would allow a malicious app to impersonate a legitimate app, the security researchers gave the example of a malicious app impersonating the 1Password Browser extension and could thus intercept data travelling on an internet port (assigned to the browser extension) to capture the login data for a specific website where a user is attempting to login. 1Password has offered advice in this blog post on preventing this attack and discusses approaches that it is currently considering in order to mitigate this issue in the long-term.

For the fourth and final flaw; Scheme Hijacking, the researchers found that a URL scheme used to share information between apps could be hijacked by the first app registering that specific scheme (in Apple iOS, it is the most recent app that registers for that URL scheme is then allowed to make use of it). For OS X the researchers were able to hijack the access token of Wunderlist (a To Do list app). For iOS the researchers were able to hijack the URL scheme for communicating between Facebook and Pinterest apps allowing the Pinterest app to access data within the Facebook app.

To see the extent of which apps are vulnerable to such flaws (within the 4 categories mentioned above), please see Table 1 located on page 9 of the researcher’s report. In addition, for a detailed list of the types of data that can be exposed during these attacks, please refer to Table 2 on Page 10 of their report.

How To Defend Against These Attacks
Since the researchers reported these flaws to Apple in October last year it is reasonable to assume that Apple is working to resolve them and would have more strict checks in place to prevent further apps becoming certified within their Store containing these flaws.
These flaws are not trivial for Apple to resolve since the apps are working as intended and these flaws stem from design decisions that have been abused in novel ways. Thus to resolve them will either mean re-designing these apps intercommunication mechanism to prevent these flaws having malicious effect or adding stricter checks to prevent apps being placed in the Store that inadvertently use these mechanisms in ways that were not intended by Apple. Thus to defend against the exploitation of these flaws I would simply recommend only downloading apps that you know and trust from the Apple App Store.

Further resources discussing these flaws are this post and this post.

Thank you.