10 September 2012
~1 min
By behrang
Today’s smart cards such as banking cards and smart corporate badges are capable of running multiple tiny applications which are often written in high level programming languages like Java or Microsoft .NET and compiled into small card resident binaries. It is a critical security requirement to isolate the execution context and data storage of these applications in order to protect them from unauthorized access by other malicious card applications. To satisfy this requirement, multi-application smart cards implement an “Application Firewall” concept in their operating system which creates an execution sandbox for card applications.
There has been a healthy reaction to our initial post on our research into the RSA SecureID Software Token. A number of readers had questions about certain aspects of the research, and I thought I’d clear up a number of concerns that people have.
The research pointed out two findings; the first of which is in fact a design vulnerability in RSA software’s “Token Binding” mechanism. The second finding is another design issue that affects not only RSA software token but also any other software, which generates pseudo-random numbers from a “secret seed” running on traditional computing devices such as laptops, tablets or mobile phones. The correct way of performing this has been approached with hardware tokens, which are often tamper-resistant.
Widespread use of smart phones by employees to perform work related activities has introduced the idea of using these devices as an authentication token. As an example of such attempts, RSA SecureID software tokens are available for iPhone, Nokia and the Windows platforms. Obviously, mobile phones would not be able to provide the level of tamper-resistance that hardware tokens would, but I was interested to know how easy/hard it could be for a potential attacker to clone RSA SecureID software tokens. I used the Windows version of the RSA SecurID Software Token for Microsoft Windows version 4.10 for my analysis and discovered the following issues:
This week, Charl van der Walt and I (Saurabh) spoke at Mobile Security Summit organized by IIR (http://www.iir.co.za/detail.php?e=2389).
Charl was the keynote speaker and presented his insight on the impact of the adoption of mobile devices throughout Africa and the subsequent rise of security related risks. During his talk, he addressed the following:
Understanding the need for mobile security to be taken seriously in Africa Analysing the broader implications for the user and the company The types of attacks occurring against mobile devices What does the future of mobile security look like and what are the potential threats to users? Understanding the particular threats posed by smartphones and other portable devices, e.g. tablets The presentation can be accessed via link below:
This blog post steps through how to convert encrypted iPhone application bundles into plaintext application bundles that are easier to analyse.
Requirements:
1) Jailbroken iPhone with OpenSSH, gdb plus other utilities (com.ericasadun.utilities etc. etc.)
2) An iPhone app
3) On your machine:
otool (comes with iPhone SDK) Hex editor (0xED, HexWorkshop etc.) Ida – Version 5.2 through 5.6 supports remote debugging of iPhone applications (iphone_server). For this article, I will use the app name as “blah”.
Introduction From time to time I like to delve into malware analysis as a pastime and post interesting examples, and recently we received a malware sample that had a low-detection rate. Anti-Virus coverage was 15/43 (35.7%) based on a virustotal.com report and Norman sandbox did not detect any suspicious activity as shown in the report below:
Norman sandbox report did not show any registry or network activity. This might be due to the use of virtual CPU or sandbox bypass techniques by the malware. Sunbelt sandbox was down at the time of the analysis.
BackupExec agent is often among common services found on the internal pen tests. The agent software stores an encrypted “logon account” password in its backend MS SQL database (LoginAccounts table). These accounts include the “system logon account” which is used to run agent services and an optional number of active directory accounts that are used to access resources over the network. The following scenarios can result in access to encrypted passwords:
I’ve developed a FTP like multi-threaded server application as a target for this challenge of the month. It has been coded in c and compiled by VC++ 2008. This is a three step challenge:
Step 1- Find the correct “passphrase” format to logon to the server and get the “Access Granted” message. (You may use a debugger like Ollydbg to do Live RE for this step).
Step 2- Do vulnerability research on the server software. There is at least one exploitable bug but there could be more bugs or error conditions. Try to spot a memory corruption bug and write a denial of service exploit for it.
Introducing [http://www.reddit.com/r/ReverseEngineering/]
(like its name suggests, a reddit thats all about Code RE..)
APSB08-15 is the latest adobe security advisory regarding a memory corruption vulnerabilty in Acrobat Reader versions <8.1.2
As expected, the advisory does not include technical details about the attack vector, So let’s try to reverse the related Adobe patch to find more about this vulnerability. I’m going to use IDA 5.2 with patchdiff2 plugin (thanks to kris hint on this plug-in).
The patch is released as a MSI file. I used Greg Duncan’s Less MSIèrables tool to examine the content of this patch: