Whitepaper Blackberry Z10 Research Primer - "Dissecting Blackberry 10 - An initial analysis"

In 2013, Blackberry has presented a brand new operating system which significantly differs from others presented on the smartphone market. A very high security level is announced, and the expectations are corresponding. Some analytics consider this as the last chance for Blackberry "to get back in the big game" and stand in the row with such giants as iOS and Android.
The goal of this whitepaper is to show an approach for testing the new Blackberry 10 operating system and to identify vulnerabilities on a new Blackberry 10 device.

A set of methods and tools has been developed. In the paper we will:

•   Discuss specifics of the operating system
•   Check for vulnerabilities "by design"
•   Talk about fuzzers
•   Test default utilities
•   Dump the "boot sector"
•   Mention other interesting entry points / notices
•   Propose further steps for future research

The whitepaper can be downloaded from here:
https://www.sec-consult.com/en/Vulnerability-Lab/Whitepapers.htm

Secure WordPress: Part 2 - Configuration Settings

In part 1 of this series we focused on the one of the most common security problems related to user accounts that often result in attackers easily taking over your WordPress site. In this part we will be tackling insecure configuration settings in PHP, WordPress itself, etc and present secure alternatives that strongly improve the security level of your site.

PHP Settings

General Recommendations

General best practices dictate disabling "Safe Mode" and "Magic Quotes" as both are deprecated and might cause problems with your site.

Change settings by adapting the according entries in the file php.ini:

safe_mode = Off;
magic_quotes_gpc = Off;
magic_quotes_runtime = Off;
magic_quotes_sybase = Off;

Logging Recommendations

When hackers are targeting your site, every bit of information, such as physical paths, error messages displaying source code, etc can be leveraged in later attacks. Also, it is crucial to have proper logging in place to be able to trace hack attempts and have the possibility to analyze the attacks and understand what they were doing.

Change settings by adapting the according entries in the file php.ini:

expose_php = Off
log_errors = On
display_errors = Off
html_errors = Off
display_startup_errors = Off
error_reporting = 32767 //E_ALL starting from PHP 5.4

Security Recommendations

Now let's talk about more critical configuration settings that might protect your site from being fully taken over by attackers. "Register Globals" has been deprecated as of PHP 5.3.0 and removed as of PHP 5.4.0, but unfortunately there still exist quite a few PHP installations that have this option enabled. This option opens up a lot of attack possibilities and often allows attackers to take over your web application easily, so it should be disabled.

Another security consideration is restricting powerful PHP functionality that, when used in an insecure fashion by e.g plugin developers, can make your site vulnerable. This powerful functionality is also commonly used after a site was initially hacked to install backdoors. Users should leverage the "Disable Functions" option to disable those functions thus limiting what attackers can do on your site.

For example, "fopen", a commonly used function in many PHP applications allows the reading and writing to file resources. If the allow_url_fopen option is activated, PHP allows to use URIs for fopen or includes, which has been the cause of countless web site compromises in the last decade. More information about this attack, which is called "remote file inclusion", can be found on Wikipedia.
Change settings by adapting the according entries in the file php.ini:

register_globals = Off
disabled functions = system,exec,passthru,shell_exec,proc_open
allow_url_fopen = Off
allow_url_include = Off

Note: If you can't change the php.ini directly, some of these settings can be changed in the wp-config.php file with the following syntax:

@ini_set('log_errors','Off');
/* That's all, stop editing! Happy blogging. */

File Permissions

File permissions are often cause for security related discussions. Let's explore the core concepts and main considerations for file permissions in WordPress hosting environments.

In shared hosting environments, you share one server with dozens or hundreds of other customers. These setups are cheap, but often very difficult to secure, because in many cases it could be possible for another user on the same server to access files belonging to your Wordpress site (e.g. your wp-config.php file),  or read your DB passwords and them take over your site this way. If the file permissions are set poorly then it might even be possible for a user on that server to write and change arbitrary files for your site as well. So obviously if an attacker takes over any one site in the shared environment, they could spread to all the other sites fairly quickly.

