The Man In The Disk

Share if the site was helpful

The Man In The Disk

If you’ve ever taken an introductory class on cyber security (or if you’ve explored the topic on your own), then you’re likely familiar with the term MITM.  Man-In-The-Middle attacks are security breaches where a 3rd party butts their way in-between two parties attempting to communicate.  Obviously, this is not an ideal situation for either party, and a new variation of MITM is taking Android users by storm.

MITD

Man-In-The-Disk (MITD) is the name that’s been flying around the past few days.  But before we get into its details, let’s discuss a little more of what MITM attacks entail.  A MITM attack is when an unknown party inserts itself between the two trying to communicate.  When this is done that malicious party is able to spy on the conversation happening.  Even worse they might altar what is being sent.

As an example let’s picture an everyday conversation between two friends.  Person 1 and 2 are talking to one another about their plans for tonight.  And let’s say person 3 is bitter they didn’t get invited.  Person 1 might send 2 a message online asking “Want to meet up at 8?”, but 3 intercepts it, changes it, and then forwards the newly modified message to 2.  Now when 2 opens the message it instead says “On second thought there are cooler people I’d rather spend my time with”.  (A riveting example, right?)

The idea is simply that a 3rd party can both invade and modify conversations between clients and servers.  And a lot of the time the invasion can be a lot more critical than hurt feelings.  MITM attacks can be avoided by taking proper precautions and such as certificate pinning.  But that deserves a whole post of its own.

So How Does It Happen?

MITD attacks are a specific type of MITM that takes advantage of careless storage on users phones.  MITD attacks can allow 3rd party users to access information that is stored on an android device’s external storage.  This is something that many apps don’t use, but researchers at Check Point recently found that many app developers (including Google itself) are not following the recommended security precautions for avoiding this vulnerability.

There are a couple different methods for storing information in Android apps.  Android’s developer website has a good page laying out the differences between them.  If you want to go deeper into when using each is appropriate PhonLab covers this in its Android Development Course.   For the most part Android security is very sound due to sandboxing.  This is the idea that each app silo’s its information and only makes it available to others if either the user allows it or if both apps are on board for sharing.

External Storage

External storage is essentially a part of the device’s storage card that is shared by all applications. Google suggests that developers should add extra validation if apps utilize this storage functionality.  And unfortunately it seems that a lot of apps currently aren’t doing this.  Due to prioritization of external storage, data coming in to the phone may be subject to MITM attacks before it even reaches the app meant to use it.

Ironically Google was not following this advice either.  Since the report came out they’ve addressed the places where they were falling short, but it seems many other apps have made the same mistake and will be named after they correct their issues.

In conclusion, there is a security scare going around for android apps, but don’t overhype it.  If developers take the proper precautions to prevent MITM attacks (something Google explains easily how to do on their site) then this danger fades away.  Security is an ever-changing field, but this breach is one that can be easily avoided if developers do their due diligence.

 

Improved Security Or Less Freedom? APK Updates

Share if the site was helpful

Improved Security Or Less Freedom? APK Updates

Earlier this week a small change rolled out to the Google Play Store.  It’s one that you likely won’t even notice, but for those who have it’s tough to decide whether the shift is good or bad.  What change?  Just a small string of metadata for apps.

Google is adding a security string of metadata to all Android APKs (the file format android apps are stored in).  This string will come along with the usual app and be used to verify that apps are distributed through the Play Store or another approved channel.

But why?

The reasoning is (of course) for security purposes.  Users will be able to verify that the apps their downloading aren’t malicious apps seeking to wreak havoc on your system.  There are plenty of apps that have posed as secure looking every-day apps when in reality they were doing other things under the hood (such as mining bitcoin).  This new metadata will supposedly help catch apps like this and ensure that any apps users are downloading are coming from a safe place.

We’ve talked before about how android apps are pretty secure through their information silos.  Apps must use a content provider/resolver to access information from one another, and in order to get access to your serious information (contacts, messages, pictures) apps are required to request permissions that must be explicitly granted by the phone’s owner.  That being said it’s still not a good idea to go around downloading every app you can just for the heck of it.  Security should not encourage reckless behavior.

So what’s the issue?

