eightbit.io @eightbit-io - Tumblr Blog

YOW! Connected 2014 - Developing Secure iOS Applications

Here are my slides from my YOW! Connected presentation from last week. I had a great time at the conference and met a lot of great people. It was great to present to developers about security issues and I thank the YOW! team for the opportunity.

Yow connected developing secure i os applications from mgianarakis

#ios #security #secure development

Neat post from Norm about weaknesses in PHP's lcg_value function. Norm runs the Sydney OWASP chapter and is generally an all-around awesome dude. If you are in Sydney and interested in security I would definitely recommend you check it out.

#security #phplol #owasp

Ruxmon Brisbane (April 2014) - Introduction to iOS Application Penetration Testing

My slides for my presentation at the Ruxmon Brisbane meet up earlier this month. Pretty much the same as the OWASP presentation but they are up here in case anyone wants them.

Ruxmon April 2014 - Introduction to iOS Penetration Testing from eightbit

#security #ios #penetration testing

The slides to my Breakfast Brief presentations earlier this month have been posted online here.

Enjoy.

#security #ios

I will be presenting on iOS application penetration testing at Ruxmon in Brisbane this Friday.

It starts at 6pm at the Red Hat offices and there is a possibly much more interesting talk on Docker security as well.

The last Ruxmon I went to in Brisbane was years ago now but if the Melbourne events are anything to go by I'm sure there will be drinks somewhere afterwards as well.

#ruxmon #ios #security

So Matt Thompson is writing a book on low-level iOS programming.

Take my money!

#ios #programming #nshipster

Thoughts on PCI DSS

Ty Miller from Threat Intelligence posted an interesting take a little while back on the lack of difficulty in the PCI DSS exams and how that may be contributing to data a lack of quality PCI auditors. In turn, this results in weaker application of the PCI DSS mandated security controls.

The PCI DSS exams don’t exactly require months of study in order to pass them. The first time I passed the exams, I had sat the course but didn’t even have to read the PCI DSS requirements. This low standard of the exam allows unqualified auditors to become certified, which I have.

It’s an interesting perspective and I agree that this can definitely be a contributing factor in poor implementation of the standards and lax certifications but I think the core of the issue lies in the fact that the payment card industry wants PCI DSS compliance to be more than what it is. They want to sell assurance to consumers that their card data is safe. The problem is they can’t sell that. You can’t ever have assurance that you won’t be hacked. If you have valuable data and you are a target attackers will find a way.

Unfortunately the security industry is built on trying to sell this assurance - “buy this next next next generation firewall/IDS/WAF and you won’t get hacked!”. The whole PCI ecosystem is no different and unfortunately organisations buy into it and believe they have done enough.

This leads to a perception problem when these organisations suffer massive breaches of cardholder data despite having been certified as PCI compliant. As a result nobody seems to take PCI DSS seriously as a security standard and who can blame them?

This is not to say PCI DSS doesn’t have any security benefit. As a set of baseline standards for the security of sensitive data it’s not too bad, but real information security is more than this. Information security is tough. Real tough. It’s a constant struggle that you never “win”, only “manage”. The organisations that do security well recognise this. The know that information security cannot easily be distilled into a set boxes that you can tick.

There are no easy answers. There is no silver bullet. PCI DSS is no exception.

#security #rant #pci

Neat little tool to bypass ASLR in iOS applications by flipping the PIE flag.

#ios #reverse engineering

OWASP Melbourne - Introduction to iOS Application Penetration Testing

My slides for my presentation at the OWASP Melbourne meet up last Thursday. Went a bit long but everybody seemed engaged and interested. Demo gods looked favourably on me too.

OWASP Melbourne - Introduction to iOS Application Penetration Testing from eightbit

#ios #owasp #pentesting

Definitely one of the better "vulnerable" iOS apps to get started with. Recommended if you are getting into iOS app testing.

Back Into It

The past few months have been a bit hectic for me with the birth of my son and as such this blog ended up settling in to a much lower position on my list of priorities. I’m not sure if anybody actually reads my writing here but it is something I enjoy doing and now that things are settling down a bit again I’m looking to start posting here a bit more regularly.

I’m not going to commit to a schedule or anything of that nature but I want to make more of an effort to record my learnings, thoughts and knowledge in the information security field here.

I don’t run ads. I don’t advertise or promote the company I work for. I don’t derive anything out of this other than my own personal satisfaction which I think is as good a reason as any to kick things off again.

#personal #random

