Swift and Security
Dzung Pham at Swift Summit San Francisco, 2016
My name is Dzung Pham and I am a security consultant at Cigital. Today I'm going to talk to you about Swift applications and security. This talk is going to cover, on a high level, security testing for Swift applications that can also translate into Objective-C applications, if you're interested in that.
Security in Swift applications
Swift is the new iOS programming language that came out in 2014, just two years ago. It has been our most favorite programming language for its very friendly syntax compared to our old friend Objective-C. Swift is type safe, which means that Swift applications are more resistant to memory manipulation attacks as well as buffer overflow.
In fact, all Swift applications are compiled with automatic reference counting by default, which means that Swift applications are more resistant to memory corruption. This year, Xcode introduced HTTP Secure Transport Protocol, or HSTS. With this configuration on by default for every Swift application the communication of your Swift app is going to go through the encrypted channel HTTPS, which is great news. I also want to briefly mention the implementation of Keychain as well as Touch ID. Keychain is essentially providing us a safe way to store sensitive information on your device and Touch ID is for local authentication and re-authentication in your applications.
If Swift applications are so great, then what am I here talking to you about then? Even though Swift and Xcode, together, provide a pretty great coverage, in terms of security, things can still happen. Vulnerabilities in Swift apps are not caused by the Swift language itself, but by how things are implemented. In order to understand more about that, I am going to go over some of the common vulnerabilities that are normally found in Swift applications.
This list is compiled by my own experience working with iOS as well as Swift applications in general, as well as personal research. Most of the applications have the client side and the server side. The client side is, essentially, everything on your device. It is the application on your iOS device of your choice. Could be iPhone, iPad, iPod Touch, whatever device you want to do. The server side is the computer operations that your application is running on. Most of the Swift applications will have both of these components unless your application does not make any call to the server side. An example of that would be a customized emoji keyboard app that only runs on the device. In that case, your application does not make any call to the server side and so you will only have the client side. Most of the Swift applications out there have both of these components, so in terms of vulnerabilities, you will want to look at both the client side and the server side to see what kind of vulnerabilities that your application might have.
Client side (device)
Let's talk about the client side first. The most common vulnerabilities on the client side are insecure data storage and data leakage. Sensitive information, such as credential, password, or session ID could be stored on the device unsafely. Some of the locations that you can find this information are the file systems, caches, database files, or even the application's memory. This sensitive information can also be found in the log of the device or sometimes they are hard coded so they can be seen when you reverse engineer the binary of the application.
The second most common vulnerability that we found in Swift applications is like a binary protection. In here, I want to mention jailbreak detection and certificate pinning. Jailbreak detection is a mechanism that prevents your application from running on a jail broken device, which then prevents an attacker from accessing the file system of your device. Certificate pinning is essentially to prevent someone from setting up a proxy between the client side and the server side. When you are able to set up a proxy in your application, you can listen to traffic and potentially modify the communications from your client side. This can cause some damage and harm, especially if your application is having some weak server side controls that can be bypassed. In that way, it is bad.
That's the client side. Now, talking about the server side, in here we have broken cryptography, server side controls bypass, authorization and authentication issues. Most of these vulnerabilities on the server side, if you are familiar with web applications, these are the vulnerabilities that are present in web applications. They are very common in the web services for a Swift application, also.
In here I have OWASP Mobile Top 10. This is where you can find a more comprehensive and detailed list of the ten most common vulnerabilities that are present in mobile applications in general. That would cover all mobile application platforms out there: iOS, Android, Windows, whatever. I found that this list is very true to iOS as well as Swift applications in general.
How to find security vulnerabilities
Now that we know what kind of vulnerabilities you might find in your application, let's talk about how we can find them. In here, I have a list of toolings that I use every day in my job. Of course, if you go out there, there are a lot more tools that you can use and you can even write tools for yourself. These are the tools that are most utilized. I will also be talking about two types of toolings, static toolings and dynamic toolings.
First, static toolings, we have SSL Scanner. Some of the common SSL Scanners are sslscan, sslyze or ssllabs. With SSL Scanner, you can essentially find out what kind of cyber suite and search certificates that are supported by your application. Even if your application is using HSTS, Xcode allows some exception to HSTS, just in case you don't want to use TLS 1.2 or if you want to have some exception in your application. Then you should scan your domain anyway. SSL Scanner are non intrusive, so I would recommend you scan your domain anyway.
The next tool I want to talk about is the proxy. A proxy is, essentially, a tool that provide you with the capability to see the traffics between your device and the server side. In here, I list my favorite proxy tool, which is Burp Suite, which works really, really well with mobile applications. Of course, there are other kind of tools for proxy that you can use, like Fiddler or Zap, that you can also use. It's completely up to you. I list Burp here because I really like it.
The next type of tool is for reverse engineering. In here, we have IDA Pro, Hopper, and idb. These tools essentially take into the tool your application's binary and then give to you back the code or bytecode or disassembled code, depending on what tool that you are using. With the output from the reverse engineering tools, you can gain a very great insight into how your Swift application is actually operated without even having access to source code. That is why we have the saying, "No source code? No problem," in mobile application security testing. We don't really need to see the source code, we just reverse engineer it.
Then, you have the tools that you can use to explore files on your device like iFile or openSSH. That's the static toolings that I have.
Moving on, the next type of toolings I want to talk about is dynamic toolings. In here, I have Cycript. This is actually pronounced like “Script”. Cycript is the dynamic penetration testing tool that you can hook into your Swift application in runtime. A really great use of Cycript, that I normally use, is to check whether your application wiped out sensitive information from the application's memory properly or not. I use that for Swift a lot. Another functionality of Cycript that a lot of you might know of is to hook or to write tweaks into the application, which work really well with Objective-C. However, since Cycript is built on Cydia Substrate, which has direct access to Objective-C and Java's library and not Swift's library for now, Swift applications are a little more resistant to hooking attacks by Cycript.
Last but not least, I want to talk about idb, which is a one stop shop tool for mobile penetration testing, especially iOS pen testing. idb gives you the benefits of both static and dynamic toolings in a way that it gives you back code that you can use to gain insight into how your application works. It can also help you with fuzzing some of the methods that you want to hook into your application. Of course, this does not work well with Swift. It works on and off. One of the functionality that I really, really like in idb is the pasteboard view. A lot of the time, developers allow sensitive information to be copied and pasted with the pasteboard, whether general pasteboard or name pasteboard. With idb, you can actually see what are being copied onto the general pasteboard and the name pasteboard, if you know the name of the pasteboard. Pasteboard are a great place to find out what kind of information that might be leaked there. That's dynamic toolings.
At the end of the day, I think Swift is really cool and it is built with security in mind, but no programming language or framework are completely immune to attacks. Today we talked about Swift applications- what are great in Swift, what are the common vulnerabilities that you can find in Swift applications as well as how you can find the vulnerabilities with some of the tooling. I hope that the next time you are developing a Swift application, you have security in mind. Thank you very much for your time.