What is Reddit's opinion of
mitmproxy?
From 3.5 billion Reddit comments
➔ mitmproxy website
By popularity on Reddit, this Service is:
78 reviews of this app found across Reddit:
How are you with python?
Wouldn’t take much effort to find anything with a header of “content-type: video/mp4” or whatever it is we’re talking about here, and have python stash the response body somewhere. I’ve used this method for saving all kinds of stubborn shit. All the JavaScript trickery in the world isn’t gonna stop this.
Automate requests through the proxy with selenium, maybe?
I have Windows 10 Enterprise installed on a machine earlier today. Even with telemetry set to Full, the lights on my switch don't blink when I double-click on an image in Explorer.
I also set Windows to proxy HTTP/HTTPS to mitmproxy running on another computer, and I get no requests when opening images.
Independently of that, with telemetry fully disabled I still get some disappointing requests to bing.com and live.com when using the operating system. I'm not even logged into a Microsoft account.
The sweet spot of this seems to be debugging the SSL configuration of your server. For everything else, I feel there are more convenient ways.
If you're just interested in the communication contents, just open chrome://net-internals/#events (or the devtools for a high level view). Works without any installation whatsoever, also on the stable versions. For actual debugging on the protocol level, I'd go for mitmproxy, which offers client/server replay etc. (I'm affiliated with the project - Burp, Fiddler, Charles, ZAP, ... would be great alternatives, so it's not about that).
Honestly? vim and grep. A couple quick greps on an unfamiliar codebase usually gives me a good idea of how "smelly" it is security-wise, pull me out a list of http routes so I can see what looks interesting, etc.
As far as infosec-specific tools, maybe mitmproxy? It gives you the ability to replay HTTP requests with slight modifications. I think Firefox allows editing a request before resending in its network inspector but it didn't handle multipart encoded forms very well last time I used it. mitmproxy is also nicer because you can also write plugins to do things like automatically strip CSRF tokens out of proxied requests and replay them so you can quickly verify that all endpoints correctly mitigate CSRF.
Self-signed certs in general provide no security. If your client blindly accepts a self-signed cert, an attacker can trivially MITM the traffic [1] and record/alter any packets in either direction. It's no better than HTTP.
You /can/ securely use your own certs if you control the trusted certificate store on the client. That's generally not the case though.
Look into StartSSL and Let's Encrypt for no-cost certificates.
This is wrong. Check out
https://mitmproxy.org/doc/ssl.html
It allows you to sniff TLS/SSL. You simply need to create a self-signed certificate for the API's domain name, and then add that certificate to Android's certificate chain (a very common/easy process). The app will then trust mitmproxy which decrypts the connection for you in real-time (while proxying onwards to the real server)
Almost certainly. mitmproxy does this. It will generate a new cert that you need to install on your device as trusted.
However, if an app is verifying the certificate itself against a list of known certain they provide, it could fail. Basically HSTS cert pinning. After all, it was designed to prevent MITM attacks.
No, the data is encrypted through TLS and both wireshark and tcp dump don't actively decrypt it.
To decrypt the data, you will need to get Niantic's TLS private key (highly unlikely to ever happen) or mitm the connection at runtime with a certificate you have the private key to. Try <code>mitmproxy</code>, it makes these things easy to do.
/u/larrysalibra, do you know about mitmproxy? It makes intercepting internet traffic (even HTTPS) much easier than sshing your router.
What's interesting to note here is not how much data Tantan is sending back to their servers, but that they're doing it without SSL. If you monitor Tinder traffic, you'll notice largely the same personal details (location, match data, distance, etc.) being transmitted – albeit via HTTPS.
There are a couple ways to do it. First is to use something like Wireshark or mitmproxy to read the network requests the app is making.
Another option is to decompile the apps. This will let them view the source code, which will let them see where it's making network connections
Finally, you can use debugging tools on a physical device to see what's going on.
You can interactively view requests, and create replacement filters on them. You can also pass all options by cli arguments.
It has a kinda funky UI, but you get used to it pretty quick.
- For functional testing (like testing user flows), mitmproxy/mitmdump is a really great tool.
- For "pedal-to-the-metal" stress tests, check out Apache/AB.
- For pre-built stress tests (like generic unit tests), Apache/JMeter is pretty powerful.
I think mitmdump is the best fit for your use case. Only thing to watch out for is that mitmproxy is a bit of a resource hog, so you might need some port-mirror trickery to avoid introducing performance-related bugs on production.
The general idea is pretty simple, but there is some trickery involved in practice (you can see an open source implementation here for example). As you noticed, the proxy has its own root CA. The general idea is that the proxy uses this CA to generate certificates for any sites you access, on the fly (it probably caches the generated certificates, for efficiency). You can read a more detailed explanation about the whole process here -- look for the sections "Explicit HTTPS" and "Transparent HTTPS" depending on whether Chrome is set up to use the proxy ("Explicit HTTPS") or not ("Transparent HTTPS").
Chrome doesn't know the CA used by the proxy, so even though the certificate it receives for "reddit.com" has a valid signature from this CA, it doesn't consider the connection secure. If you really wanted, you could change that by adding that CA to the list of root CAs trusted by Chrome. You'd have to export the root CA to a file and then import it as a trusted CA by going here:
chrome://settings/search#ssland clicking "Manage Certificates" (this opens the right tool to manage the certificates regardless of the OS Chrome is running). I don't really recommend doing this, though.
Short of traffic monitoring/MITM SSL proxies (mitmproxy for example) to see if proper encryption is used (or if encryption is used at all), you're left with a few choices:
- Trusting the company and their privacy policies (if they even have one). I don't personally recommend this.
- Sticking to open source software (and verifying the code/compiling it yourself, or, again, trusting a third party to have done that; examples: Hacker's Keyboard and the AOSP keyboard).
- Using keyboards that do not require an Internet connection (to list some: Hacker's Keyboard, NextApp Keyboard, Multiling O Keyboard).
- Using a firewall to block Internet access to the keyboard after you've installed the language pack, if applicable.
It's a trade-off between security and convenience.
You can packet-sniff your own computer to watch the game communicate with the server, and begin to reverse-engineer the undocumented API by watching the interaction. Assuming the connection is encrypted (and why wouldn't it be, in this day and age), you'll probably have to run something like mitmproxy to decrypt the connection. If they're using certificate pinning, or connect using something other than HTTPS, you may have to reverse engineer the application directly, reading the strings or stepping through instructions to see what calls it makes. Doable, but complicated and tedious.
Used: mitmproxy/Burp Suite to understand how the api works, and jadx to try to get readable decompiled source code once I knew what to look for and general idea of what to expect/how it works.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
I had a blast doing this!
- Reverse engineer the Animal Crossing API with mitmproxy and find out the endpoints for reactions
- Set up a Python server to fetch the authentication cookies to access the API
- Use Google's Teachable Machine to capture, train my gestures, and export to a Tensorflow model
- Pour the model into Tensorflow to predict what gesture I am doing and call the corresponding reaction API on my Python server
Nice list!
I want to give a shout-out to mitmproxy as an open-source alternative to Charles. It has a command-line interface as well as a web interface. It's also scriptable (in Python).
It's come a long way since I first started using it. It's much simpler to get up and running now.
если у сяоми можно устанавливать руками самоподписанные сертификаты (или всовывать руками CA, а потом сертификат), и если можно указать прокси -- то прошивать роутер не обязательно.
На свободную тачку ставится mitmproxy, он генерит сертификат который надо установить в исследуемую систему. Далее в исследуемой системе надо указать, что тачка с mitmproxy это прокси и ходить надо через него.
Тул фактически делает tcpdump, но цимес в том что TLS расшифровывается. В принципе кажется с некоторой гимнастикой Wireshark тоже может залезть внутрь TLS, но с mitmproxy как-то проще в настройках показалось. Это работает, я так успешно проснифал закрытое api одного телефонного приложения и смог написать альтернативный клиент.
https://mitmproxy.org/#mitmdump would probably be a good fit. You can programmically strip out data from http requests using its python api.
I've used mitmproxy in the past with messing around with malware. It works pretty good
As /u/0x414142424242 pointed out, OWASP ZAP is basically an open source alternative with similar core functionality. However, I think mitmproxy is also worth a look -- it has a command line and web interface and is very extensible in Python.
> scraping off an app is different to HTML scraping
for sure, yes, but in my experience it can also be much, much easier because it is highly unlikely that your target will send down presentation stuff (i.e. HTML) to the app -- they will send down only the data, which is what you wanted to begin with.
That said, there are different hurdles to overcome when going after app data: authentication is almost surely involved, there could be rate limiting per login, and they are (strangely) able to change the format or data sent down almost arbitrarily, which isn't typically true for web targets.
> I intend to use an extension to run the android app
I'm not certain what that means, but I guess so long as you know and are comfortable with it, then try it out. My experience has been a mixture of man in the middle attacks, and decompilation of the app to learn the URLs and any auth schemes. But, just like going after a web target, almost every job differs.
I don't at all mean to dissuade you from using the app-centric approach, but also be sure to look at any XHRs on their current website, as it may very well be sending down the JSON you want but without all the authentication or other tidbits you may can avoid. It can be the best of both worlds: just the data, thankyouverymuch, but without all the energy expended to learn those URLs and responses.
> Je suis 100% d'accord avec toi, mais même si ils réussissent à avoir un certifcat signé avec la clef privé il ne peuvent pas lire le traffic envoyé vers un autre certificat en écoutant les câbles. Et si ils ont changé le certificat, de sorte que le traffic soit crypté pour ce certificat, ils ont déjà accès au trafic et ça ne sert donc à rien de toucher aux câbles.
Il suffit de créer un certificat intermédiaire signé avec une clé racine, comme ça tous les navigateurs le reconnaissent. Ensuite, générer des clés à la volée signées avec ce certificat n’est pas très compliqué, il y a même des logiciels qui permettent de faire ça très facilement.
Parce que soyons honnête, peu de sites déploient DNSSEC et DANE/TLSA, peu de gens utilisent un résolveur qui vérifient leur validité, peu de gens vérifient les certificats émis par les sites, et peu de gens n’utilisent un VPN.
>Ce que je veut dire c'est que ce câble ne vas avoir aucun impact sur la force de renseignement de la DGSE
Ça oui je suis d’accord. Ils doivent avoir assez de moyens technique avec les fameuses boites noires.
charlesproxy/fiddler are both very good, and will address most situations. I personally use mitmproxy in a transparent proxy mode, because I have came across some apps that "ignore" a proxy configured on the device client.
https://mitmproxy.org/ http://docs.mitmproxy.org/en/latest/transparent.html?highlight=--host#fully-transparent-mode
If the devs were really focused on preventing a MITM they might leverage cert pinning. Not sure of a way you can snoop that traffic, without doing some http client logging on the server in a lab env.
From what little I read on their site, it looks like they're just an http proxy.
Should be as easy as installing it on any other debian distribution. Get the raspbian flash, and install mitm. The biggest thing you'll have to look out for is dependencies. You may run into several libraries you have to install that aren't called out in the default instructions because normally they're there.
Try the Ubuntu Install Instructions first.
You may be able to use a MITM proxy with these.
https://mitmproxy.org/ for example. (I've never used it. Just came up in a googlesearch)
If they support the older ssl versions, they may redo the ssl protocol for the connection to your browser. They're having to decrypt it anyway.
using STunnel is also possibly an option. Use one stunnel to unwrap the old ssl protocol. Then if you need it, another to rewrap it. (or only connect via an ssh tunneled proxy, which is the only thing allowed to talk to the stunnel port)
Is the ACL (access control list) (A/k/a Ip whitelisting) being done in an access router or in a firewall? Most firewalls are very good at dropping spoofed packets while a router could be bypassed.
The typical way a MITM app works is that it's not a router, it's a proxy. As a proxy it is able to deal with HTTPS and also provide valid routing info to both ends of the conversation.
It works for me. I just point the settings in the wifi settings to the proxy.
http://puu.sh/hFnKW/8c33317b18.jpg
Did you remember to install the certificate on the phone? https://mitmproxy.org/doc/certinstall/webapp.html
If you want less bloat, more open source and non-missing images in the documentation, you way want to take a look at mitmproxy. Also, you get real Python scripting instead of this weird FiddleScript thing.
> Reason 1: make things easy to use.
Burgher's solution: a web wallet.
He does not elaborate, however, on the known phenomenon of why web wallets get hacked incessantly?
The reason is otherwise simple.
The browser was specifically designed to leak its secrets to law enforcement. We also know that not only the official mafia makes use of this browser feature but that every other mafia does that too.
Nowadays, we even have user-friendly and automated tools to assist absolutely anybody in duly and extensively hacking browser traffic:
> It can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols.
When you see a large herd of sheep somewhere, then rest assured that the presence of a pack of wolves will automatically materialize out of the blue and start circling this juicy source of extra proteins.
Mutatis mutandis, when a large number of unsuspecting mimic users will start using their browser-based wallet, that will certainly also draw the attention of hungry predators in search of easy prey. Before you know the successful predators will exclaim:
All your base are belong to us!
So, on the one side, yes to making some things easier.
However, on the other side, no, to making it easier for a new socialist income and wealth redistribution scheme to collect funds from the naive segment of the population to be handed over to the more ruthless one.
2FA is a fledgling workaround for the fact that SSL/TLS (as in "https") does not secure anything at all:
> mitmproxy ... can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols.
Is 2FA the solution?
Not necessarily, because the second factor usually also revolves around using (yet another) insecure protocol such as SMS.
Seriously, why use something for protection that simply does not protect?
Can you really solve the problem caused by an insecure protocol by using two insecure protocols (2FA)? And if that does not work, three insecure protocols? Ad nauseam?
The real solution is not to use browser-based client applications and not to use SSL/TLS in any client application at all, be it desktop, web, or mobile.
Nothing is fixed, my friend.
Not even close!
> mitmproxy is your swiss-army knife for debugging, testing, privacy measurements, and penetration testing.
> It can be used to intercept, inspect, modify and replay web traffic such as HTTP/1, HTTP/2, WebSockets, or any other SSL/TLS-protected protocols.
Anything that runs in a browser, such as Chrome, is low-hanging fruit. It is just too easy to strip clean.
If you store anything of value in a browser, you are doing something very dumb.
Firefox has an option to dump TLS keys into a separate file which you can then use to decrypt captured packets. Note that the keys used in your browser and the ones used by the game itself are likely not the same.
Should the above not work, you could look into using a tool like mitmproxy to man in the middle your own connection. This requires that you install the certificate it generates as a trusted certificate in your system.
It's easy to check for HTTP by setting up a proxy such as mitm. For other protocols you'd need a transparent proxy.
There used to be a network log in iOS many years ago. Not sure if that still exists.
Plenty of ways to go here.
If you just want a quick win, set PiHole to return the IP address of your PI as the A record for the domain in question. Then set up something to snoop on incoming network traffic. If you want to try doing it without upsetting the connection, you'll need to proxy it through your Pi so that you can see it but leave it untouched.
If your router supports it (unlikely), you could try to set your Pi as the gateway for all traffic from the target Pi, then use mitmproxy to invisibly proxy traffic. (Or just forward all traffic like a real gateway and use Wireshark.)
If not you might be limited to using NAT firewall rules. You could still use mitmproxy, but it would be rather limited because it's not supposed to be used behind after NAT. You'd need something like
sudo mitmproxy -p 80 --mode reverse:http://example.org:80/ --set keep_host_header
where example.org is the target domain you determined via the PiHole. (If you are stuck with NAT you might find this script useful. Although I haven't tested it extensively, it seems to work.)
... of course, your router might always have the capability to do all this more easily, but that's hard to say without being familiar with the details.
> I can just analyse it and find out if it's true or not.
You can do the same thing for WhatsApp, and it has been done. It's not all that hard to analyze network traffic if you're somewhat tech-savvy. The additional TLS encryption layer can be stripped with a tool like mitmproxy and you will still see no plain-text message content after that (but probably some plain-text metadata). Of course truly verifying that it's the Signal protocol being used as opposed to something else encrypting or obscuring the message content is much harder than having a quick peek behind into the plain client-server communication data, but it *is possible.
> Security Advisory > Concerning web-based wallets. Why are they so insecure? > > In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor. > > The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials. > > From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet. > > Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised. > > This type of attack is typically automated with tools such as: https://mitmproxy.org. > > A fourteen year old script kiddie can learn how to do that in just a few weeks. > > This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time. > > In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Thank you. So what do you suggest?
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies to intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Jaxx wallet undoubtedly uses HTTP to secure communications with remote websites.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
Security Advisory
Concerning web-based wallets. Why are they so insecure?
In order to allow law enforcement and intelligence agencies intercept encrypted messages, HTTPS implements a well-known backdoor.
The certificate for a site's public key can be issued by 600+ different certificate authorities, some of which are very shady. Therefore, any attacker on a node in between your device and the website server can intercept the public key and the real certificate and replace it by a fake couple of credentials.
From there on, the Man In The Middle (MITM) can completely decrypt your not so secure communications over HTTPS. A large number of attackers, working various WIFI locations, telecom operators, and backbone operators will automatically harvest userids and passwords from multiple known sites such as indeed blockchain.com. They also intercept a massive number of fiat banking logins and passwords, usually, with a view on selling them on the darknet.
Therefore, a thefting occurrence is just a question of time. All that needs to happen, is that one node on the route between your computer and the website happens to be compromised.
This type of attack is typically automated with tools such as: https://mitmproxy.org.
A fourteen year old script kiddie can learn how to do that in just a few weeks.
This problem also arises when using websites such as coinbase.com. An exchange that you access through the browser is an accident waiting to happen. It is just a question of time and your money will be gone. You can still use them for small amounts if you make sure not to leave your coins on the exchange's website for extended periods of time.
In other words, never use a web application for secure computing. Websites can simply not be secured. This is by design so.
First, you trust the built in cert authority that comes with mitmproxy. By doing that you trust certs issued on the fly by mitmproxy for the Disney plus urls as you make requests to them. Then you set some settings in your browser to proxy through the proxy server. At that point mitmproxy is decrypting the TLS traffic from Disney, renecrypting it with its own cert and passing it on to your browser.
From there you just need a simple python script to look for the right MIME type for video data in the web response headers and dump the response body to disk.
Use selenium or something to automate the process.
The video files would be whatever Disney sent over to you, no transcoding or capture cards or anything. If your stream was 4K at 60mbps the file(s) you dumped will be exactly the same.
I assume this would work, I don’t know anything about this DRM but not many DRM schemes can defend against this.
I use two linux laptops (or two phones). I don't trust web-based platforms because they are by design vulnerable to MITM attacks. I don't use firmware wallets because I don't trust their firmware.
The web was designed to remain interceptable by law enforcement. Interception is therefore trivially easy to do.
Any network provider on the network path between you and a site like Binance can siphon off your bitcoins by scripting a tool such as mitmproxy:
There are globally tens of thousands of automated harvesters collecting all kinds of login credentials from unsuspecting users.
That is why your Binance login details are undoubtedly already for sale on the darknet, just like your PayPal and online banking details.
Hi, I got a problem with changing said config. My goal is that the apps accept a certificate for mitmproxy (https://mitmproxy.org/). I downloaded the apk with an apk-downloader(https://github.com/HamidrezaMoradi/APK-Downloader) unpacked the apk with 'apktool' and changed the network security to this:
<network-security-config>
<base-config>
<trust-anchors>
<!-- Trust preinstalled CAs -->
<certificates src="system" />
<!-- Additionally trust user added CAs -->
<certificates src="user" />
</trust-anchors>
</base-config>
</network-security-config>
I added/changed the following in the manifest file:
android:debuggable="true" android:network_security_config=”@xml/network_security_config
after signing the apps I could connect to my own wifi-accesspoint. But some apps I can not install for some reason. I read somewhere that it is about SElinux, but I can not enable it myself? It looks like it is set to enforced by design and all solutions to change the setting failed or I failed using them.
I tried both things with a Samsung Galaxy A51 and a Google Pixel 4.
Would be great if someone could help me. I can provide more information if needed.
Thx in advance.
The majority of iOS is open source. https://opensource.apple.com/source
The rest can be reverse engineered similarly as you would to any other software. https://www.youtube.com/watch?v=p512McKXukU
You can also https://mitmproxy.org/ the network traffic to see that the e2ee works and never has to send the secret key to Apple's servers.
There are countless ways to verify that the encryption works.
I have block lists that I maintain and I think is pretty decent: https://www.github.developerdan.com/hosts/
But to answer your question: it’s difficult.
Method 1: using pihole- filtering by client- open the app and inspect the domain queries being made. This method is difficult since you cannot see the actual request being made and so it’s difficult to know what is a required domain and what is an Ad domain. This method takes a lot of trial and error, but after a while you’ll start recognizing a lot of the domains and get a better feel for it
Method 2: Use a HTTPS proxy to inspect the full requests. This method is a lot of work to setup and is probably too involved for the average person, but you can install HTTPS proxy on a local machine, generate a trusted SSL cert, trust it in your device and setup your proxy settings. This method allows you to see the full requests and really figure out what’s required or not. I like MITM Proxy: https://mitmproxy.org/ - I’m sure there are other good options for this too, but a HTTPS proxy is what you are looking for to inspect the full requests
I want to point out that this post is about URL, no need to crack HTTPS, hopefully URLs are not encrypted, else we would not be able to browse the great Internet.
I think that you could write a piece of Python using this lib (mitmdump)[https://mitmproxy.org/#mitmdump].
> So I could just take an http server/client lib in C++ like this and modify it to do both ?
Modify what? It can already do server & client it seems.
> But what you are saying is that this would make the key hidden from someone that tries to decompile but wouldn't actually secure it because it can be retrieved from analyzing the network right ?
If you store your keys in plaintext in C++, a debugger such as x64dbg could easily find them ("find all referenced strings"). To get in the way of that, you would have to obfuscate the keys. But anything beyond that may not be worth the effort if the user is in control of the Root Certificates. I've done things myself with mitmproxy for server emulation.
>shellcode rules
I din't talk about shellcode, but an entire spyware injected in the browser through a 0day.
For the encrypted traffic I was thinking to capture the traffic with mitmproxy then maybe pipe it in snort... but if it can't detect injection is absolutely unuseful.
Put something like https://mitmproxy.org/ between your phone and the internet when using the app and see what requests the app is making. They're most likely just HTTP requests that you can replicate on any machine.
I’m gonna say don’t as even though they mitm ads there is nothing stopping them from morning other traffic with out notice (prolly won’t happen a risk). Also yes they can see bank info if they change.
Here is an example of bank info that could be seen. I used a free open source program called mitm proxy to get this.
Actually, session token theft can happen in many ways: - XSS - Brute force - Database breach - Session fixation - Backend logging of request headers (and someone could have a look at it) - JWT signing key compromise - MITM - even possible when https is enabled (see https://mitmproxy.org, which is probably set up in corporate environments for monitoring purposes) - Malware on user's computer - Recent youtube attacks have demonstrated this! - Internal threats - employees stealing keys / session tokens / seeing logs - Subdomain takeover - Uber was a victim to this - Rogue browser extensions: They can even read httpOnly cookies!
> If you have a deeper knowledge about how to parse the encrypted packets, please let me know.
Setup an SSL proxy and decrypt that way, depending on device security it might complain quite a bit but it would be the easiest way.
Mozilla already does performance change tracking. For example, perfherder regressions recorded for Firefox 71 are tracked in this bug.
> a test environment that replicates more real world conditions of users on actual sites (could be archived with servers replicating ad calls and the like)
That is actually what Mozilla does for popular websites with their Raptor performance-testing framework that perfherder is running. It uses mitmproxy to replay recorded page loads.
Here's the way to do this kind of monitoring: Get and install Fiddler (I'm assuming Windows - if not there's also mitmproxy, which does the same thing) and pass your browser through there. Fiddler (or mitmproxy) will show you exactly what the browser request does. Pass your python requests request through there as well, and you'll be able to see what you're doing differently.
That is still sort of possible, but instead of editing an XML file you have to edit some HTTPS traffic between your PC and Adobe's server. While this can be done with a MITM proxy (eg Fiddler or <code>mitmproxy</code>, I don't think anyone's documented publicly the way to do it with the very latest update after they published it the first time and Adobe changed the response from their server a little bit.
There are cracks though, m0nkrus (google him) is the most trustworthy packer of Adobe software with vetted cracks. He's been active since before PainteR's big releases even.
Just an FYI, it would have been trivial to mitm all network traffic of iOS (or pretty much anything with configurable network settings) and see what apps are talking to what (non-Apple) servers. Decompiling a load of APKs is definitely harder than installing certs once and setting a proxy in the network settings. Using network tools for this and you'd even get a nice and parseable output to analyze.
For SSL pinned apps for either OS, with slightly more effort sometimes you can even see what they're storing and sending. IMO, when Objection works its still easier than decompiling APKs to try to grok what is going on over the network.
> Yeah it was a college desktop computer
For such computers - yes they can monitor anything. Including https traffic.
For that matter any malicious hacker that had physical access can probably monitor anything too (by installing a root kit, or a physical hack to the keyboard connected to it, etc). Don't type any credit cards or other sensitive thing into such computers.
> I'm not sure if they are able to monitor activity on personal laptops and phones connected to the same wifi network.
From your own computer they can monitor all unencrypted traffic to and from such machines, but can not monitor any end-to-end encrypted traffic on such machines (like tor).
Note that they might be able to monitor https traffic if they have a https mtim proxy installed on their network - though if you're careful you should be able to detect it as your browser may warn you about the fake certificate such proxies give you for gmail.com .
If you want to capture the tests while you are taking them (that is: the website only will show you the tests once, and that time is while you are yourself taking the test), then an intercepting proxy (or mitmproxy or similar) will capture all the bytes sent down to your browser, which will include html, JS, images (including any flash payloads), audio/video media, etc etc. You would then need to extract out any identifying information (session cookies, test answers, personal data, etc) but the actual capture part would be almost painless.
If you want to scrape the tests, but almost by definition not while you are taking them, then that would take some research, given that I haven't seen moodle to know what kind of weird stuff one might encounter.
If you can prove that ABP collects data (which shouldn't be hard using https://www.wireshark.org/ or https://mitmproxy.org/), that would be a pretty big news story. You could probably get an article in Ars Technica. There are tons of fake ad blockers that do phone home, but I don't think Ad Block Plus is one of them.
See https://wiki.wireshark.org/SSL
You can set a magic environment variable on the client (for some environments) SSLKEYLOGFILE
or, there are other methods using LD_PRELOAD. But you need to get the private key from the client (yes the client).
You can also trick it with e.g. DNS or policy-based routing, and run https://mitmproxy.org/. But then you rely on it not checking the veracity of the keys (which is conceivable, a lot of kit doesn't check the certificate).
You don't necessarily need a custom API key. Set up mitmproxy on your PC, configure your phone to use your PC's IP as a network proxy (and install the root cert), and then log into the app and hit start.
I was able to reverse engineer my car's remote start this way (different make though). It had two API keys: one hardcoded into the app which you exchanged for a token, then you use that token + your username/password to exchange for another token that lets you send authenticated requests to the API. It's all captured by mitmproxy.
When a form is submitted typically a request is made asynchronously. While you may not see the link or params in the URL bar of the browser there is likely a request that is being processed.
The best course of action is to attempt to recreate the issue with the details provided by the reporter using a tool like:
Tool: https://portswigger.net/burp/ https://mitmproxy.org/
Browser Extension: https://chrome.google.com/webstore/detail/tamper-chrome-extension/hifhgpdkfodlpnlmlnmhchnkepplebkb?hl=en
Without more details it is difficult to determine if this is defined as "self xss" or is a legitimate reflective XSS
I discovered something called mitmproxy. Apparently it takes care of the certificates and stuff so you can decrypt SSL traffic, even with a transparent proxy.
I don't know much about it beyond this (how it installs, what kind of analyzers are out there to analyze its logs, etc), but it seems to at least be a start.
If anyone knows anything about this and can point me in the right direction, that would be fantastic!
They could get everything, even with HTTPS - there's stuff like mitmproxy that allows sniffing on that. They could also just replace your bundled copy of requests or whatever you're using for HTTP and make it log all requests/responses.
Setup a proxy for the Wifi.
If you like command line I enjoy using. https://mitmproxy.org/ Might take a bit to get used to the keystrokes but it works like a charm. Plus you can rewrite payloads if you want.
>Additionally how does python verify libraries it installs through pip
Pip switched recently to https before it was unencrypted plaintext, some developers sign their packages but that is a tiny minority.
Ironically you can install MIT's excellent mitmproxy toolkit with:
pip install mitmproxy
with the SSLstrip2 plugin for example to patch the setup.py on the fly.
/u/artagel wrote:
>But your code will be readable by all, so chances are someone that takes a look at he code will see the malicious functions quite quickly.
Thats the way it should be, but lets be honest we stared at hardbleed for 27 month, and yes Python is not C but still.
You should simply delete all malicious strings out of your library after the initial infection that would make it harder to tie the malware to your lib.
I used mitmproxy but you won't be able to get a nice cumulative data report without writing some Python scripts, and even then it's not really the right tool for the job.
To get measurements that include all your devices you will need something that sits between your internet provider and your devices, recording bandwidth. A good candidate for this would be your wifi router, since it is sitting in the right spot already. If you're lucky your router may already have this feature. If not, you would need to use something like bandwidthd on a wifi router running OpenWRT. Unfortunately this is probably not a reasonable effort to set up unless you're pretty technical already.
As a general rule, nothing else even comes close to video in terms of bandwidth consumption. Youtube, netflix, snapchat all hit pretty hard. If I understand correctly, you're saying that your home broadband/wifi has a data cap? Just move to a different country, I'd say.
>For those of us still in the digital backwaters (personally, Australia), being able to cache popular websites is a huge help when I have 50 staff trying to internet over a crappy ADSL2 pipe and there's no upgrade path for that pipe.
This is one of those 'everyone knows' things: "Everyone knows you can't cache encrypted web pages"
Actually, you can. It is just more complicated than doing so for unencrypted web pages.
Note: This isn't a perfect solution. Certificate pinning by browsers can cause this to not work.
I don't know what SET is... But you can do ARP Spoofing to redirect traffic through your machine. Then you can run something like mitmproxy to observe all requests, and when you see the request to the home.html you replace/modify it. But it's limited to HTTP. If the website uses HTTPS you can check out SSLstrip.
If you manage to do that, you have understood the technical stuff quite well... Maybe you then can easily find this functionality in SET.
The proxy runs on your own computer and generates a new certificate on first install. So as long as you trust your own computer this isn't a real issue. See https://mitmproxy.org/doc/ssl.html for details.
I will name a few reason why this is blatanly fake for anyone who actually knows about computers. I have not seen the original video.
- the way suraj gets on his knees for the almighty justice warrior is too good to be true (your penis is too big? man I can just imagine this kid fantasizing about this stuff when he goes to bed)
- why would he link the facebook post in his email?
- he conveniently removed the appology video, which this fake fuck somehow didn't save. youtube-dl is very famous
- he didn't actually "write" the interceptor himself. Nobody would, it's too complex. You'd use a tool written by someone else. Such as mitmproxy. Which is something you would know if you did it.
- you cant crash a server to the point where it has to be wiped with a photo. You could crash the program, but not a whole fucking computer.
- how would him posting the email exchange let "suraj" know that he didn't have his passwords.
I find it hard to see how you couldn't see through his bullshit. His magical neighbor thing is probably his own sound system.
Let me repeat, there is no doubt in my mind this is fake, which makes this whole thing pretty racist.
As others have said, yes, some IPSs can do what you're after. Even something as simple as mitmproxy can be given a CA cert and key (that you distribute to your client computers as a trusted CA) and generate certificates as needed for each connection.
However, some browsers have gotten wise to this. Firefox and Chrome both support certificate pinning where if they see an unexpected cert returned, they treat it as insecure. All of Google does, along with Twitter, Dropbox, and hundreds of other sites.