Ideally, in a Linux- or Unix-based shared environment each user should be assigned an unique user account that has exclusive read and write permissions to its own files. The group permissions should be set to "read" for all files so the web server so the WordPress site can work properly.  However, users should not have any read permission or write permission to another user's files. That way it is prevented that anybody else on this shared environment can read or write the files of other users. However, the problem remains that if any other user on that server would upload a file browsing PHP script it would run with the privileges of the web server which would allow it to still read all the files. Check if your hosting provider is using open_basedir restrictions or ask them directly how they ensure that users are limited to their virtual hosts.

In self-hosted environments the same best practices apply, although the risk is heavily reduced due to the fact that the server is not shared with hundreds of other users.

WordPress Settings

The last section of this part we will be looking at some WordPress specific settings that, if configured insecurely, could turn your WordPress site into an open door for attackers.

File Editing: The WordPress "file edit" functionality can be useful for making quick changes to plugins or themes, but generally it is not needed in production systems. This functionality is often exploited by attackers who have gained access to the admin interface to quickly compromise the website. On production systems, this functionality should be disabled if it is not explicitly needed.

Allowed MIME Types: WordPress allows the upload of media. By default this functionality is limited to file types that are considered safe such as image files. It is crucial to never allow dangerous file types such as .php scripts, because this would allow any user with the author or editor role to take full control over the site.

Debugging: Similar to the debugging and error messages that PHP provides, WordPress has a debugging switch that can be enabled to show errors during e.g plugin development or to facilitate troubleshooting. In a production environment this should never be active to prevent attackers from obtaining sensitive information that could be exploited in further attacks against the site.

Summary

1. Ensure that PHP is configured securely in only necessary features are enabled. 
2. Ensure that file permissions don't give other users the possibility to write/read your files.
3. Ensure that dangerous WordPress features are disabled on a production system.

Don't know if your WordPress site is configured securely? Don't worry, just go ahead and download MVIS Security Center for free and it will help you to identify security issues with your setup and give you exact information on how to improve the security of your site.

Secure WordPress: Part 1 - User Accounts

Update: The countermeasures described in this post also prevent the currently ongoing brute force attacks against the admin user of WordPress sites!

Update 2: MVIS Security Center has been updated and now detects all week user accounts that are currently exploited in the global brute force attacks. Get version 1.3.2 and check if you are vulnerable. 

In this multipart series we will cover typical mistakes that are commonly exploited by hackers to take over or deface WordPress sites and we will cover how to prevent them.

Those of you who have ever taken a look at the WordPress support forum will know how often WordPress users from all over the world ask for help, because they got hacked. A Google search for "WordPress Help I've Been Hacked" yields 1,770,000 results.

The main reason why attackers choose to hack WordPress sites is because it is one of the most widely used content management systems (CMS). It has even been estimated that roughly 17% of the Internet runs on WordPress. This obviously makes it an attractive target.

The first part of our series focuses on one of the most trivial issues attackers abuse to fully take control of a WordPress site - security issues regarding WordPress user accounts and passwords.

Usernames and Passwords

During the initial WordPress setup the proposed username is "admin" and as you can imagine this username is not changed in a majority of all active setups. Subsequently, this allows attackers to launch automated brute-force attacks against passwords for this known username. In the case that the attacker guesses the correct password they immediately obtain full control over the website.

Even if the username has been changed to something different than admin, there are still ways to easily find out which usernames exist for a specific WordPress site. Whenever a post is published, the username or alias is shown as the author. Clicking on the author will open the link like for example http://urlofwordpressite.com/?author=1. This url will show all posts by the author with the given ID, 1 in this example. Attackers can abuse this functionality to figure out which usernames and their according IDs are available on the site. Naturally, lower IDs such as 1 and 2 likely have higher privileges (e.g. admin or editor roles) and make a good target for a password brute-force attack. There are even tools available that can automate the process of enumerating usernames and IDs from a given WordPress site such as WPScan (see image below).

WPScan in action

So even if the username is not admin, it is quite possible that attackers still figure out all the usernames and if the passwords are weak they can easily succeed in taking over the website.

User Roles

Let's talk about user roles in WordPress and identify which one of them should be considered as dangerous and used with caution.

