Dan Shugrue and Cole Herzog, Digital.ai | DevOps Connect 2022

ai. ai. Hey guys excited to be here.

We're here today to tell you how and why to build a blueprint for secure software. So if you're here you already do care, but in case you're just virtually passing by you should stop what you're doing and pay attention for three reasons. First whether you know it or not, whether you make blue jeans hamburgers or power grids, your organization makes stuff by making software for your employees and probably make software available to your customers.

You are in effect a software Organization no matter what you do and the software you make is out there in the wild. Second not only are you a software org? Your org is probably making more applications whether web-based desktop or most likely mobile and they ever have before.

And third applications were once again in 2021 the top cause of external breaches. I say all this because we've known that traditional bolt-on or perimeter security is not enough and we've known that with greater and clear greater Clarity for years. We've moved on from building bigger walls to keep the bad guys out.

That kind of thinking began to change when John kinderback popularized the term zero trust in 2010. Security practitioners and increasingly application owners are realizing that the apps whether they're mobile web or desktop based. Contain not just vulnerabilities that can be sust out with SAS tools applications have by definition working examples of how to bypass traditional security infrastructure.

They have to contain working examples or else they simply wouldn't work. For instance, if your favorite retail store app can't get past the firewall. They've put up you wouldn't be able to buy a new pair of shoes.

As a result the biggest banks the biggest gaming companies the biggest retail companies and the biggest media companies in the world are using a combination of anti-tan brain and obfuscation techniques to build security into their applications to prevent the working examples contained in those apps from being exploited by attackers. So threat actors know they can get their hands on an app. They can steal that working example and use it to access back-end systems personally identifiable information IP or the crown jewels of their victims and they can get their hands on an app the same way you or I can through religious stores like the ones Apple and Google provide us with Once they get their hands on an app, they run the app.

Um, or they've reverse engineer it as cool as Cole will soon demonstrate. A reverse engineered app leads to problems that are detailed in this slide loss of Ip loss of customers regulatory fines. Thus our customers are looking for ways to build secure software that addresses each of these challenges.

So how can you protect the apps that you plan to put out into the wild? You build software securely. And by that I don't mean that you send your developers back to college to learn how to code securely.

The problem is that there isn't a CS program in the country that includes cybersecurity in their graduation requirements. So while we haven't given up on the Hope or the dream of developers coding securely, we do have a means to provide secure apps today and we secure your apps in three ways. The next three slides will show you how we protect we Monitor and we react first we protect by shifting security left specifically we add protections at compile.

ai agility analytics release testing or deploy customer. ai is a One-Stop shop for optimizing your entire cicd pipeline. You can configure the protections yourself.

You can have us build protections for you, or you can use an auto config file to build Baseline protections into your apps. Automatically. You can also apply the full Suite of protections on premises or have us apply protections for you in the cloud.

In addition, we provide key and data protection through white box cryptography doesn't ensuring that your Communications are secure even in the unlikely event that your app is cracked. Now second we monitor. And by that, I mean we provide a standalone dashboard that shows which protections or guards have been activated.

We also show where the adversarial action is taking place the operating system on which the action is taking place as well as a host of other details that are vital for remediation or reaction to take place. If desired we can integrate our reports with your existing Sim soar or business intelligence tool of choice so that you're not stuck with yet another dashboard in your security operations center. third and finally we react so how do we provide you with the means to automatically respond to threats in real time with rasp?

or runtime application self protection for example, if a certain tamper action is detected you could program your app to automatically prompt the user to authenticate using two-factor off. You could also automatically add reactions that were would alter features on the app. For example, a certain sports game manufacturer that we worked for or with changed the gravity setting to zero when tampers were detected which made the players simply float off the field.

Finally you can add reactions that will simply shut down any app that has been tampered with effectively making that working example that your app contains unavailable the threat actor. All right with that let me pass the mic to Coal. We'll show us an example of how threat actors work and what types of tamper actions we detect and trigger on.

Thanks, Dan. That all sounds pretty sus so let's hop right into an example. This is going to be pretty simplified and probably nothing new to anybody here, but we'll run through it real quick.

This should demo a pretty viable attack vector and we can show how stray encryption and obfuscation make it a whole lot harder to attack. Entering the correct username in this sample banking app and entering the correct password lets you log in to your balance transfer money banking stuff. I I don't Bank stuff.

I don't know but money stuff. So if the password is incorrect. The app blocks access to the account.

It's a trivialized example. Like I just brought up. It's meant to illustrate a point even adding things like API tokens or other minor security measures.

It's not going to make it that much harder to attack just another minor hurdle. getting useful data out of another protected application is Really easy? It's so easy.

I could I could teach my daughter how to do it. A daughter is one she doesn't walk yet. I know what you're thinking that.

By one they should probably be walking but like I don't we don't have the time to get into it. So if we could just keep on with the example every grade. This is a screen capture of the application after sending it through a decompiler.

In this case, we use Hopper but free tools like you draw are just as if not more powerful. We can download nap off the App Store like Dan mentioned onto a jailbroken device and we can rip the IPA off in like five minutes using Freda. Everyone here.

Probably only knows about it, but you can Google free to code share. There's a script for everything. Like I only really like crispy bacon.

Right? So like if my oven was like or my stove was an Internet of Things stove. probably use free to get crispy bacon and so everybody compiler has some form of search built into it.

