Author Archives: jeremy.allen
Excuse me, your clouds are leaking
I recently started playing around with Gliffy, a nice online diagramming tool that has become quite popular. Gliffy makes sharing your diagrams with the world easy. Unfortunately, many Gliffy users do not realize that they are sharing their diagrams with the entire world. Some quick Google searches revealed a number of entertaining diagrams.
This data ranges from boring to concerning. I held back a few that I felt were not responsible to disclose. At any rate, this highlights the dangers of using “cloud services” and not educating employees about the inherent risks this involves. Also, some of this is just plain laziness from those who probably know better.
After assuring Google I was indeed a human about a dozen times, here are the highlights:
- A GitHub Migration Map — Author Unknown
- “esecurity” flow chart
- An org chart with salary information
- The “melvyn” flow chart
- A single sign on app flow
- I don’t even know
- qwest.com current architecture solution
- Lubricant Supply Chain
- “Confidential” Application Design Docs
- Another Org Chart
- A Networking Diagram with Passwords
- UI Mockups
- MyBook General Photo Album Confidential API
- A Really Detailed Internal Business Process
- Marketing Plan With $ Figures
- Some Sort of Business Plan
- Music Studio SEO Strategy
- Facebook Ad Campaign Results
- Fax Numbers in a Payroll Process
- Payroll Email Process – Info Disclose
- Another Org Chart
- Another Internal Network Diagram
- ATM Vendor Proprietary Information
- DoD Stuff
- More DoD Stuff
- Even More DoD Stuff (I hope this stuff isn’t classified)
- Another Internal/External Network Diagram
- Hot Sexy Text Chat Mockup
- Zombie Attack Flow Chart
Also, SOPA and PIPA are bad. Please let your representatives know. See: reddit.com for a nice write up.
@bitexploder, @sorcerer13 and @rossja
OWASP ATL: Mobile Application Assessment Presentation
I recently gave a presentation at OWASP ATL on the OWASP Mobile Top 10 and how to assess mobile applications. This was a light weight discussion of the OWASP Mobile Top 10 and some topical and technical concerns related to securing mobile applications.
Download the presentation here: [download id="276"]
These videos show various testing techniques on real applications. The applications targeted didn’t have any serious problems. In the case of the game, “WordFeud”, a Scrabble clone, the game maintained game state on the server and tampering with client side values did not yield any interesting results. The SoundCloud demonstration shows how it uses the iOS data protection API to avoid storing OAuth tokens in the applications file sandbox and instead uses KeyChain.
Video Demo Series Here:
iPad SSL MiTM
- http://www.youtube.com/watch?v=0453HDZYdGU
- http://www.youtube.com/watch?v=kZ1pKShrKyk
- http://www.youtube.com/watch?v=NvyM1wzwT2o
- http://www.youtube.com/watch?v=HRRqL7IAkJw
- http://www.youtube.com/watch?v=24FT-plmjAs
iOS Application MiTM
- http://www.youtube.com/watch?v=Hgk310uUdjI
- http://www.youtube.com/watch?v=x1T6kjtcpLw
- http://www.youtube.com/watch?v=0VwJ1bss5wA
- http://www.youtube.com/watch?v=50NAa324WC0
- http://www.youtube.com/watch?v=btl147-ioKQ
- http://www.youtube.com/watch?v=5YFC2L0vapM
- http://www.youtube.com/watch?v=UL6mjywzBwU
Sound Cloud and Data Protection
Protect your Apple Developer Certificates
A discussion of Apple Developer certificates came up. The conversation was focused on how a third party developer wanted access to an organizations certificate so they could build the application for the organization and (potentially) publish it to the Apple App Store. The developer’s request did not surprise me, but it did surprise a couple of people at our lunch table.
As a policy, third parties should never be granted access to your Apple Developer certs. Anyone that has that cert and private key can publish applications as your organization. This has huge implications. Please, don’t let anyone outside of your organization have access to your certs. In fact, don’t let more than a few people in a tightly controlled environment have access to them. If you deal with SOX and any sort of separation of duties you are probably familiar with separating developers from production. You may not be aware that having access to that Apple developer cert (issued to your organization as a whole) lets the possessor publish applications as you. If you have a third party developer, tell them no when they ask for access to your certs and handle it in house.
I also recommend any org building iOS apps create build environment and only publish binaries they build themselves to the app store. The best secure SDLC and developers in the world can be undermined by this one operational security mistake. Guard your developer certs very closely. A third party developer can slip in malicious code. A third party developer may not have the same security practices and constraints as you. The list goes on. The idea is simple: protect your Apple dev certs like a nuclear launch code.
Here are bad code signing things that have happened:
http://threatpost.com/en_us/blogs/possible-new-rootkit-has-drivers-signed-realtek-071510
http://www.symantec.com/connect/blogs/stuxnet-code-signing-incident-emphasizes-role-acs
http://www.f-secure.com/weblog/archives/00002017.html
Note: Reader Karl observes that you can still have separation of duties from developers by not giving them the iTunes connect credentials required to upload to the store. Karl is likely correct on this point. It is certainly not quite as easy as I made it out to be getting things into the App Store with just a code signing cert.
Be wary though, production code signing certificates should likely be kept out of most development environments, as there are still risks with Ad-Hoc application publication and many other abilities Apple dev certs enable that should not be granted to a development team carte blanche.
Intrepidus hosting a Convergence notary
Suffice to say, the Certificate Authority trust model seems to be fundamentally broken, and with increasing attention paid to it from numerous angles, it’s likely to need a massive overhaul before getting any better. However, there are efforts underway to change the way we think about trust in this capacity. Moxie Marlinspike, known for his contributions to (breaking) SSL and the CA system (among other things), recently developed an alternative to the traditional CA trust model. The project, called Convergence, pairs a Firefox add-on with a set of server-side components to help validate the authenticity and trustworthiness of a particular SSL-enabled site.
Although Moxie’s blog post (that led up to Convergence) and the video of his talk at BlackHat USA 2011 explain the rationale a bit more, the concept is simple: you visit a (SSL-enabled) site, let’s say SomeTrustedSite.com, and the Convergence add-on sees a certificate with a fingerprint FOO. The add-on asks a set of Convergence “Notary servers” what they see. If they see FOO, you can reason that SomeTrustedSite.com‘s cert is legit. If one or more of the notaries sees something that isn’t cert fingerprint FOO, something’s probably rotten (such as man-in-the-middling of your connection, or a notary’s connection, or some other network nastiness). Most importantly, you decide which notaries you want to trust, rather than relying on a browser-vendor defined list of Certificate Authorities. Convergence also attempts to anonymize inquiries to notaries so as to minimize the likelihood of a notary getting a bit too privy to your browsing habits.
Per the Convergence site, the installation process for the add-on is fairly straightforward: run Firefox, visit Convergence.io, click “Download”. After that, add any notaries you wish to trust — two Thoughtcrime notaries are enabled by default, and there’s an ever-growing list of additional notaries on the project’s Github wiki. As this project caught our eye, Intrepidus Group decided to spin up a notary server of our own, which can be added by loading our notary file (if you have Convergence installed, you can simply browse to “.notary” files/links to add the associated notary info).
And Intrepidus isn’t the only company to get on the Convergence notary server train. Late last month, Qualys announced their support of the project, as well as spinning up two notaries. We certainly hope to see more of this type of backing in the near future, and encourage others to run their own notaries as well.
ARM, Pipeline and GDB, Oh My!
This post off will start with an important question. Look at Listing 1 below; after executing the instruction located at main+12, what values will be stored in r0 and r1? Take a moment to consider this.
Listing 1: Disassembly of main()
My first (albeit incorrect) answer was that r0 would have 0x000083bc (main+8) stored in it and that r1 would have 0x000083c8 (main+12+8) stored in it (the address of the instruction, plus the value from the add instruction). I thought this because I made a few assumptions about the state of the processor during the execution of the instructions. First, I assumed that while executing the instruction located at main+8, “mov r0, pc“, the pc register would have the address main+8 stored in it and therefore that address would be moved into r0. I also made the assumption that while executing the instruction at main+12, “add r1, pc, #8“, the pc register would have the address of main+12 stored in it and this address plus 8 would be moved into r1. According to Listing 2, I felt that GDB supported my assumptions by showing the pc register with the currently executing instruction stored in it.
Listing 2: GDB reported pc values before execution of instructions.
By examining r0 and r1 while executing the instruction located at main+16 (Listing 3) it became obvious my two predictions would not come to pass. The r0 register had 0x000083c4 stored in it and the r1 register had 0x000083d0 stored in it. Perplexed, I needed to try to understand the mechanism at work here.
Listing 3: Actual values of r0 and r1
After a few minutes of thinking, I started to remember a topic covered in my NYU:Poly computer architecture class, pipelining. I then noticed that both of the values were exactly 0×8 higher then I expected. Doing a quick Google search, I came across the fact that the ARM processor executing my code has a 3 stage pipeline with a 4 byte fixed instruction size.
To understand this problem, we now have to get into some details of ARM processor architecture. Pipelining, as it relates to a processor, is a term used to describe an optimization to optimize the execution of instructions. When a processor executes one instruction there are normally a few distinct steps required before finally executing it. For example, ARMs pipeline stages include fetch, decode, and execute* (see note at end of post). The processor must first load the instruction from memory (fetch), decipher what the instruction must accomplish (decode), and perform the operations necessary to complete the instruction (execute). Each step usually relates to a set of components inside the processor and requires a certain amount of time to accomplish. In addition, the steps must performed in a strictly serial manner per instruction. In a non-pipelined processor only one phase of one instruction is performed at once. This leaves the hardware on the processor responsible for the other stages idle. A pipelined processor is designed to have each phase active for an instruction all of the time.
Let us work through an example (Image 2); during one clock cycle Instruction 1 will be in the execute phase, Instruction 2 will be in decode phase, and Instruction 3 will be in the fetch phase. So why is this important? From a high level point of view, the pc register points to the currently executing instruction. This is the convention that GDB employs. However, from an ARM pipeline point of view, the physical pc register always points to the instruction currently being fetched. The reason for this resides in the deepest levels of the ARM processor architecture. The pc register is used as a direct input into the address register. The address register is used to index memory used to fetch the instruction. See image 1 below from “ARM system on a chip, second edition” for a good diagram of this.
Image 1: ARM Layout (source: ARM system on a chip, second edition)
Our example image below shows a time based view of this processor over the course of 5 clock cycles. Carefully analyzing image 2 during clock cycle 3, we see that the instruction being fetched is 2 instructions after the instruction being executed. Therefore, within the processor, pc must point 2 instructions after the current executing instruction, or 8 bytes ahead (each instruction is 4 bytes long). Instructions that use the value stored in the pc register will be using this actual value of pc. When we see an instruction such as “mov r0, pc” we can think of this as r0 will get pc + 8 where pc represents the current executing instruction as reported by GDB.
Image 2: Pipeline (Source: http://winarm.scienceprog.com/arm-mcu-types/how-does-arm7-pipelining-works.html)
With this in mind, the correct answers to the initial question is:
r0 = 0x000083c4 = (main+8) + 8 = 0x000083bc + 8
r1 = 0x000083d0 = (main+12) + 8 + 8 = 0x000083c0 + 8 + 8 = 0x000083d0.
As you can see, these solutions match what was observed by GDB. Yay!
So what are the key lessons learned? Depending on the number of stages or the specific hardware, the difference between the address of the currently executing instruction and the value stored in the physical program counter register (eip, pc, rip, etc.) may be different. It is important to research this behavior for any processor architecture you are going to be reverse engineering on, writing shell code for, or simply writing assembly to be executed.
-Raj
*Note: There are many different ARM processors and pipeline architectures, however, this is a good description of it to understand the general mechanism at work.
Skype 5.5 and New Hidden Emoticons
WARNING: This post is humorous (and not very technical) in nature. Please don’t take anything that follows seriously.
With that warning out of the way, we all know that Emoticons are a very serious topic. When Skype updates their emoticon set the Internet takes notice. When Skype announced new emoticons, they included a bit about two new “hidden” emoticons. With something this important hidden, there can be no rest until they have been discovered.
Skype encrypts and obfuscates their binary to prevent reverse engineering (and perhaps to compress it, etc.). Using the very powerful hacker tool, “Process Explorer” I was able to dump the process image. Using another advanced hacker tool, “strings” I was able to find the emoticon list. With a bit of spam to my co-workers I found a couple of hidden emoticons (zilmer) and (hollest). Zilmer and Hollest appear to people that were, or are, associated with the organization behind Skype.
Full Skype 5.5 emoticon listing:
(mooning) (u) (skype) (skype) (punch) (call) (talk) (mp) (mp) (mp) (~) (~) (o) (o) (e) (zilmer) (hollest) (wfh) (toivo) (bug) (wtf) (smoking) (smoking) (smoking) (rock) (poolparty) (poolparty) (finger) (fubar) (drunk) (swear) (headbang) (headbang) (*) (ninja) \o/ (d) (beer) (beer) (^) (flex) (flex) (cash) (cash) (pi) (pi) (coffee) (tmi) (bandit) (music) (tumbleweed) (sun) (rain) (rain) (F) (heidy) (heidy) (lalala) (lalala) (lalala) (lalala) (h) (highfive) (highfive) (highfive) (handshake) (n) (y) (y) (emo) (waiting) (waiting) (waiting) (shake) (nod) (smirk) (happy) (whew) (rofl) (bow) (think) (clap) (chuckle) (chuckle) (makeup) (makeup) (hug) (hug) (wait) (envy) (angel) (devil) (facepalm) (facepalm) (wave) (wave) (wave) (nerd) (mm) (mm) (mm) (worry) (party) (wasntme) (angry) (doh) (puke) (yawn) (yn) (yn) (yn) (yn) ]:) (inlove) (inlove) |-( |-) :^) :$ 
:* 
(:| ;( 
:O 
:D 
A few classic emoticons get rendered by WP here. So, please do enjoy that.
If you use Skype a lot check out Tattler.
@bitexploder
The OWASP Mobile Top 10 Risks for iOS Developers
The OWASP Mobile Top 10 Risks is an overview of a generic list of the most common risks found in mobile applications. We see these risks in mobile applications every day. When we see them they often show up as vulnerabilities in the applications we are assessing. No list, such as this, can adequately cover *every* issue an application will face. However, this is a good starting point for a security team or development team looking to understand the most common mobile application security issues for iOS. This article focuses on these risks (and ways to mitigate them) for iOS. For a more generic look at these controls and for further ideas on mitigations check out the OWASP Mobile Top 10 Controls.
1 – Insecure or unnecessary client-side data storage
This risk addresses the obvious concern of sensitive data being stored on mobile devices. All developers must carefully consider if storing a piece of data on a mobile device’s persistent storage is absolutely critical to the application’s correct functioning. If it is not the data should simply not be stored. If the data is required, and it is sensitive, it must be protected. Data protection often means “encryption”. For iOS developers, this is not an onerous problem. Apple provides a very easy to use, and secure, data protection mechanism for iOS 4 and newer devices using 3GS or newer hardware. The mechanism is aptly referenced as “Data Protection”. Apple provides two methods of doing this that very straight forward to use. Pass in the correct option (NSDataWritingFileProtectionComplete) to NSData writeToFile:options:errors: and the file is protected and encrypted when the device is locked. Alternatively, you can use NSFileManager setAttributes:ofItemAtPath:error: and pass in the NSFileProtectionKey attribute with the NSFileProtectionComplete value to protect existing files.
For more information see: Implementing Common Application Behaviors.
Note: The user must have a passcode for this to work. iOS 3.x on 3G and older devices do not have this capability and require much higher effort and less secure/user friendly solutions.
2 – Lack of data protection in transit
After data has been secured on the device the next high concern area is protecting the communications between the mobile application and the server. By far, the most common communication protocol is HTTP. For iOS developers this typically means using the NSURL or NSURLConnection class. By default, NSURL or NSURLConnection will fail with an error in the event of an SSL issue. Development environments do not, typically, have a valid SSL certificate, which creates a problem. NSURL and NSURLConnection behavior is changed to accept invalid certificates to continue development without hassle.
With NSURLConnection an application must implement the delegate methods canAuthenticateAgainstProtectionSpace and didReceiveAuthenticationChallenge to ignore SSL issues. Implementing these methods also gives you the opportunity to warn the user in the event of an invalid SSL certificate. The best behavior is to fail with an error the user can’t accept for production builds. Conditional code that is never compiled into the production binaries (that excludes the risky code) is best. Make sure all production code has development oriented SSL code pruned out of it.
The long and short of it is that you have to actively work at making this insecure on iOS.
3 – Personal Data Leakage
This is less of a technical issue and more of a purposeful choice that must be made as a developer. Developers must take care to guard their user’s private information. Applications must protect their user’s personal data. Use the same data protection mechanism described in the previously discussed risk “Insecure or unnecessary client-side data storage” to protect personal user data. Beyond this it is an application design decision about how the application will handle the user’s personal data. Personal data privacy has become a hot topic and user’s are becoming much more aware that their private data may be at risk in mobile applications.
4 – Failure to protect resources with strong authentication
This issue is something of a server and client issue. Very little authentication is typically performed on a mobile device. The majority of the authentication that mobile devices encounter is oriented around a server authenticating a mobile application. Application’s on mobile devices rarely authenticate other services directly. If this does occur an application is usually being asked to share a resource, such as a photograph or some other piece of data managed by the application, with a server.
The main concern is that iOS applications properly authenticate to servers and that they implement strong authentication that uniquely identifies each mobile application user to the server. One of the main concern for developers is to never embed client side secrets in their application and then use those as an integral part of an authentication method.
5 – Failure to implement least privilege authorization policy
For the local side of things only request permissions you absolutely need. Does your application *really* need access to the user’s GPS? This falls more along the lines of protecting your user’s sensitive privacy oriented data. Be judicious with what resources you attempt to access.
The other part of this issue is server application oriented issue. The key issue at hand is that applications, especially thick-client oriented applications, may contain a great deal of functionality that is not available to lower privilege users. The server is responsible for checking that a user can perform a requested action. Even if the functionality is accessed in the application, the server must not allow lower privileged users to access and execute higher privileged server side functionality. Vertical privilege escalation is a constant risk to server side applications.
Horizontal privilege flaws allow users of mobile applications to easily circumvent authorization controls and access the data of other users at the same privilege level. Care must be taken to only allow a mobile application to access server side data that belongs to the currently authenticated user.
6 – Client-side injection
Client side injection is an interesting problem that can lead to a variety of issues depending on the application and how it operates. Many iOS applications utilize SQLite, which means that at some level those applications may be vulnerable to SQL injection. Often the consequences of SQL injection against a client side application are minimal.
A recent vulnerability in the Skype client for the Mac (I know, it isn’t an iOS app) illustrates the possibilities of “Rich User Environments” and the consequences they can have when an application implicitly trusts input.. The vulnerability was a simple cross site scripting attack that allowed remote code execution. Similar issues can surface in mobile applications if the application uses UIWebView or other rich environments and does not carefully check user (and other!) input.
The mitigation falls down to standard data validation. Any specific advice given here would be to specific to be useful in a general way. Make sure your data confirms to your expected length, range, type and format. Length is obvious, range is for data that has expected numerical ranges (positive integers only), type is for any sort of integer or other data structure being read and format is for the actual data formatting (such as phone numbers).
Data type is actually an interesting one. Any sort of serialized NS objects are inherently insecure and should never be trusted from a remote source. Similar to NIB files (serialized objects), they must only be used locally and only come from trusted sources. If a user can directly input objects into the system and manipulate them a variety of difficult to catch security bugs can result.
Another interesting issue is with format strings. From the comfortable confines of the NS* Objective-C environment it barely feels like you are writing code that gets compiled down to native instructions. Drop down to a library, like SQLite and that illusion is quickly shattered. Format strings using the %@ formatter are vulnerable to a variety of interesting attacks: ()
7 – Client-side DOS
This issue is fairly obvious. Make sure you are being a defensive programmer. This can result from development errors and bad logic. Modern mobile applications do a lot of parsing of formats such as XML and JSON. Defects in these parsers or in the way they are used can result in unexpected DoS.
8 – Malicious third-party code
Assume the device is jailbroken. Let me say that again: assume your user’s device is jailbroken. Act accordingly. Also, even on legitimate, non jail-broken devices there are interesting problems that can arise related to the URL / Protocol handling mechanism. iOS is not very big on Inter Process Communication. One of the few mechanisms available to iOS developers to accomplish this is the custom URL scheme. Use these with extreme caution. External (malicious) web sites can call these. The behavior when multiple applications define the same scheme is undefined (and you can’t stop an application from trying to usurp your scheme).
From iOS 4.2 and on there is a better IPC mechanism (application:openURL:sourceAppplication:annotation). If you need to perform IPC, use this. You can even pass real objects instead of hacking them up into a URL ready format (see: trusting serialized objects is a bad idea).
9 – Client-side buffer overflow
This is still quite possible. Since Objective-C is a strict superset of C there is no limit to the depth in which an iOS can get itself in trouble with old C programming issues. I won’t belabor them here, but they are quite possible. Pay careful attention to your string formatting (NSLog, etc.). Stick to the NS* class hierarchy when at all possible. Abstract away your C code to the smallest amount possible and be extremely cautious with any C string and memory operations.
10 – Failure to apply server-side controls
See: The OWASP Top 10.
Other Thoughts
For some other thoughts on iOS application security please visit our earlier blog post on the topic.
For some other
Mallory Used to Discover Apps are Watching You
There is a good bit of discussion today regarding privacy and mobile applications. Specifically, the folks at Veracode ripped apart Pandora for Android and made some interesting discoveries. This research was spurred by this WSJ article: Mobile-App Makers Face U.S. Privacy Investigation. Referenced in the most recent WSJ article is an older article regarding research performed on a much larger group of applications: Your Apps Are Watching You. Digging a little deeper WSJ discloses their methodology used for their December research. If you read to the very last line of the methodology the article says, “He used an open-source tool called “Mallory” to decrypt encrypted data.”.
So, what is my point? That you should get to know Mallory. Intrepidus Group is actively working on the next release of Mallory to include many enhancements aimed at usability and making it a more comprehensive testing tool that makes it easy to perform research, such as that conducted by the WSJ. You can follow our active development at our Mallory Bitbucket repository. We plan to unveil a new release at SOURCE Boston where Raj and I will be giving a talk on a bevy of new features for both developers and security professionals alike.
CanSecWest 2011
CanSecWest 2011 is an important and influential gathering of information security professionals. The topics covered at CanSecWest are diverse and span a variety of topics on the offensive and defensive side of the information security fence. CanSecWest is a three day conference where attendees can attend every session, if they so choose. The talks are limited and high quality and the scheduling is such that no talks overlap. The focus is on quality.
Day 1
With that said there were a lot of great talks and presentations. I will highlight a favorite talk from each day. From the Wednesday sessions the most attention grabbing was the “SMS-o-Death” talk. Nico Golde and Collin Milliner cover a variety of attacks on SMS. Mulliner’s SMS reserach can be found at his site here. The “SMS-o-Death slides can be found here. Their research focused on “feature phones”, which are sort of smart, but not really, phones. They are a less interesting attack target, but their availability is huge and they represent, by far, the largest mobile attack surface out there. Surprise, they are quite vulnerable.
Day 2
For Thursday I liked the iPhone and iPad hacking talk (in my defense I do a lot of iOS hacking). It was a quick overview of some less common (and more common) security issues facing iOS application developers. The highlight being novel techniques to gain code execution, including abusing NSString formatting %@. If you have any statements that look like this [someString stringWithFormat:otherString], or NSLog(someNSString), bad developer no going home tonight for you! The talk also discussed data escaping vulnerabilities with XLS, PDF and RTF handling semantics. The talk covered a lot of ground. Alex Sotirov has a nice write up of it on his coverage of CanSecWest 2011.
Day 3
Vincenzo Iozzo and Giovanni Gola of Zynamics gave a talk on some advanced analysis techniques. In their talk they cover some of the concepts in the Zynamics tool, BinNavi, and discuss how to approach static analysis in a different way to discover certain classes of bugs. The approach to walking the call flow graph and setting up the static analysis in a particular, and novel, way allows them to more easily discover certain classes of bugs (they claim a best use for C++ life-span issues). The slides from the talk they gave at BlackHat DC, which is similar to the CSW talk can be found here. As always, the research Zynamics present is great and cutting edge. The short summary is: they have math and know how to (ab)use it.
Pwn2Own
Pwn2Own. About that. As an avid infosec observer, mobile application tester and bug hunter, I really love Pwn2Own. The results are a good where does the “rubber meet the road” public exhibition. It may not be for everyone, but it is entertaining. Pwn2Own setup. Pwn2Own results. The linked media coverage is a bit inaccurate, mainly because it didn’t take minutes, days or seconds, for a given target to fall. The researchers spent significant time outside of the contest to develop their exploits. Also, no one has genuinely researched or targeted Windows Phone 7 yet because it new and has little market share just yet. Windows Phone 7 did not fall, but the security of it is no mystery, I am going with “no different, or more safe, than any other smartphone operating system”. Android survived, which was a little surprising. So it goes.
This is not the Android Market Security Tool you are looking for
We have been actively following and analyzing the spate of Android malware in the Android Market place. The most recent outbreak to light up the blog-o-sphere has been the Droid Dream outbreak. Google’s response to this was to launch a search and destroy mission. They created and pushed a tool to all handsets that were infected with Droid Dream. The Android Market Security Tool (AMST) was pushed to devices that were known to have downloaded and installed infected applications. This tool disinfects the compromised handsets by eradicating all remnants of the Droid Dream trojan. However, what we found quite interesting, is that shortly after the release of AMST, a trojaned version of the AMST appeared and is making the rounds on the internet! (Yo dawg…)
Symantec performed an initial analysis on this piece of malware. They found some interesting links between the malware and a hosted Google code project. This sparked our interest and we decided to get a sample of this malware and perform our own analysis.
The first obvious difference is that the application is requesting very different permissions from the official Google tool, including the ability to change network settings and perform actions, such as send and receive SMS, which can be used fraudulently.
This image illustrations the permissions the application is granted. In particular it is allowed to change the network state, a fact which becomes important when coupled with some of the capabilities of this malware, which we will discuss shortly. The features of this malware are almost identical to the Fake 10086 malware, which has been previously analyzed. When we looked at the disassembled version of the fake AMST, it does appear to be extremely similar to the code found on this Google Code repository. Keep in mind this is malware targeting Android devices using Google’s own code hosting repository system to keep track of the malware development.
So what does this opensource malware do? One thing it does is change your Wireless Application Provider server and your APN. The capture below shows the Java version of this code doing that:
How this capability is used is unclear, but the fact that it is setting your APN, which is essentially where you access the Internet from on the carrier network, is a bit troubling. Additionally, the application has the ability to intercept SMS messages by abusing the RECEIVE_SMS permission. It uses this to filter out SMS from certain numbers so that the malware can receive SMS messages that the user is never aware of. The application then responds and takes some actions based on that SMS. Again, here is the Java code for clarity:
Another interesting feature of this malware is that it hooks the phone call receiver. On any phone call the phone receives it looks for two specific numbers, “10086″ (hence the name Fake 10086 of this Malware’s variant) and “10010″. Both of those numbers are associated with Chinese telecom carriers. The main purpose of all of these lovely “features” is to prevent the user from receiving support related to this malware and keep it on there. The main purpose of the malware is to message a “vedio” service, err, “video” service and rack of SMS text changes. The capture below illustrates some of the URLs and VEDIO love.
private static final String CMWAP = "cmwap";
public static final String CMNET = "cmnet";
// private static final String SERVER_URL = "http://go.ruitx.cn/Coop/request3.php";
private static final String SERVER_URL = "http://www.youlubg.com:81/Coop/request3.php";
// private static final String VEDIO_URL = "http://211.136.165.53/wl/rmw1s/pp66.jsp";
private static final String VEDIO_URL_REAL = "http://211.136.165.53/adapted/choose.jsp?dest=all&chooseUrl=QQQwlQQQrmw1sQQQpp66.jsp";
private static final Uri uri_apn = Uri.parse("content://telephony/carriers/preferapn");private static final Uri uri_apn_list = Uri.parse("content://telephony/carriers");Seems pretty ballzy to have the malicious source code posted on a Google Code repository, so we wanted to know more about this aspect. While the author seems to have worked on a few other projects, “mmsbg” seems to be the only thing updated by this account on Google Code recently. We had to wonder what type of jokes this guy would put in the signature that signed the trojaned APK file. A quick “keytool -printcert” of the CERT.RSA file is listed below. Notice the “EMAILADDRESS=lorenz@londatiga.net“.
Let’s see what is up at londatiga.net. Seems to be an Android developer with some APK files posted. Wonder what cert was used to sign the “AnReboot Widget” package which you can download from the site.
Notice the matching fingerprints (the MD5 and SHA1 lines). Looks like both the malware sample and the “AnReboot Widget” posted on the Londatiga site are signed with the same private key. What are the chances of that… we thought. Turns out Lorenz dropped a private key in a tutorial blog post on signing Android applications and then used it for this app (although his Android Market apps are signed with a different key). Anyhow, it is a good reminder that they’re called “private” keys for a reason. Might be time to generate a new one if you are using ones that have been downloaded by others.
Another point of interest are the whois results for the IP address in the malware:
inetnum: 211.136.96.0 - 211.136.191.255
netname: CMNET-shanghai
descr: China Mobile Communications Corporation - shanghai company
country: CN
admin-c: HL888-AP
tech-c: HL888-AP
mnt-by: MAINT-CN-CMCC
mnt-lower: MAINT-CN-CMCC-shanghai
The malware makes HTTP posts to this address. One final point we will raise is that the malware can also sets the user’s APN to a CMNET APN.
Regardless of the true intent of this malware, the malware authors of the world have clearly struck the first blow in the mobile malware war. This will be a fascinating space to watch as the collision of malware, personal data and mobile devices occurs.
@bitexploder, benn, jross, sid and DIAB1069