Drazen Drazic linked one of his old posts the other day on LinkedIn in the wake of the Target breach. I definitely agree with the sentiment of the post. All of the items listed that fall under the banner "security" can be overwhelming for many organisations - including those that seemingly have the resources and appropriate governance. In a lot of cases a penetration test might be the easiest thing to comprehend for an organisation (and on the other side the easiest to sell) even if it's not going to be the most beneficial to the organisation.

Draz attributes this, in part, with the focus on the technical which is certainly true but I believe the bigger issue is the insular nature of the industry as a whole. I am generalising a bit here but there is a definite "us vs. them" mentality that is pervasive in the industry and it builds a certain arrogance where we beat down organisations and developers who fail to get security right instead of truly helping them.

Most in the industry blame it on organisations who "don't get it" and don't give security the proper support but what are we doing about this as an industry? We present technical talks at conferences and pat ourselves on the back at how we outsmarted such and such company/technology but how often do we truly reach out to those we are actually trying to help and assist them in meaningful ways. Why is the best that we can offer in the way of help is to show you how we can break your app a hundred different ways?

Is that really the best we can do?

#security #rant

Five Myths About Jailbreaking (From A Security Perspective)

I do a lot of iOS application security assessments for various companies both large and small. One of the common misunderstandings my clients have is around jailbreaking and the risks that need to be considered.

Hopefully this post will help clarify the risks and debunk some commonly held views around jailbreaking.

Myth 1 - Public Jailbreaks Are The Only Jailbreaks

This is a common one. When I raise an issue with an app that would require a compromised device to exploit I will commonly hear “but there is no jailbreak for x.x.x firmware”.

Putting aside the fact that not all of your users will update to the latest point release of the firmware, there is an incorrect assumption that the only jailbreaks are the ones that are publicly available online.

iOS vulnerabilities and exploits are increasingly valuable. Reports peg iOS exploits selling for up to $US500,000. There are many more exploits out there than just those that people have decided to give out for free on the internet.

Myth 2 - Jailbreaks Require Physical Access to the Device

Another common response I hear is “well someone would need to steal the device to compromise it and then we would know”. This is largely an extension of the first myth. Just as public jailbreaks are not the only exploits, not all jailbreaks require physical access.

A good public example of this were the ‘JailbreakMe 2.0 and 3.0’ jailbreaks which both exploited vulnerabilities in the FreeType libraries used in rendering PDF files. In both instances all a user needed to do to jailbreak the device was to navigate to a website and click on a link that launched the exploit. Although this was done in the context of a jailbreak it is not too hard to imagine similar flaws being exploited in a more targeted and stealthy manner using social engineering.

Myth 3 - Jailbreaks Are Always Obvious to the User

It is a commonly held misconception that if Cydia is not on the device then it is not jailbroken. Cydia is an app that is commonly installed with public jailbreaks but is certainly not a prerequisite or in any way required for a jailbreak. In fact, any kind of targeted exploit is unlikely to install Cydia in the first place.

Myth 4 - Jailbreaking is Apple’s Problem

While the security of the iOS platform is definitely Apple’s problem, the security of your app, your data and your users is squarely on your shoulders. The security risk to your organisation is your responsibility. You will be the one that suffers the impact if your app is compromised and you should be actively managing that risk.

Developers of apps that are likely to be targeted by attackers should operate on the assumption that the app will be run on a compromised device and design the application and controls accordingly. Apps that have payment functionality or handle highly sensitive data are likely to be a target.

What controls are appropriate will depend on the risk profile of your organisation and your app but it is something that needs to be considered. Apple won’t secure your app for you.

Myth 5 - You Can Completely Protect Against Jailbreaking

Unfortunately you will never be able to completely secure an application. A determined and skilled attacker with a debugger and access to your app will likely be able to bypass any jailbreak protections that you put in place.

This isn’t a reason to not do anything though. The idea is to raise the bar for the security of your app so that it becomes too difficult or costly to attack. How high you raise the bar will depend on the risk profile of the app, the kind of threats you face and, more likely, your budget.

#security #ios #jailbreaking

How To Set Up An iOS Pen Testing Environment

Over the past few years I have focussed heavily on mobile application security and in particular application security on the iOS platform. A lot of people starting out want to know how to get set up to test iOS application so I thought I'd do up a quick guide to getting started.

Tools of the Trade

The following is a list the hardware and software you will need to get started pen testing iOS applications.

Hardware:

A Jailbroken iDevice

It doesn't really matter which iOS device you choose. An iPad is probably the most versatile as it can run iPhone and iPad apps.

