Monthly Archives: September 2020

Getting started with iOS testing

Jailbreak a device (At your own risk)

Disclaimer: I would never jailbreak a device that was going to carry my personal information. You should not either. It is absolutely at your own risk.

This blog post is about getting started with assessing iOS apps. I had not done this in a few years and so this is notes to bridge the past with modern which may be of use to you.

There is currently a stable root exploit called “checkra1n“. This works at the bootloader level and so long as you prevent your rooted handset from rebooting you will have a rooted handset. There is stable exploitation tools for Linux and now for Windows.

I use Windows as a host OS. I do this for many reasons but the simplest one is because Linux works better in a VM than windows does in my experience. I tried checkRa1n in a kali VM with the phone passed over USB directly to the VM. This was a dead end. The exploit process looked like it was working but it never completed, do not enter this cul-de-sac.

To get around that I could have tried the Windows exploit tools. But I selected to use “bootra1n“. This was a bootable USB Linux distro which included checkRa1n and it worked exactly as advertised.

Install the device via app store

  • Setup a test account without any of your real personal info.
  • Sign in to the app store, and then install your target app on the device.

There are other ways to install apps including “3uTools” (see section later). For me this did not work as my target app was not available in the app store they maintain. If your target is available for install then you will find an easier process where you don’t need to dump the IPA file as described in the next section.

Dump IPA file from handset

  • On Jailbroken Handset
    • Open Cydia and install “frida-server” as per this guide.
  • Inside a Kali VM (I used a VM, you can go barebones. Process did not work on Windows).
    • Install frida
pip install frida-tools
  • Inside Kali install “frida-ios-dump”
apt-get install libusbmuxd-tools
ssh -p 2222 root@localhost # leave yourself connected to this session
git clone https://github.com/AloneMonkey/frida-ios-dump.git
cd frida-ios-dump
pip install -r requirements.txt

Now all you need to do is run “dump.py” against your target as shown:

python3 dump.py <target_app_name>

To obtain the correct target app name use “frida-ps” as shown:

frida-ps -Uai

Getting MobSF The Quick Way

MobSF is an excellent tool for gathering some low hanging fruit. As a minimum I would advise throwing every IPA (and Android APK) through this for static analysis. It does a good job of finding strings which may be of use, as well as analysing permissions and other basics. This post is about getting you started and MobSF will be an excellent place to end this post.

Install docker as per this guide. Then after you have that up and running you can get access to MobSF using this:

docker pull opensecurity/mobile-security-framework-mobsf
docker run opensecurity/mobile-security-framework-mobsf

This will start an HTTP listener bound to 0.0.0.0 which is great. But you need to know what IP address Docker just gave you. First list your running containers:

docker ps

Then use docker inspect with a grep to get that for you:

docker inspect <container_id> | grep IPAddress

Fire up your web browser at http://YOUR_IP:8000/ you can now upload the IPA file and it will give you that static analysis juice.

3uTools

This is a beast which gets around having to install iTunes. A bit of software I have a ~15 year old past with which I frequently refer to as a “virus”. It is simply not possible for iTunes to be as shit as it is/was. Therefore, it must have been maliciously generated.

3uTools allowing you to dodge the virus that is iTunes

A lot (but not ALL) of apps from the app store are available for install using this. You will still need to supply legit app store creds to use that feature. If you can install using 3uTools then you get a super easy way to export the IPA file. But it only works on apps installed via 3uTools. In my case the app I needed to examine was in the app store, but not in the 3uTools equivalent.

Thats it from me, I am not going to rehash how to test an iOS app here as there are excellent resources explaining how to do that.

Your next steps would be to Google the heck out of these things:

Best of luck on your road to pwning iOS.

References

Pitfalls in Pentesting

In this post I am going to cover some pitfalls of Penetration Testing. It is kind of three rants stitched together. Loosely around the theme of how we generally interact with customers, as well as the reporting processes that I have seen over the last 15 years.

A person whose job it is to respond to penetration testing findings was asked this question:

  • What are the pain points you have experienced when responding to Penetration test findings?

This is what they said:

“…For my part, as an engineer that gets the fallout from these things I can tell you that I really hate that these scans report stuff that’s been fixed by back-porting by the suppliers. I’ve lost count of the number of times I’ve had to explain to SecOps, Managers and developers that the hundreds of “alerts” they have can be ignored because RedHat have already backported fixes not reflected in the reported version numbers. Time to get off one of my soap boxes!..”

— Anonymous fighter in the trenches

It is also worth noting that this was not a customer of ours.

I yelled “preach!”. Whoever this was I really love that they hit the nail on the head. I opened my most recent report where I had tackled that concern , I hope, adequately:

An except from a report

I hope that if the anonymous responder were to have seen my report. That they would at least see that I considered their plight, and that I have given them an easy out when responding to their manager. “Look, this guy even said it is possibly a false-positive”.

The target had a server banner which, if true, was vulnerable to several things. Unfortunately the OS was not listed in the banner (and was not otherwise 100% confirmed) so I could not prove or disprove the versions without either exploiting the issue, or being given more access. Had the banner said “RedHat” then I would most definitely have changed what I said. It would say there is a high potential that backporting was being used.