Role	Permissions	Dangerous
Super Administrator	Full rights (Multisite)	Yes
Administrator	Full rights (Single Site)	Yes
Editor	Manage all posts, upload files	Yes
Author	Mange and create own posts, upload files	Yes
Contributor	Edit own posts, manage profile	No
Subscriber	Read posts, manage profile	No
Visitor	Read posts	No

Many of the existing roles are considered privileged and if those accounts are taken over by attackers, they could deface your website and even fully take over the web server (by uploading malicious scripts). Limiting the accounts that exist for your WordPress site to ensure that only few users have privileged user accounts and that they use secure passwords goes a long way in protecting your website. If you want to create a secure password you can for example use this password generator.

Another feature that might put your WordPress site at risk, is "enabled user registration" and even more so if the default role that new users obtain after registration is changed like below.

A very insecure example of enabled user registration

This in disabled by default but if it actually is configured insecurely like above it would potentially allow anybody to freely register to your site as e.g Administrator user and get full access to your site. This would be disastrous for your site.

Recommendations

Additional to the security improvements already mentioned, there are further countermeasures that can be crucial in protecting your sites from attacks:

Activating HTTPS: When you connect to your admin backend over a public WLAN at e.g Starbucks anybody in the same WLAN could read the username and password you are using to login.
More information on how to enable HTTPs for your WordPress admin interface can be found here.

Securing your Computer: Many times the only reason WordPress sites are hacked is because the computer that is used to upload files to the site via FTP has been hacked as well. The FTP application such as Filezilla often is used to store the user credentials and this is abused by automated malware to deface websites. Make sure that your computer is protected with a personal firewall and anti virus software and does not get infected with malware.

Summary 

1. Ensure that you don't use the admin username.
2. Ensure that all of the passwords, especially for dangerous user roles, are very strong.
3. Ensure that user registration is disabled if not absolutely necessary.
4. Ensure that HTTPS is enabled for the admin interface.
5. Ensure that your client computer is protected and free from malware.

If you need support with solving these issues, install MVIS Security Center. It identifies problems like these and will provide you with the information needed to solve them.

Security Testing iOS Apps Part 2

In part 1 of this series we focused on the basic skills required for iOS security testing. Now that you are an expert on all things iOS, it is time to set up the test environment. For this, some essential hard- and software is required.

1. Test device

For some apps (and if you have the full, compilable source code), it can be sufficient or even more reasonable to test on the iOS simulator only. However, there are situations where you want to run the app on the actual device, so you will most likely want to buy a test device. An iPad is obviously the better choice because it is not only cheaper, but can run iPhone apps as well.

If you are buying an iDevice for testing purposes, make sure to buy a device running an iOS version for which at least a tethered jailbreak is available. Just a few weeks ago, if you had bought a new iPad mini, you would have been stuck with a non-jailbreakable device, because a jailbreak for iOS 6 on A5 devices wasn't available yet. Apple also won't allow flashing an old iOS version, even if you still have the old firmware image lying around.

2. XCode and IOS API

Xcode is the toolset for building OS X and iOS applications. It has a nice IDE and integrates Apple's LLVM compiler. The iOS SDK allow you to compile applications for iDevices, as well as test them in the iPhone simulator. More information is available on the XCode website.

3. IDA Pro

I don't use many commercial tools for hacking (there's three paid tools I use in total) but there is simply no way around IDA Pro - it has been my trusted companion since version 4.3 or so. It is the most popular disassember and has great support for Objective-C binaries. AFAIK there is no alternative for disassembling iOS apps but if you know one, please let me know in the comments. Check out the Hex-Rays website for more information.

Black box or white box?

There are different test scenarios depending on what the client can and wants to provide you with.

In my opinion, pure blackbox testing of iOS apps usually does not make a lot of sense. Yes, you can look at the GUI and network traffic and interaction with the filesystem and iOS APIs, but it is so much more efficient to simply read the source code. Therefore we almost always try to go for a whitebox test / source code review.  If the source code cannot be obtained, it is standard procedure to disassemble the app, which is almost as good as having the code.

In the ideal case, you will always want the application's full source code including the XCode project files. This allows you to compile the app and debug it in the simulator, setting breakpoints etc. This is the easiest way to analyze the app's behavior and do a comprehensive security analysis.

Loading and debugging a project in XCode is pretty self-explaining - simply follow the XCode user guide.