So we'll go around searching this decompile or flight password off authentication until we find something in a couple minutes. We're at the button action for confirming the password the little submit button on the login screen that's gonna run this code, you know, like the login button. So if we follow a little further into this into the assembly that runs when the button actually gets pressed we can see a bunch of calls that end in a test bit and Branch if zero.

I'm not again a banking expert but I have no idea what we could possibly be testing at the end of the password check function. If we continue following the control flow, we can see two possible branches from the password check code. The branch on the right is the invalid password Branch.

Thankfully this app doesn't have any strain encryption all so we can see right there that we've got it right. This is where we're gonna print out the enveloped password string and stuff. And the other block shows the code executed on the contrary when the password is, correct.

Between you me and everyone else listening password is I love Chipotle. I do really like chipotle steak burrito. It's my go-to.

So if we look at the machine code in HEX for this we can pretty easily pull out the TBC sequence 54010036. io or check them inhidro, which I'll show you all the out codes. In this case if we change the 36 to a 37 that'll swap the tbz to its sister called tbnz test a bit and Branch if non-zero.

The short of this is newly bought it modified binary is going to accept any login for any account as long as we don't enter the correct password. There's only one correct password and there's like an infinite number of incorrect passwords not like really infinite right? Because like if it accepts like 255 characters or something like there's a lot there's a lot of passwords.

It's like you grab a napkin and a pen or something jot down some math. I it's pretty likely you're gonna log in and if you don't log in on the first try you're like guaranteed on the second try it's pretty good odds. So after swapping just one bit in the app, we can successfully log into the account as long as we enter the incorrect password the text like these genuinely happen.

and break into an app isn't something that requires like years of training or practice takes an internet connection and a couple of hours in my daughter's case. You don't actually have to be able to walk which is a plus for her. So we know from Forester and other.

Analysts that applications are the most common cause of external breaches. If we look at the tools techniques and procedures of attackers more often than not the first thing that they use for white hats and black hats is freedom. Like we mentioned previously Frieda does anything and everything in many cases it can help someone get a new credit card.

Well, I guess it's someone else's old old credit card, but it's this person's new credit card. A solid protection to defend against Frida and other tools is kind of like an onion. It's it's got layers attackers have to defeat Dynamic instrumentation detection before they can attach the app process with freedom.

Then they'll have to defeat the hook detection and Swizzle detection guards before they can hook or Swizzle with freedom. And I'll have to defeat the checksum guards before they can alter the binary. On top of that all the guards have guards protecting those cards to make them more difficult to remove.

It's in addition to custom offication and strain encryption making static analysis incredibly painful on top of that the protection changes every single release. So what attackers learned from the last version of your app doesn't really help them for the next version. Honestly, I'm kind of beat just talking about it.

So I'm gonna tap out and I think Dan's gonna take on the rest. Thank you Cole. So how do we suggest that you obfuscate your code and build detection of tools such as Frida into your apps.

One way you can build some basic obfuscations of say JavaScript into your software development lifecycle is through the use of Open Source tools. There's open source out there that will prevent the more obvious examples of reverse engineering by for example, renaming strings such as password. So that attackers can't reverse engineer your app as easily as coal.

Just color for the show us. You might want to start there. If you're protecting an app that has access to pii to money or IP.

You'll probably want to take a few more steps to obfuscate your code. For example, you may want to obfuscate external strains modules and even obfuscate the protections or quote, you know guard the guards through a guard Network. The guard Network.

That's so exhausted. Nicole had to tap out just talking about it. Imagine if you had to actually crack that kind of protection you'd likely be even more exhausted than coal is now by the way cool if you need some water, please don't forget to hydrate.

ai is one of them. ai also gives the ability to add obfuscations on top of obfuscations on top of obfuscations. all of which monitor each other as well as we give you Andy Taylor mechanisms to detect when your app is run in an unsafe environment such as a jailbroken device or freedom.

We do this by providing you the means to write a protection blueprint. And depending on the type of app you're protecting you'll write your blueprint in Java XML or C++. And depending on the type or amount of help you want or need will provide the documentation necessary for you to write the blueprint will help you.

We could actually write the blueprint for you completely. or we could apply the protections themselves for you. so once you have the blueprint, you can use a simple toggle to change the protections completely for each successive release.

Meaning that each release will force adversaries to start their hard work all over again and nobody not even a determined threat actor wants to do that. Especially when there are literally hundreds of thousands of other apps that they can tamper with that likely don't have protection techniques built in. And finally, how does the protection blueprint work?

It's simply inserted with your xcr archive in the case of iOS or your compiled app, and any other case? Along with the blueprints into our proprietary engine to Output your protection app. It's easy.

Okay, so if our protections are so great and so easy to implement why haven't you heard of us? Well, one reason is that we have a new name as of two years ago. And for two years have been in a pandemic.

We were in our San a company with 20 years of experience protecting some of the most famous gaming and banking apps on the market. Over the years we saw a few different hacking techniques and learned a few defensive measures on how to stop them. ai app security and we serve hundreds of global 2000 customers including four of the top 10 game makers in the world and for the top 10 banks in the world.

We're also protecting the streaming content of two of the largest global Media or streaming companies. And we protect the applications at one of the largest Automotive companies in the world and at some of the largest medical device makers in the world in short companies with the most precious valuable important and attacked apps in the world trust us to protect their applications. So thank you and contact us to schedule a meeting or review your application security.

over and out