You can do some testing on a non-jailbroken device but the coverage is not as great. The latest public jailbreak, evasi0n, is for iOS 6.1.2 and is available here. The team behind the jailbreak, evad3rs, have done a great job with a really polished tool that makes jailbreaking the device a pretty simple exercise.

There is currently no jailbreak for iOS 7 (yet) so if you have a more recent device or have updated then you are unfortunately out of luck for now.

As a side note - finding and exploiting vulnerabilities in iOS to allow for a jailbreak is not a trivial task. It requires skill and time. iOS bugs are also pretty valuable. So if the jailbreak team asks for a donation, consider throwing some money their way. Especially if you intend to use the jailbreak to pen test applications in a commercial sense or to test your own commercial apps.

Wireless Networking

There are multiple ways to connect to the device but a wireless network is the simplest way to get started. You can use SSH over USB (more on setting this up below) but it's usually just easier to set up and use a wireless network.

Computer (derp!)

The most common question I get asked is "do I need a Mac to test iOS applications?". The short answer is no. The slightly longer answer is no, but it's probably a good idea, particularly if you would like to do code review or test using the simulator. You could get away with an Linux box or an OS X VM but I just prefer to use OS X natively.

Software:

The following is a list of software you will need to get going. I will go over setting these up in the next section.

Xcode and Command Line Utilities available from the Mac App Store (requires an Apple ID)

Intercepting Proxy such as Burp Proxy available here, ZAP Proxy available here or Abrupt Proxy available here. I will use Burp.

openSSH available via Cydia and iPhone-tunnel available here

SQLite available here or SQLite Database Browser available here

keychain-dumper available here

class-dump-z available here

gdb available via Cydia

cycript available here

mobilesubstrate available here

adv-cmds available via Cydia

Darwin CC Tools available via Cydia

evasi0n available here (latest public Jailbreak)

redsn0w available from the Dev Team

ios-ssl-killswitch by iSEC Partners available here

Setting up the Environment

Install Xcode and Command Line Tools

Xcode is Apple's IDE and includes the latest iOS SDK and iOS Simulator. It's available for free on the Mac App Store (requires an Apple ID). Once Xcode is installed be sure to install the Command Line Tools via the components download tab in the preferences (XCode->Preferences->Downloads->Components). Older versions of the iOS Simulator are available here too if necessary.

Install Burp Suite

Pretty standard.

Jailbreak your device

The current public jailbreak is available at [evasi0n.com]. The jailbreak software is pretty slick and easy to use so I won't detail the steps here however as a caution always back up your device first.

Install OpenSSH

OpenSSH can be installed via Cydia (which would have been installed when the device was jailbroken). The default password for the root account on iOS is alpine but you should probably change it, as well as the password for the user mobile, to something else.

To change the root password first SSH into the device over the wireless network using the default credentials:

ssh root@[IP ADDRESS]

If you don't have a wireless network the easiest way to connect to the device is using iPhone Tunnel:

./iphone_tunnel -lport 2222 ssh -p 2222 [email protected]

Use the passwd command to change the root password:

passwd

To change the password for the mobile user:

passwd mobile

Add Proxy Cert

In order to intercept HTTPS traffic you will need to add the self signed Burp Portswigger cert (or the equivalent for whatever proxy you are using) to your device:

Use your desktop browser to export Burp's CA certificate. Using your browser, visit http://burp and click the "Cert" link to download your Burp CA certificate. Save the certificate somewhere on your computer using the .crt file extension.

Attach the cert to an email and send it from your desktop computer to an email account that you can access on your device.

On the device, open the email and click on the attached cert

Tap "Install" and follow the prompts to install the cert on the device.

Don't forget to set the proxy settings on the device (available in the network settings) appropriately.

Install Mobile Substrate, dpkg, wget and Preference Loader

All of these packages can be install via Cydia.

Disable SSL Validation

It is increasingly common to find applications that use certificate pinning. If the application employs cert pinning or other application level SSL validation methods it may impact the interception of HTTPS traffic.

There are manual ways to do this (which will probably be the subject of another blog post) but for now there we will use a great tweak to disable SSL validation - ios-ssl-killswitch by iSEC Partners.

It works by patching functions in the Secure Transport API, SSLCreateContext(), SSLSetSessionOption() and SSLHandshake(). Higher level APIs like NSURLConnection rely on the Secure Transport API for their certificate validation routines and should defeat cert pinning in most apps.

To install it use dpkg:

