Author Archives: sid
Google Wallet coming for iOS?
The list of two OS types in WalletShared: ANDROID and IOS (click to enlarge)
Let’s start by saying this is no smoking gun, but a pretty interesting case of information leakage through an application. For our regular blog readers, you’ll know we’ve been looking into NFC based applications over the past year. The jewel of all NFC apps is easily Google Wallet and thus we’ve spent a large amount of time trying to understand it. When you decompile an Android application, which isn’t obfuscated, you’re able to see the same class names, method names, variable names, and other identifiers as in the developer’s source code. In this case, Google Wallet includes a package called “wallet.proto” which contains parsers for any “Protocol Buffer” formatted data the application uses. While the name “Protocol Buffers” sounds generic, it’s actually Google’s well-documented mechanism for serializing data (think of it as their version of XML or PLists). If you followed the Google Wallet PIN hashing issue, you’ll remember that the PIN hash is stored in a protocol buffer.
The “WalletShared” protocol buffers package in the current version of Google Wallet contains hints of iOS within the parsers definitions. This includes defining the “DeviceContext -> HardwareType” field with only two values: “ANDROID” and “IOS”. iOS strings are also found in two additional protocol buffers called “IosDevice” and “IosWallet”. The classes only leak a little detail about the information being collected which include items named “appId”, “appVersion”, “walletUuid”, and a few “model” and “version” items.
Function names with
Now you might ask why anything about an iOS application, written in Objective C, would get compiled into an Android application, written in Java. This could happen because of how a Protocol Buffer structured data definition file is created. A developer typically creates a “.proto” file, which is a programming language independent file which defines the data structure. This “.proto” file is then compiled using the “protoc” application and creates the appropriate files for the language you are programming in. Thus, it’s simple to use the same “.proto” file to create a Java object or an Objective C object if they are both going to use the same data structure. While Objective C is not in the official protocol buffers package, there is an add-on for that language available. Thus it is quite likely if there was a “shared” data structure which both clients and the server would need to parse, the same “.proto” file would be used regardless of the application’s programming language.
Of course, if Google is developing Google Wallet for iOS, it raises numerous questions. Since iOS devices do not currently include an NFC radio or secure element, is Google planning to release a case, or “sleeve,” with these components? Or do they know something about the next iPhone we don’t? And if the next iPhone does have NFC and a Secure Element, would Apple allow Google access to those components? In any case, if Google is working on developing their wallet for iOS, this could be a sign of strong commitment by Google to contactless payment technology. And that’s a win for everyone regardless of which device is in your pocket right now.
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
EA Origin vulnerabilities, responsible disclosure, and the Force
If you’re a gamer like me, you’ve probably been waiting for the release of Star Wars: The Old Republic, currently being developed by Bioware. I’ve been looking for beta codes, and came across Penny Arcade’s beta code give-away some time ago (bless their souls).
As I was signing up for the beta, I noticed something interesting: the registration page immediately told you if the email you’d typed in matched an EA Origin account. This piqued my interest: was this exploitable, other than testing if email addresses were associated with Origin? I signed up with my Origin account, and strangely, it asked for a new password, without authenticating my current password. Digging further, I realized that you could reset the password to a new one of your choosing, with one caveat: the holder of the email account needs to access the verification link sent to the email address as part of signup. Here’s the email:
NewUser:
Thank you for joining the Star Wars™: The Old Republic™ community! To complete your registration and activate your account, simply verify your email address by clicking here. Remember, we will update or create an EA account using this email address upon your email validation.
Normally, this would be good enough to prevent unauthorized password resets, but I found it strange that nowhere on the registration page or the email did it say that my password would be reset, and no indication after the reset. Conceivably, you could sign up a large number of Origin accounts for the SWTOR beta, and if the target doesn’t log into his Origin account immediately, he’d be unaware his account has been compromised. If you’re a gamer, you’ve probably signed up for a dozen betas, hoping to get lucky now and then – a “confirm you want to join the Star Wars beta” email from EA would raise no suspicions whatsoever.
I decided to report the issue to EA. I couldn’t find a security contact on their website, but a bit of e-stalking later with a colleague, found the email address of the EA CISO, and shot off an email describing what I’d found. To my surprise, instead of being ignored or receiving a letter from their legal department, I got a response within the hour – “Do you mind sharing your details so we can address the issue promptly? We take security very seriously and would like to get on it right away.” I couldn’t have asked for anything better.
Four days and some email exchanges later, I received an email from one of their Online Development Directors: thank you for reporting the issue, a patch has been deployed – oh and we’d like to send you some free SWTOR swag to show our appreciation.
This was a pretty fun experience for me. It wasn’t a critical vulnerability, but had the potential for mass abuse. EA was on the ball in fixing the bug, and kept me in the loop. You don’t get that too often. Now if only I could use this to have EA give me a permanent beta testing status for all games 
Mutual Authentication in Android and iOS
This is a post on implementing mutual authentication while programming for Android and iOS. For the sake of brevity and focusing on the technical side of things, I’m assuming here that:
1. You know what client authentication is
2. You know how to issue certificates to your clients
3. You know how to configure IIS/Apache/webserver_that_floats_your_boat for client authentication
4. You know what I’m doing if I say “R.raw.resourceName” in Android, OR if I say I’m implementing a delegate in iOS
5. You have a DER-encoded certificate for the root issuer of your SSL certificate (rootCert.cer), and a PKCS#12 object containing the client authentication certificate with the private key and chain of issuing certificates (clientCert.p12).
You’ll notice that the title says “Mutual Authentication”, not “Client Authentication” – our goal here is to implement both strong client authentication using certificates, and verify that the server certificate presented to us is issued by a CA we trust explicitly. For example, if my server certificate is obtained from Verisign, I would like to verify that the SSL certificate chains up to the Verisign root, instead of say the Comodo or DigiNotar roots, or any other root stored in the system certificate store.
Now that we have our logistics out of the way:
Android
For Android, we’ll be using the SSLSocketFactory class to implement client authentication. Place all your trusted root issuer certificates into a Bouncy Castle store (BKS). You can create a Bouncy Castle store by doing the following:
keytool -import -alias "rootCert" -file rootCert.cer -keystore myApp.truststore
For the application below, I’m assuming that the trust store and the client certificate are added as resources to the application. In an actual application, the client certificate is probably something that is enrolled for and obtained after the application has been distributed.
KeyStore serverRootCert = KeyStore.getInstance("BKS");
serverRootCert.load(getResources().openRawResource(R.raw.sslapptruststore), "password".toCharArray());
KeyStore clientCert = KeyStore.getInstance("pkcs12");
clientCert.load(getResources().openRawResource(R.raw.clientpass), "password".toCharArray());This loads the truststore containing the trusted root certificates, and the client certificate we need to use for authentication.
HttpClient httpClient = null;
HttpParams httpParams = new BasicHttpParams();
SSLSocketFactory sslSocketFactory = new SSLSocketFactory(clientCert, null, serverRootCert);
SchemeRegistry registry = new SchemeRegistry();
registry.register(new Scheme("https", sslSocketFactory, 443));
httpClient = new DefaultHttpClient(new ThreadSafeClientConnManager(httpParams, registry), httpParams);The code above creates a standard SSLSocketFactory object, setting our trust store as the certificate store we want to compare against, and adding the client certificate we want to use for authentication. The HttpClient object can then be used as you normally would in an application – i.e. set the URL we want to access, execute the request, as shown below:
HttpGet request = new HttpGet("https://example.com/clientAuthRequired.html");
HttpResponse response = httpClient.execute(request);
iOS
iOS follows a slightly different paradigm then Android. To implement client authentication, you need to override/implement specific NSURLConnection delegates.
There are a few basic steps to be kept in mind:
- Define the URL resource you want to retrieve
- Specify the authentication methods you want to handle
- Create security objects for the authentication method
- Handle the authentication challenge
NSURL *url = [NSURL URLWithString:@”https://example.com/clientAuthRequired.html”];
if(nil == url)
// handle errorThat completes the complex process of defining a URL
- (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace {
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust])
return YES;
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodClientCertificate])
return YES;
return NO;
}This tells iOS that we would like to handle the Server Trust and Client Authentication events. If you want only client authentication, and want iOS to handle your trust, the server trust part can be skipped.
NSData *rootCertData = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@”rootCert” ofType:@”cer”]];
SecCertificateRef rootCertRef = SecCertificateCreateWithData(kCFAllocatorDefault, (CFDataRef) rootCertData);
NSData *p12Data = [NSData dataWithContentsOfFile:[[NSBundle mainBundle] pathForResource:@“clientCert" ofType:@"p12"]];
NSArray *item = nil;
NSDictionary *dict = [NSDictionary dictionaryWithObjectsAndKeys:@“password", kSecImportExportPassphrase, nil];
SecPKCS12Import((CFDataRef) p12Data , (CFDictionaryRef)dict, (CFArrayRef *)item);
SecIdentityRef identity = (SecIdentityRef)[[item objectAtIndex:0] objectForKey:(id)kSecImportItemIdentity];Analogous to the Android code, we first load the resources we need to authenticate and verify identity.
-(void) connection:didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge {
if([[protectionSpace authenticationMethod] isEqualToString:NSURLAuthenticationMethodServerTrust]) { // Verify method
SecTrustRef trust = [[challenge protectionSpace] serverTrust]; // Create trust object
NSArray *trustArray = [NSArray arrayWithObjects:rootCertRef, nil]; // Add as many certificates as needed
SecTrustSetAnchorCertificates(trust, (CFArrayRef) trustArray ); // Set trust anchors
SecTrustResultType trustResult; // Store trust result in this
SecTrustEvaluate(trust, trustResult); // Evaluate server trust
if(trust_result == kSecTrustResultUnspecified) {
NSURLCredential *credential = [NSURLCredential credentialForTrust:trust];
[[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
} else {
// handle error;
}
if([[challenge protectionSpace] authenticationMethod] isEqualToString:NSURLAuthenticationMethodClientCertificate]) {
NSURLCredential *credential = [NSURLCredential credentialWithIdentity:identity certificates:nil persistence:NSURLCredentialPersistenceNone];
[[challenge sender] useCredential:credential forAuthenticationChallenge:challenge];
}
}For limiting server trust, the list of root certificates we explicitly trust is set as the trust store to compare against. SecTrustSetAnchorCertificates overrides the system settings for making trust decisions, and replaces them with your own. For client authentication, the client certificate we loaded previously needs to be added as an NSURLCredential to the connection, and then let the networking do it’s thing.
Pentesting WP7 apps (Part I)
With over 30,000 apps in the marketplace within a year of launch, Microsoft’s Windows Phone 7 platform seems to grabbing consumer attention slowly but steadily. Though the installed user base is nowhere close to that of Android or iOS, Gartner’s predictions notwithstanding, in the last few months we’ve seen an increasing interest from companies on this new mobile platform. One of the questions we hear a lot is how we go about pentesting WP7 apps, and what tools their QA teams should be looking at. This post, and others in this series, is aimed at answering some of these questions.
Application Package Structure
WP7 apps are zip files renamed as “.xap” archives, and can be opened by standard archival programs such as 7-Zip and WinRar. Rename the application package “MyApp.xap” to “MyApp.zip”, and then unzip the archive. Generally, the following files will be found inside application package:
- AppManifest.xaml – Lists assemblies required by the application, application code entry point, runtime version.
- MyApplication.dll – Main application DLL. This contains the application logic and embedded resources like XAML layouts and images.
- Background.png, ApplicationIcon.png – Images for the application
- WMAppManifest.xml – Lists capabilities requested by the application, application GUID, application XAML entry point, app icons and live tile/hub bindings.
- WMAppPRHeader.xml – DRM header for app (in case of download from Marketplace).
- WPInteroptManifest.xml* – Optional. If it exists, the application is probably making use of interop services.
- MyInteropDll.dll* – Optional. If it exists, the application is probably making use of interop services.
- System assemblies – Default WP7 assemblies, e.g. Microsoft.Phone.Controls.dll, System.Windows.Controls.dll, etc.
- Images/* - Application icon / app bar images
*Note – With the Mango update release, interop services will probably be blocked. This provided the COM interoperability bridge, allowing applications to call unmanaged code from managed binaries. This shouldn’t concern you unless you develop OEM or mobile operator apps, as Microsoft restricts use of the interop capability.
Many applications also have accompanying resource folders, which hold static content like configuration files, sounds, etc., which might be worth looking at.
The WMAppManifest.xml file lists the capabilities requested by the application, which should be as minimal as possible. Capabilities define what resources an app requests access to, similar to permissions in an Android app. The capabilities required by application, based on the libraries it references, can be determined by using the Windows Phone Capability Detection Tool, packaged with the WP7 SDK.
C:\Program Files (x86)\Microsoft SDKs\Windows Phone\v7.0\Tools\CapDetect>CapabilityDetection.exe Rules.xml MyApplication.dll
ID_CAP_NETWORKING
ID_CAP_MEDIALIB
ID_CAP_SENSORS
ID_CAP_WEBBROWSERCOMPONENT
ID_CAP_IDENTITY_DEVICEThe main point of analysis is the MyApplicationName.dll file. This contains the primary application logic. Though theoretically any .NET language is supported, typically WP7 applications are written in C# and compiled as managed binaries. Though WP7 apps may be relatively new, the .NET language has been around a while, and a number of tools exist to aid in reversing .NET binaries.
Decompilation and Static Analysis
After extracting XAP contents, identify the main DLL file. This is usually the assembly pointed to by the “EntryPointAssembly” field in AppManifest.xaml. The DLL is a .NET managed code binary, and depending on any obfuscation used, can be decompiled back into C# by tools like .NET Reflector and dotPeek.
- .NET Reflector – This is my preferred tool for decompilation of .NET binaries. The interface is simple and easy to use – however, I find myself getting better results with dotPeek (see below). The standard version of the tool costs $35, though a 14-day evaluation license is available.
- dotPeek – This is a recent tool from JetBrains, still in development. It’s free, and managed to decompile some binaries that Reflector bailed out on. I’m expecting good things from this.
I’ll use .NET Reflector below.
Once the target binary has been identified, in our case MyApplication.dll, load it in .NET Reflector by clicking on File -> Open and selecting the file. The tool may complain about missing assemblies; this happens because it wasn’t built to support WP7 and cannot resolve the assembly names automatically. Whenever it complains about an assembly, for example “could not find Microsoft.Phone.dll”, it also offers the user a chance to load the file manually. Click on the “…” and browse to “Program Files\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0\Profile\WindowsPhone”, where you will find all the system DLLs that are generally used by WP7 applications. You may need to install the WP7 Developer Tools SDK (http://create.msdn.com/en-US/resources/downloads) if you don’t have that folder already. If you’re using a 64-bit flavor of Windows, replace “Program Files” with “Program Files (x86)”.
Right click the assembly on the tree to the left and click on “Disassemble”. The tree should now be expandable, and will have two nodes, “MyApplication.dll” and “Resources”. Resources contains all the embedded resources for the app, like XAML and image files. These can be extracted and saved for perusal – sometimes, the XAML files have interesting tidbits left by the developer. Double click the resources file to load it into the right tree, then right click -> “Save As” on the resource you want to save.
The screenshot above shows a typical decompiled binary. I’ve obfuscated the namespace, since it’s a real app in the Marketplace. The second node contains reference points to system DLLs, and the application code namespaces. This is essentially the meat of the application – it represents the code tree of the application and allows to look for bugs in the decompiled code. Expand the code tree and click on any node to view the source. The structure is DLL -> Namespace -> Class -> Class Members. It’s more expedient to view it by class – click on the class you want to investigate, and you can see declarations for all methods and variables used by the class. Click on “Expand Methods” on the right hand pane to view method definitions.
Clicking on “Tools” -> “Search” on the main window bar will bring up the search interface. Type in the desired search string in the search box, results should dynamically update. Results can be refined by type, member, string/constant, or exact match by the little icons to the right of the search bar.
That’s all I have this time – I’ll talk about exploring Isolated Storage, interop DLLs, analyzing network traffic, and other points of interest in the next post.
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
ShmooCon 2011
Hey guys, I’m Siddarth Adukia, the current FNG at the Intrepidus Group. We just came back from ShmooCon, the first one I’ve been to, and I thought I’d do a little write up.
Getting to DC from New York was.. interesting. Raj, Max, and I decided to drive it down. As soon as we hit 50mph on the highway, we were greeted with what sounded like a hard disk needle scratching the platter.
Umm. Not good.
We pulled over, and our resident car enthusiast Raj popped the hood and began poking around. A few seconds later he looks at us and says, “Looks like the front bumper is loose. I got this. I need an avocado, a corkscrew, and a zip tie.” Blank stares ensue. “How about just a zip tie?” That we had. And thus I present the hardware hack of the year.
The rest of the journey was pretty smooth, with a little detour to Philly for lunch.
We drove down a day early to check out our office at Chantilly, Virginia. This facility houses most of our crew on the PhishMe side, but more importantly the giant Swings of Awesomeness.
ConTime! There were quite a few talks on mobile security at the con, including Intrepidus Group’s Zach Lanier, who teamed up with Jon Oberheide for a presentation on the current state of Android security. That was a well-attended presentation, with people spilling out into the corridors. Another very cool presentation was Project Ubertooth, by Michael Ossmann. An open-source passive Bluetooth sniffer, with a possibility to extend the platform for Bluetooth packet injection? Sign me up! There’s a Kickstarter project up, so if you’re looking to get one yourself, it’s $100 for a fully assembled one. IG has pledged in the top bucket, and I think a bunch of us will be picking up personal copies as well.
Another talk worth noting was the keynote from Mudge – “Analytic Framework for Cyber Security”. It wasn’t quite what I was expecting, I thought it would be a bit more concrete than giving grants to Hacker Spaces and their ilk, though I guess a bit might have been redacted by DARPA. His analysis of the current state of cyber security was pretty interesting, especially the bit about how policy mandated “strong” passwords actually result in weaker passwords. Most people in the security arena are already familiar with the consequences of strong password policies. This has been spoken and written about in the past; what I hadn’t seen was the analysis from the hash-cracking contest from Defcon, where team Hashcat took first place. Looking at the graph over time for password hashes cracked, you see a stead slow slope for hashes cracked at the start, and then curves sharply upwards before plateauing. The sharp increase was attributed to similar passwords using an English word, followed by some numbers, and then a special character, commonly a bang, to meet the “strong” password policy. Need to change the password every X days? Just keep incrementing the appended number. Mudge gave this an example of how well-meaning but flawed security policies inadvertently lead to weaker security, weaker passwords in this case.
David Schuetz, another fellow Intrepid, joined a panel for The Past, Present, and Future of “Something You Know”, a discussion on the state of password cracking. With rainbow tables and highly parallelized cheap hardware, we seem to be hitting a point where “strong” passwords are not as strong as they were. The panel was a step forward to raising awareness over these issues, though there still seem to many lines of thought on how exactly we might do this. David also won the badge contest this year (again), much to the crowd’s chagrin.
There a few other talks that I’d call interesting, but didn’t give me a nerdgasm. Danny Quist’s enhancements to Vera are pretty useful for someone into malware reversing, but the URL enlargement talk by Daniel Crowley was somewhere between meh and interesting (you found people using it to link personal Google Docs, spam websites, Rick-rolls and goatse? Whodathunkit!). The two interesting points were multiple levels of redirection using url shortners to hypothetically frustrate analysis, and parasitic storage to store files in chunks in a url. Sarah Edwards’ talk on iPhone app data security was a series of anecdotes on how bad app developers are in security. No surprises there, though I would have preferred to hear more about methodology then an individual walkthrough of how thirty different third party iPhone apps stored usernames / passwords / location data / etc. in the clear / base64. And why do we still have multiple talks on how printers got owned?
I missed a few other talks I wanted to go to; the EFF talk was supposed to be good, as well as the SMS botnet control one by Georgia Weidam. I didn’t miss them because of scheduling conflicts with other talks, but because I was having way too much fun at the IG booth.
The IG booth was quickly established as the chill out spot for a large number of people, IG folks and non-IG alike. This was because we are cool and interesting, and had nothing to do with the cases of Sierra Nevada or Lucha Libre masks at the booth. It also led me to an interesting observation – potential hires answer technical questions with greater accuracy, detail and honesty while inebriated (See: Ballmer Peak). We had a little challenge card at the booth, if you can solve the challenge, you bypass a few rounds of interviews. Sadly, not many people could solve it, and those who did didn’t need to solve it to prove they were leet.
The number of times the word “Mallory” came up during the weekend was amazing – we had quite a few people talking to us on how they were starting to use Mallory for their security assessments, and what additional features they’d like to see. Keep a look out for a lot more features and how-to’s on Mallory this year.
There are a lot of things I’m missing out in this post – Hack Fortress, Ghost in the Shellcode, the ShmooCon party, hijinks with lasers and shmooballs, tequila pong, and things of dubious and quasi-legal nature, which are probably left better unsaid. That’s all the unclassified info I can share at this point; watch out for Raj and Jeremy’s talk on Mallory at SOURCE Boston in April!
