PLEASE NOTE: As promised, I've published a full white paper that is now available for download:
White paper "Reflected File Download: A New Web Attack Vector" by Oren Hafif.
On October 2014 as part of my talk at the Black Hat Europe 2014 event, I presented a new web attack vector that enables attackers to gain complete control over a victim’s machine by virtually downloading a file from trusted domains. I decided to call this technique Reflected File Download (RFD), as malware can be "downloaded" from highly trusted domains such as Google.com and Bing.com without ever being uploaded.
This post concludes our three-part series about mobile security. Today's post will outline some options for detecting jailbroken devices, should you choose to do so. Yesterday, we asked whether blocking an app's execution on jailbroken devices was worth it. Earlier this week, we described some vulnerabilities in iOS web browsers.
Many iOS applications contain some sort of jailbreak detection mechanism. Some of the detection mechanisms can be bypassed by attackers (sometimes easily), whereas others are quite difficult to bypass. Below is a list of some of the more popular methods of detecting jailbroken iOS devices.
This post is part two of a three-part series about mobile security. Today's post will discuss the execution of apps on jailbroken devices. Yesterday, we described some vulnerabilities in iOS web browsers. Tomorrow, we'll explore detecting jailbroken devices.
Three different messages but they say the same thing: the app will not execute on a jailbroken device. The question is though, is it a good idea for developers to block execution on jailbroken or rooted devices?
Today we begin a three-post series about mobile security. We start with a discussion of vulnerabilities in iOS web browsers. Later this week we'll cover apps executing on jailbroken devices and the detection of jailbroken devices. While the release and adoption of iOS 8 may plug some of the holes discussed in this post, many users will continue to use iOS 7 for some time and may remain vulnerable.
In Q1 2014, the market share of web traffic from mobile browsers exceeded 30% , and it is constantly growing. According to data provided by StatCounter, web traffic from iOS devices surpassed that of Mac OS X and Windows 8 . Many vendors are trying to get a piece of the pie by introducing their own browsers on Apple’s platform.
UIWebView is the main component of all browsers that allow running web content. The WebKit engine is the same as in Mobile Safari. The main difference is in the UI wrapped around WebKit.
Below I explain a number of vulnerabilities introduced by developers as they add functionality to their browsers.
Trustwave, like most other information security firms, has been busy investigating the ShellShock vulnerability and subsequent scanning and exploit attempts. The SpiderLabs team at Truswave wanted to give the community some feedback on what we are seeing happening "in the wild" and a status on the detections and coverages we have in the relevant Trustwave services and product portfolio.
When trying to identify crimeware/malware, it's a good idea to design a multi-part system that deploys a variety of detection techniques to increase your chances of detection. You can start with one technique and then layer on additional techniques as time and resources will allow.
In this short blog post, I’m going to share just one of those techniques (using edit-distance) that you can plug into your multi-part system to perform rudimentary detection for popular crimeware admin panel strains like Pony, Citadel, and Zeus.
On May 12, 2014, SAP published updates to Adaptive Server Enterprise versions 15.0. 15.5 and 15.7 on all platforms. These updates addressed a security flaw in a built-in procedure implementation. The flaw allows any authenticated database user to overwrite the master encryption key or execute arbitrary code in the database server process context. Below I will discuss in detail what happens inside the server when the vulnerable procedure is invoked.
In this post I will discuss how a serious but mostly ignored vulnerability can lead to a full compromise of a WordPress site. The key in this attack is how WordPress handles authentication allowing a brute force attack if the secret salt and key values stored in wp-config.php are exposed. IF an innocuous LFI (local file inclusion) or accidental leak of this data by a backup or copy of wp-config.php is successful, then an attacker could generate their own valid auth tokens and gain full access to the site’s admin pages without being detected.
This is a followup to a previous blog post (Jamming with WordPress Sessions) where I discussed an attack against WordPress authentication tokens. At that time I only wrote about a post-compromise scenario where an attacker could generate undetectable authentication tokens that effectively never expire. I restrained myself then from divulging how this flaw could chain with other attacks to allow attackers to compromise WordPress sites. With the release of WordPress 4.0, the vulnerability that this attack exploits (CVE-2012-5868) has finally been patched (yes, after 2 years).
Our web honeypots picked up some interesting attack traffic. The initial web application attack vector (PHP-CGI vulnerability) is not new, the malware payload is. We wanted to get this information out to the community quickly due to the following combined threat elements -