Author Archives: jross
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
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