However there are cases where only an IPA file or iTunes link is provided. This is the more difficult scenario, since you will not be able to use the simulator and you have to rely on reading the disassembly and observing the app's behavior on the device for your analysis.

Disassembling an iOS app

Analyzing an app obtained from the Appstore is not as straightforward as you would expect, because iPhone binaries are tied to a specific device using binary encryption - the binary can be decrypted only with the hardware key of the device for which the app was purchased. The decryption is done at run-time by the iPhone loader. Opening the encrypted binary in IDA Pro will give you only garbage.

Fortunately this is not a big issue if you have a jailbroken iDevice. All you need to do is dump the decrypted binary from memory using Stefan Esser's dumpdecrypted tool:

1. Jailbreak the device and install SSH if you haven't already

2. Download and compile dumpdecrypted. The IOS SDK is needed to compile it. Edit the makefile to point to the gcc in your SDK and run make, then copy the resulting dylib over to the device.

3. SSH into your device and search for the path to your app's main binary (somewhere in /var/mobile/Applications/). The run the binary with the DYLD_INSERT_LIBRARIES environment variable set to the dumpdecrypted library:

# DYLD_INSERT_LIBRARIES=dumpdecrypted.dylib /var/mobile/Applications/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX/YOUR-APP.app/BINARY mach-o decryption dumper

This will dump the decrypted binary into the file YOUR-APP.decrypted, which should load in IDA Pro just fine.

Reading Objective-C disassembly

Understanding Objective-C disassembly can be confusing at first. As you already know Objective-C uses message passing instead of normal function calls. The drawback of this is that you won't be able to generate useful call graphs, and it is more difficult to navigate through the binary.

To make things easier, make sure to use at least IDA Pro 6.2, which is able to parse Objective-C 2.0 metadata structures and generate a disassembly that is quite readable. A typical method call is realised via _obj_msgSend and looks like the following:

When calling _objc_msgSend, r0 points to the object name, r1 points to the method name, and the return value is stored in r0. The method call above translates too:

[[NSAutoreleasePool alloc] init]

As you can see, current versions of IDA can annotate everything reasonably well so we know what's going on. If you are planning on doing security analysis of iOS apps, you should definitely have a look at some iOS binaries in IDA to learn how to navigate through and understand Objective-C disassembly.

Here are some more pointers to interesting articles:

• Reverse Engineering iPhone AppStore Binaries (TippingPoint)

• Decrypting iPhone Apps (SensePost)

• Reversing iOS Applications (LightBulbOne)

With the test setup finished, we will focus on the actual security analysis in the next episode.

MVIS Security Center Version 1.3

I am happy to tell you that we have officially launched MVIS Security Center as of now. 

The beta phase is officially over and we are very happy with the feedback and reception so far! Thanks for all your support! We have implemented a coupon system, so upon subscribing multiple sites you will receive coupons that can be entered to activate any other MSC plugin running on any other site. 

This allows you to share subscription costs and get a juicy discount!

To even further sweeten the pot, the first 10 subscribers will receive double the amount of sites that they subscribed for.

For example: 

• Purchase 1 site for 1 year, get an additional coupon for 1 site for 1 year. 
• Purchase 10 sites for 2 years, get an additional coupon for 10 sites for 2 years.

If you haven't given MSC a try yet, download it here and enjoy a secure WordPress experience as over thousand others already do!

Have any suggestions, feedback or wishes for MSC? Drop a line in the comments or send us an e-mail to mvis-wp@sec-consult.com.

Security Testing iOS Apps Part 1

While for the last decade or so our day-to-day security work has been mostly about web applications, we are now seeing a gradual shift in demand to mobile apps. This is a nice thing because honestly, after testing over 9,000 web applications it does get a little monotonous.

By now we have acquired a good level of experience with mobile app testing and we thought it would be a good idea to share some of it with others who might want to get into the field. This the first part of a multi-part blog series on security testing of mobile apps. Because my personal focus is on iOS, I will do the iOS part, and will leave Android to one of my colleagues (yes, other mobile OSes exist but we have never been asked to test apps on any of them).

In our first article we will focus on specialized know-how and skills required to get started. Later articles will discuss common test setups and security issues found in iOS apps.