This set me off thinking again about how our industry often fails the customers we are paid to help.

If our industry has heroes they may or may not wear capes. But they almost definitely work on the blue side in my opinion. The brave souls tasked with the gargantuan task of interpreting penetration testing reports. From multiple consultants, from different vendors. The variability of output is enormous. These warriors have to find someway to make it work regardless of what thing has arrived as the deliverable.

I have seen Pentest companies who try to solve it in two ways:

  • Dictatorship – Based on one person’s vision you set a reporting standard.
    • You develop a rigid knowledge base of vulnerability write ups which tells everyone exactly how to report something. This includes fixed recommendations which must be provided.
    • You retrain every consultant in your team to meet that standard.
    • You yell at people during QA to remove any sense of individuality in reporting.
    • You fall out over CVSS risk ratings because “we need to risk this exactly the same way as the customer got an XSS which was 6.5 last week”.
    • Some Customers LOVE This. They don’t want any variability because the master spreadsheet they have with all vulns exists. They want the exact risk score for every instance of a vulnerability ever. They just like it neat.
    • The goal is to make every report as identical as possible across any customer and from any member of the team. Robotic Reporting.
  • Cheerful Anarchy – You set a baseline standard for reporting by providing a structure for the reporting and a style guide. Then you let folks have at it!
    • You accept that Pentesting is consultancy profession. Which is influenced by the experience of the consultant doing the work along with their understanding of the risk appetite for the customer.
    • You provide a basic knowledge base of vulnerability write ups which covers a consistent title, background, and baseline risk score. Then encourage the consultant to produce the remaining content just for that project.
    • You train your consultants to understand risk calculation and expect them to alter the baseline risk considering every instance they see.
    • The goal of this is to make every report tailored. Therefore inconsistencies will exist such as two consultants finding the same vulnerability with the same impact but providing different risk ratings.

Of the two I have always preferred cheerful anarchy. I know that some customers absolutely want a penetration test to deliver consistent results over time. It helps them sleep at night. I argue that a little anarchy might be good since the consultant should be free to express their opinions SO LONG AS THEY EXPLAIN THEM WELL ENOUGH.

In truth you need to essentially support both in 2020. Big accounts who want the consistency need to get it. Other customers who are perhaps in earlier stages of their security maturity processes should be given tailored findings in my opinion. They haven’t necessarily encountered an SQLi before, so you need to contextualise it a lot more. So I recommend being so flexible that you can be rigid… I suppose?

Places where a penetration tester needs to be super clear is when dealing with potential false-positives. If the only evidence you have is from a vulnerability scanner then you have not done a good job. I implore you to always find some other means of confirmation.

In situations where the vulnerability is raised only based on banners.. Then your flow is to:

  1. Find a working exploit. If you can, then try to exploit a docker container or VM with the same software first to verify the payload works well. Ask the customer if you can use the exploit. If you have done it in your lab first you can explain that it works well without a risk to stability. Otherwise you can warn them that it may trigger an outage. They can then make the decision themselves as it is their risk.
  2. If no exploit is available. If you can, then execute OS commands to verify the installed patch. In most cases you do not have this access. You can either document the finding with caveats (as my report did), or.. and I appreciate this is a revolutionary idea. You can ASK the customer to confirm the installed version themselves and provide a screenshot. In my case the time was not available to do so and I was forced into the caveat approach.

I know, I know. I suggested you speak to the customer! Worse still I say you should ask them to support you improving the quality of how you serve them. You should not forget that a Penetration Test is a consultation, and that you are on the customer’s team for the duration of the engagement.

They say you should never meet your heroes. But it has been going really well for me when I speak to them so far.

Hope that helps.

Encrypting files with openssl using a password

I needed to send an encrypted file to a user with a Mac. They were unable to install additional software on their machine, and I have no Mac to verify things on.

By default Mac’s roll with openssl installed (thanks Google), so the solution seemed to be to use that.

You can debate the encryption algorithm choice and substitute as appropriate. But the basic syntax for encryption and decryption using AES-256 is shown below:

Encrypt file with password

openssl enc -aes-256-cbc -iter 30 -salt -in report.pdf -out report.enc

Note: running this command will result in a prompt to enter the password, and confirmation.

Decrypt with password

openssl enc -aes-256-cbc -iter 30 -d -salt -in report.enc -out report-decrypted.pdf

Note: again this command will prompt for the password to be entered before extracting.

Warning; running with scissors

This is securing with a password. Go big or risk exposure here. Someone could always try brute force and you want to make sure that takes way way longer than the validity of the information you are protecting. I recommend 72,000 characters long as a minimum to be sure.

Now you have a key distribution problem though. How to get the password to the other person securely? You cannot email them the password since this is the same delivery mechanism for my scenario.

  • Generally WhatsApp (or other end to end encrypted chat client to a mobile phone) is good.
  • Phoning and saying a long password can be awkward but works (so long as they promise to eat the paper they write the password on immediately).
  • SMS is less secure but still verifies that the user is in possession of that person’s phone.

Hope that helps.