In Air for iOS, I'm trying to find a way to mark when a possible Man in the Middle attack has occurred.
By default, anytime you try to connect to an SSL site that has an invalid certificate, you get the error:
"A secure connection with this site cannot be verified. Would you
still like to proceed?
The certificate you are viewing does not match the name of the site
you are trying to view."
I don't want to display this prompt, just disable network functions after that.
I started off trying to use a network monitor, but it gives the prompt as does running a separate URL request to test the connection.
I finally came across the "SecureSocketMonitor" which seems to do what I need it to do when running through the Flash environment, but once I compile into an Air for iOS application, it doesn't seem to function at all.
Does anyone know how I can detect an invalid SSL certificate without displaying that prompt?
Related
I am working on mobile pentests currently. At first, using my home network I was able to intercept traffic on burpsuite for both iOS and Android versions of “Test App”. Then the next day, I still am able to intercept traffic but the behaviour of this “Test App” for both iOS and Android seem like it has certificate pinning as I was just stuck on the pre-auth page and getting errors when trying to log in. Without proxy though I am still able to login OK and proceed with the app normally so I don’t think my home network got blacklisted? (For context, the binaries does not have any certificate pinning).
But when I tried to change my network to my mobile hotspot, I could intercept the traffic and app behaves normally again.
Anyone encountered the same previously? Any ideas on what could be causing this? Thanks
This does seem odd. I would wager one of three things is happening here:
You accidentally left "Intercept" on in Burp Suite Proxy. This holds the response in Burp Suite until you click Forward, which would cause behavior very similar to what you are describing here. I have done this more times than I am willing to admit.
There was a temporary outage in the application's API. Not unheard of, especially if this is an unreleased app.
There is some sort of issue on your home network, but this is unlikely. Maybe two devices have the same static IP address?
It's hard to say exactly what the issue might be based on the information you provided, but hopefully this was helpful, or at least gives you a place to start!
Sort of a newb to OWASP ZAP/proxying apps through it, so I'm tagging OWASP in this post, but hoping someone knows how to circumvent this issue here.
On Windows 10, OWASP ZAP 2.11.1, I've generated a new certificate and installed/trusted it to my iPhone 13 Pro Max. I've setup the proxy to run over port 8081 in OWASP, and turned on the routing on the phone. I'm seeing the traffic in OWASP which is cool, however the apps aren't actually "working". For example, if I load the Instagram app, I see the traffic/sites showing up in the left pane for Instagram, but on the phone, it doesn't refresh the feed and says there's no internet connection. Some other apps just hang on the first loading screen of the app, even though I'm seeing the traffic in OWASP.
My theory here is that the traffic isn't being routed BACK to the phone, but merely being intercepted before sending it out. Am I correct in assuming this? Or what else could be happening here as I'd like the apps to work properly while I'm proxying through ZAP.
Thanks!
UPDATE
After some digging, I'm thinking this is likely a result of "pinning", which I think can be (relatively easily) circumvented with Frida for Android apps, but maybe not so much with iOS apps. Any insights into that would be greatly appreciated!
I was getting the "no internet" message after following the steps above posted by Simon Bennets (https://www.zaproxy.org/faq/can-zap-be-used-to-test-mobile-apps/). Had to do extra step to trust manually installed certificate profiles as shown here: https://support.apple.com/en-us/HT204477.
I am trying to implement a splash page/ wifi landing page on my existing public wifi network, using the DNS method mentioned in Wiki, in which I host a custom DNS server, that will redirect ALL dns lookup to a local address where a web server is hosted, for all user before they click agree.
After the user clicked agree, my custom DNS server starts returning correct ip for the look up, thus, user will be able to get online.
note: We totally understand that this is in no way secure our network, and even putting our network at risk. But the goal here is to just to pop the landing page up in front of our users.
This approach actually works on Windows Phone (Windows 8 I tested) as splash page, and even on a computer when I try to open a random website, it redirects me to my page, and after I hit agree, I can get to the internet.
When I try it on iPhone/ Android, once I connect to the hotspot, the splash page/ wifi landing page appear as expected (because the device is trying to verify internet access by going to the set of pages) However, after I click agree, and allow internet access, both iPhone and Android splash screen will not go away. I have to force iphone to "use this wifi without network" to exit.
I wonder if there is a special (javascript?) method I can call in the page, or some package I need to send to the device? I noticed on iOS, if I click a link to the App Store, the splash page go away without disconnecting from the network, So, I guess I am missing something here.
For example, clicking the link to the iOS StackOverflow App on iOS device can be a workaround.
Had been googling around for a week now, nothing seems to came up.
by the way, I am building my custom dns server on node js, with the module dnsd.
=-=-=
=-=-=-=-= edit =-=-=-=-=-=
I also uploaded a demo of my code on GitHub:
https://github.com/kylelam/dnsd_wifi
To test it, run it in your local network (sudo node demo.js). Then, change your phone's dns to your machine's IP. Disconnect your phone from wifi and connect to it again. (on iOS, you might need to go into detail, and enable auto-login, and auto-join, or if you can't, just reboot.)
*note1: the server will need to run on port 53, and 80, so it need sudo.
*note2: please don't laugh at my code, I'm very new to this. But please do point out.
*note3: you will need to npm install these packages: os, express, dns, dnsd
ttl set to 0 might be the cause of the issue, try a different value like 5.
I tested Universal Links in iOS by turning on Airplane mode and saw that the correct application was opened (instead of a website)
This indicates some level of "caching" the apple-app-site-association.
I want to determine the extent to which this is cached, so I can determine
What UX edge cases are there (e.g. Offline for x days)
What security considerations are there (e.g. MITM / SSLStrip + .well-known/URL)
etc.
Ideally I would like to have details if additional logic is employed (conditional caching if HTTPS employed, DNSSec, etc)
The exact behavior here is (intentionally?) unclear from Apple. Here is my personal experience, gleaned partly from official documentation and partly from helping thousands of apps implement Universal Links at Branch.io.
The apple-app-site-association file is cached once when the app is first installed.
If this initial scrape fails, in almost all situations it will not be reattempted. The only exception to this is if the initial return is a 5xx error, in which case a limited number of retries may occur. This is not well-documented, and is not covered in Universal Links documentation at all. You can find a mention in the Shared Web Credentials docs.
The file is not checked at all when a Universal Link is opened. This is why you are able to get Universal Links behavior in airplane mode.
The file does not expire. Once it is cached, it sticks permanently for as long as the app is installed.
The file will be re-checked when installing an app update.
The file must be accessible via a valid SSL connection at either https://example.com/apple-app-site-association or https://example.com/.well-known/apple-app-site-association. If there are redirects of any kind, this will fail.
It is theoretically possible to MITM the request if you are able to install a new SSL certificate directly on the device in question. Charles Proxy for example uses this approach for debugging. I have never seen or heard of this being exploited, and the damage would be quite limited because the domain still has to be specified inside the app itself.
I found a way to get around the caching issue. The cache is bound to the domain name, so for every time you want iOS to request apple-app-site-association you can create a new subdomain, and configure iOS to use that subdomain as the universal link for your app.
Extremely hacky, but it is the only workaround that worked for me.
I am trying to use push notifications for OS < 7.X .
I downloaded the sample server / client code. I deployed the client code on my device and the low-level-sample code on the tomcat provided.
For the record , when i registered for push notifications here i registered using the BIS option. Now that i was actually given a blackberry i was informed it is using BES ( i dont think though this is the root of the problem that i am going to describe..).
On the device , in the sample application i put all the correct settings given from the email i received.
Both my pc which is running the tomcat server and my phone are connected to the same wifi.
I am trying from the device browser to connect to the server , eg https://196.84.32.112:8443/low-level-sample
and the browser opens the page normally , meaning that i am able to connect to my server from the mobile.
Now when i hit register from the device sample app ( i have tried both BIS/BES options on the settings ) , i always get the following error :
Request to register failed. Cause by java.io.IOException: Network operation[Subscribe] failed. Make sure that Content Provider URL is accessible.
In the log i get :
Opening URL: my server url appended with info like username/password/model/connection type etc
Content Provider network command [ Subscribe] failed , caused by could not connect to 196.84.32.112:8443
Command "register" failed with error: java.io.IOException: Network operation[Subscribe] failed. Make sure that Content Provider URL is accessible.
A thought is that i should register again for new push keys and use the BIS/BES option instead of only BIS , but here the problem seems to be no connectivity with the local server , not the RIM server. I already tried to register though and i am waiting for the mail with the new settings.
Also i am a bit confused with the BIS / BES option. I have no idea if my users will have BIS or BES enabled so what do i put in my code ?! In the sample application it asks me to select between BIS or BES but when the app is going to production and i need to programmatically make that choice what will i choose?! Or this choice is made only for the evaluation/development of the app and on production there is another server ?
I think all the right things have been said here, but I'm hoping we can consolidate some of the answers, and wrap this question up.
You haven't shared your code, which makes things more difficult, but many people use the RIM/BlackBerry provided PushDemo source, where a connection suffix is hardcoded in /pushdemo/com/rim/samples/device/push/PushUtils.java:
private static String getConnectionSuffix() {
return ";deviceside=false;ConnectionType=mds-public";
}
I'm also guessing this from having read your other question.
By doing this, you've hardcoded the BlackBerry transport type of BIBS. BlackBerry supports many different transports, like BES, BIS, BIBS, or WAP. The BIBS transport will send the request from your device, out to BlackBerry's servers, which are on the internet. (Note: this part is probably confusing to an iOS/Android developer, since those platforms don't provide Apple/Google network intermediaries to relay normal HTTP/S traffic)
Then, the request is relayed to your server, which is at:
196.84.32.112:8443
I'm pretty sure that TCP/IP endpoint is not available from the Internet (I can't reach it). So, that's why it fails for you.
You can take this URL
https://196.84.32.112:8443/low-level-sample
and paste it into your BlackBerry device's browser, and it will work. Your device is configured for BES, which uses your company's internal servers. Those internal servers can reach the 196.84.32.112:8443 endpoint, so it seems to work for you. But, that's because you haven't hardcoded the transport, as you have in the push code that uses getConnectionSuffix(). The device browser is smart enough to figure out a transport that works, and BES works to reach that intranet server.
Hopefully, that explains the confusing part.
Solutions
As others have said, a solution is to get your company's IT people to make IP address 196.84.32.112 and port 8443 accessible through their firewall. That would allow the BlackBerry servers to reach it successfully.
Another solution would be to change the PushUtils.java code to avoid the BIBS transport:
private static String getConnectionSuffix() {
return ";deviceside=false";
}
If you want really flexible code, then I'd suggest rewriting that PushUtils.java code, because it appears to use the pre-5.0 HTTP connection logic. ConnectionFactory in OS 5.0+ makes this easier, and more robust, when supporting multiple transports ...
To answer your question about supporting users with multiple transports, take a look at this blackberry.com example, specifically the MyConnectionFactory class. It allows you to select which transports your app allows, and which it tries first.
Ultimately, the decision to make your server public or not depends on how it's going to be used, and whether you'll have non-corporate internet clients trying to register with your corporate server.
Let me first explain the registration flow for BB Push Demo:
When you click on Register the device will
Inform your web application that the device wants to register. For this it will send the information about the device to your Web Application (the so called ContentProvider). You are expected to store that information in your database. This step happens in the ContentProviderProtocol.performCommand() method of the push demo.
Inform the BB Push Server that the device wants to register for receiving push notifications from your application. This happens in the BpasProtocol.register() method of the push sdk.
Step 1 is only necessary if you want to know who all are registered for push notifications (maybe if you want to send individual push notifications to each device and not broadcast the message to all registered users). In that case, you will probably need other information like that user's preferences etc for customizing the push anyway.
Now the error you are getting is from the step 1. For step 1 to succeed, your device should be able to connect to your web app which it is not able to.
To solve this problem, either you have to make your web app publicly accessible (and be ready to handle the load) or comment out the step 1 from the app by making ContentProviderProtocol.performCommand() return without doing anything.
PS: The webapp used in step 1 need not be same as your push initiator. The webapp is simply being used for tracking who all is registered for receiving the push and should ideally be located in the cloud on a distributed architecture if you expect a lot of users.