How to prepare yourself

Mobile apps are almost always a client or front-end to something. So usually, you will be testing a complete client/server architecture with the mobile app being the client, and connecting to some kind of JSON / XML / web service. iOS apps are real compiled binaries - as a consequence, for a security test like this you need good know-how about the pitfalls of typical (web-)server applications, as well as about low-level issues that may occur in the app (including memory management problems, heap overflows, use-after-free vulns, etc.). Since all IOS devices run on ARM processors, being able to understand ARM assembler is also required. Anyway, if you come from an application security background you likely have dealt with most of these things before.

However, there are also some iOS specific topics you should learn about:

1. Objective-C

If you haven't developed for an Apple OS chances are you've never heard of Objective-C before. It is the main programming language used for writing Software on OS X and IOS, and this is basically the only place where it is used.

Objective-C is a superset of C but uses some specific concepts that have to be learned. Instead of normal method calls, there is message passing with a confusing syntax. Also, there are other concepts like delegation, which you should read up on, because otherwise understanding Objective-C code or disassemblies of IOS binaries will be difficult.

Also, if you are going to test iOS apps, you should at least have written and deployed a Hello World app for iOS yourself.  Download XCode and the iOS SDK (you will need this anyway) and follow Apple's tutorial.

2. iOS security

This is important from several aspects. First, Apple does everything to maintain complete control of its devices and this includes locking down iOS to prevent you, the tester, from doing your work. In some cases, the first thing you have to worry about is to BREAK Apple's security mechanisms so you can get an inside look at the app you are testing and its interaction with the OS. Doing low-level stuff such as debugging a heap overflow exploit simply isn't possible without jailbreaking the device first. Fortunately, you usually won't have to develop your own jailbreak though because the jailbreak community provides this service to you for free.

On the other hand, iOS offers many security features and APIs to developers that you should understand. Most importantly, because secure data storage is such an important issue with mobile apps, you should read up on file data protection and the iOS keychain.

Encryption and code signing plays an important role in iOS. Every iOS device is outfitted with an AES 256 crypto engine that is extensively used by the OS. The keys are fused into the application processor and cannot be read, so certain cryptographic operations can only be performed directly on the device. This is relevant if you want to decrypt binaries copied from a device (more on that later). Also, every single file on an iOS device is encrypted per default according to the "protection class" it belongs to, using different combinations of the device keys and class keys derived from them. It is important to understand the different ways encryption is used in iOS if you want to assess the way an app is handling sensitive data.

Apple has released a quite comprehensive paper covering most of these topics, and you might also consider reading the iOS hacker's handbook (see below). Make sure you are comfortable with the basics before you consider testing iOS apps.

3. iOS OS architecture

iOS is derived from OS X and is running the same Darwin core OS. It's basically Unix with some Apple-proprietary layers on top of it. Standard tools, such as a shell and SSH server, are missing in the default firmware, but are easily added to a jailbroken device. For a start, get a jailbroken device, install SSHD via Cydia and explore the OS for a while to get a feel for the file system, the way applications and data are stored, and other OS internals.

Here are some more pointers to get you started:

• "Programming with Objective-C" at the iOS developer library

• Apple's iOS Security paper from May 2012

• iOS hacker's handbook. This comprehensive book by hacking-superstar Charlie Miller et. al. explains the basics as well as things like low-level debugging, fuzzing, and exploitation on the OS level. I can highly recommend this.

In the next article, I will discuss the tools and basic setup required for testing an app.

MVIS Security Center Version 1.2

Hello everyone,

We have just released MVIS Security Center (MSC) version 1.2.

Next to some improvements, as promised we have added yet another exciting feature for MVIS PROtection subscribers. The plugin is now equipped to communicate available updates for plugins, themes and the WordPress core and will keep you informed about it in the weekly status e-mails!

So if you have multiple sites subscribed, you will get the information of how many updates are available for a specific site, without needing to check in each backend. 

We have extended the free subscription phase until the 15.02.2013, so if you haven't given MSC a try yet, download it here and enjoy a secure WordPress experience!

Have any suggestions, feedback or wishes for MSC? Drop a line in the comments or send us an e-mail to mvis-wp@sec-consult.com.