So why the controversy?  If this new string of data will help keep our phones more secure why could people be opposed to it?  Well the new string is essentially DRM (Digital Rights Management).  As with media services, there’s potential for companies to abuse DRM to choose how and when you use their product.

Let’s say for example you download an app and like it how it is.  A new update comes out and you hear horrendous things about it like it makes an ad pop up every 5 seconds (a terrible marketing strategy).  Naturally you would try to hold off on updating to this new version as long as possible.  Well with DRM it might be difficult/impossible to tinker with the app to remove ads, and a developer could potentially force you to update to the new version by altering the metadata.  It’s a win for mobile app security, but it also invites misuse.

It’s not easy to say if this is a big deal or simply a step in the right direction for security, but it also hasn’t been in the limelight for long.  What are your thoughts on this change to coming apps?  Let us know in the comments below!

 

 

Keeping Your Keys Safe

Share if the site was helpful

Keeping Your Keys Safe

At some point in your app development career, you’ll create an app that has secrets.  By this I mean there will be keys inside that you want to keep secure from prying eyes.  If someone else gets a hold of your private info, the results could be disastrous (or expensive).

Let’s say your app uses Amazon Web Services and your monthly bill runs about $350 a month. That’s fine because you’re making the money back through app usage.  That is, until a 3rd party gets a hold of your secret key and decides to use it for their own purposes.  Then when your next bill comes due you find that you’re being charged for $50,000.

Not an exaggeration.  This exact scenario actually happened.  So the lesson is painful but memorable: secrets should be kept secret!  Let’s use this blog to talk about a couple ways people tend to store their keys and what you should avoid.

Avoid pushing keys to github:

I’ll start with what may sound obvious.  That sight that you put all of your code onto so that people can publicly view it?  Yeah, don’t put your secret keys up there.  This sounds obvious, but recent studies have shown thousands upon thousands of keys are available on public git repositories.  It’s possible your using a free service and don’t care, but if you’re being charge even a dollar for the service you’re using, keep it close to your heart.

Storing keys as basic Strings:

DON’T DO THIS!  Storing a key as a simple string is just asking for trouble.  There a couple issues behind this, but first and foremost is that it’s incredibly easy to access.  If you read our primer on reverse engineering apps then you know that it’s possible for 3rd parties to decompile your app and look at its code in its (almost) original form.  Storing a key as a string means the hacker just has to glance over your code and look for something that looks like a key.  Then it’s theirs and they can do what they want until you change it. 

Defining keys in build.gradle:

This is better than storing your keys as Strings in any old file, but the end result is unfortunately similar.  A lot of people put their keys in build.gradle in such a way that it’s created in the BuildConfig file of your app.  The bright side is your gradle file isn’t decompiled along with the rest of your app, so secrets are safe in there.  The downside?  Well, that BuildConfig class they were just created in isn’t as secure.  Again, our Strings are exposed in a very simple to access way.

Securing keys with Android NDK:

Let me take a second here to say something important: There is no such thing as absolute security.  If you’re going to have a secret in your app, all you can truly do is make it incredibly difficult to find.  Take the proper precautions to keep things safe, and a hacker will have to decide if it’s worth the time/energy to get to whatever is hidden.

With that said, the Android NDK (Native Development Kit) can help us use C and C++ code with Android.  Why would we want to do this?  Well for starters NDK libraries can’t be decompiled, so the information inside is a lot harder to find.  There are ways to access this code all the same, but we won’t go into them here.  It’s not perfect, but this will throw quite a few entry level hackers off your tail.

Make your code complicated:

This one again goes to what I said earlier about complete security.  It won’t happen, but you can make a hacker’s life hell by making your keys as hard to read as possible.  Let’s take a very basic example:  If your key was 123456, instead of storing that, you could make it the sum of the strings “12”, “34”, and “56”.  How you can break this up depends on how creative you can get, but there really isn’t a limit.  It just means more work for you both upfront and down the road to ensure you understand everything your code is doing.

Keeping keys safe is crucial for a large apps success, so you need to take precautions to avoid disaster.  If you have any suggestions for great ways to hide Strings inside your app let us know in the comments below!

en English
X