Category Archives: Security

Most Vulnerable App for Android

It’s a race to the bottom. Or, we learn how to improve from studying mistakes, ala target practice. Either way you look at it, Zuk offers an Android app with all the fixings.

Download the MoshZuk Application: contains the following vulnerabilities:

Stack Overflow
Heap Overflow
SQL Injection
Command Injection
Format Strings
Double Free
Directory Traversal
Race Condition
Hardcoded Passwords
Bad code habits
Overblown permissions
Bad file permissions

The best part is, we’ve specially constructed the vulnerabilities so it can be chained (extra points in this competition)

I look at it as the new Zuk standard for automated code analysis tests – the Zuk afikoman hunt. If a tool can’t find 100% it fails.

When the code is released it probably will be copied and used by developers who want to write apps but do not realize it was written to be vulnerable. The flip side is thus that attackers will create simple automation to quickly find and target apps ignorantly based on MoshZuk.

E.A.S.T. Fraud Update

Data on ATM fraud in 23 countries has been released in the second European ATM Security Team (EAST) European Fraud Update for 2011.

Skimming attacks at ATMs continue with 20 countries reporting incidents. 8 countries reported increases in such incidents, and 2 countries decreases. 2 countries have reported a new variant of skimming device, and three countries that anti-skimming devices have been successfully over-ruled or removed by criminals.

This follows the recent EMV loophole investigations in Operation Night Clone (simultaneous arrest operations in Bulgaria, Italy, Spain, Poland and the USA involving over 200 police officers), as explained by Europol.

Organised crime groups are always looking for new criminal opportunities and for some time they have been targeting the vulnerability of payment cards with magnetic strips. Within the EU, criminals’ work has been made more difficult with the full implementation of EMV technology (chip and PIN), but criminals have since exploited a loophole in these security arrangements by making illegal transactions with EU issued cards in non-EMV compliant regions, including Africa and the USA. Payment cards in the EU are targeted for cloning, and the fraud committed in other regions which still accept payment by magnetic strip. This was the major feature of the criminal methodology used by the organised crime group in this case and is an increasingly common problem.

I suppose they would also consider on-line transactions or other card-not-present situations a “loophole”.

Truth v. Privacy: Colbert on Murdoch

Stephen Colbert offers some brilliant word smithing on the Rupert Murdoch privacy scandal. He cites a former editor of Murdoch’s News of the World, Paul McMullan:

I’ve always said that I’ve just tried to write articles in a truthful way and, you know, what better source of getting the truth is to listen to someone’s messages.

Then Colbert follows the advice and offers exclusive access to Rupert Murdock’s messages.

This thing’s got out of control! I’m Australian for F@#$ed!

Incident Debt Visualization

Interesting visualization chart from clarified networks.

…the horizontal axis represents time (the beginning of March in the left, the end of June in the right) and the vertical axis represents the count of new incidents that appeared to do something nasty at that point of time. One bar is about two days, one line through the the vertical axis is about 1000 incidents. Now, when the animation starts going, you can see how unhandled incidents (red color) are detected and then turning into handled ones (grey). In the end we also show the cumulative amount of work still left at each point of time. Sort of “incident debt”, if you will.

The information conveyed looks more like a work flow queue for a service than a security illustration. What does it mean when an incident is “unhandled”? No response or no solution? Maybe that’s why they call it a “debt” — they’re representing service workloads for security but it could just as easily be any service ticket. It’s the basic difference between items completed and those still being worked on.

Also, each incident appears to have an equal value of debt, which seems unrealistic. Or maybe not all incidents are equal units. Hard to tell. Bouncing lines are a compelling animation but much more interesting would be workload relative to risk. Then workload relative to risk relative to source could be seen. In other words, where are the highest risk incidents and what percentage of resources (number of resources and length of time) do they consume (versus low risk incidents)?