dpkg -i com.isecpartners.nabla.sslkillswitch_v0.5-iOS_6.1.deb

You will then need to "respring" the device:

killall -HUP SpringBoard

Install Cycript

Cycript is a "programming language designed to blend the barrier between Objective-C and JavaScript" and is very useful when testing iOS apps. To install Cycript, first install the mobilesubstrate and libffi packages using Cydia. You’ll be prompted to reboot. Once the device has come back up, log into it using SSH. Download the latest Cycript package from http://www.cycript.org/debs/. Copy the package to your device and install it using dpkg:

dpkg -i cycript_0.9.461_iphoneos-arm.deb

Once the package is installed, you should now have cycript available in your path.

Install weak_classdump

To install weak_classdump SSH into the device and use wget:

wget --no-check-certificate https://raw.github.com/limneos/weak\_classdump/master/weak\_classdump.cy

Install gdb

gdb can be installed via Cydia. The latest version should work fine.

Install keychain-dumper

Copy keychain-dumper to the device. Just use scp to copy to the device. I usually have this in /var/tmp but you can put it wherever.

This should be everything you need to get started testing iOS applications. Hopefully this has been of some help. If people are interested I will try and write up some posts on how to go about testing an application and they basic usage of some of these tools.

#security #how to #iOS

Nice article by @sergicles on the various types of denial of service attack and the penetration testing considerations of each.

To sum it up:

Taking into consideration low complexity of execution, high impact and easy remediation - the Logical DoS attack is a realistic threat and warrants investment into this type if security testing.

#security

Great post by @agelastic.

Securing your organisation is not about finding and fixing EVERY vulnerability. It's not about NEVER being hacked. This is unrealistic.

Although the first step is to"admit that you cannot be in full control of your systems and networks" the key is really the second step:

2. Recognise that this is not a defeat Attackers are people too, and are driven by economic motives. If it is too hard and not worth the effort, they will not go after you. Unless they want to make a point, of course. Make breaking into your stuff not worth the effort. That is, ensure the required effort is hard enough that "the bad guys" will give up.

There is a tendency in the industry to belittle or disparage a company or developer after finding yet another SQL injection vulnerability and owning their app. I know I'm guilty of it on occasion but it's not the right attitude.

The truth is security is hard. No matter what a vendor tells you it's not something that is fixed with the latest and greatest $securty_technology. Security is a constant journey and far more nuanced than that. You will never fully secure your organisation. That's an unrealistic goal. As information security professionals we need to reinforce this and look for pragmatic ways that we can help organisations that will actually have an impact to that particular organisation.

As a side note - if you work in Infosec and don't follow Vitaly on Twitter you really should.

#security

Social Engineering-as-a-Service

Generally when a social engineering test or campaign is run it is conducted in a similar manner to a standard penetration test. There is a series of targets in the scope, then the security team performs the social engineering testing against the targets and a report is generated with the results of the test.

The techniques used in these engagements can vary depending on the organisation and the scope but invariably the end result is always the same - a recommendation to conduct security awareness training.

But is this the right approach? Typically security awareness training is not very effective at building resilience against these attacks. The training is generally unrelated to the roles of most employees in an organisation and is usually forgotten and oftentimes it contradicts general organisational culture and practices.

So how do we build resilience against these attacks? Dan Tentler proposes a novel approach in his presentation “Building Antibodies - The Phishing Program at Twitter” (video can be found here and Dan is presenting the talk at Breakpoint later this month).

The approach he proposes is to think about social engineering and phishing campaigns not as a test but as a vaccine. The base idea being that by exposing employees to a series of increasingly sophisticated social engineering attacks you build up organisational “antibodies” that can recognise and attack phishing threats.

The idea isn’t so far fetched. Why is it that reasonably tech savvy individuals can more easily detect phishing attacks while the less technically literate are constantly duped into sending money to Nigerian scammers?

Perhaps it’s because those tech savvy individuals have had far more exposure to the workings of the Internet and various phishing scams. Similar to how children who play in the mud, eat dirt have greater to exposure to the big bad world have better immune systems than those who have a more sheltered childhood.

Apparently the program Dan set up at Twitter has shown some really positive results. I’d suspect there are many companies out there that would see the same value in such a program but perhaps don’t have the capabilities or expertise to run something like this and I’d be curious to find out if there are any companies out there that run these sorts of programs for businesses. Kind of like a Social Engineering-as-a-Service. If not, I think there is definitely an opportunity for something like it.

#security

Trending Blogs

Recently Viewed Blogs

eightbit.io