Jump to content

Search the Community

Showing results for tags 'mitm'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Site Related
    • News & Updates
    • Site / Forum Feedback
    • Member Introduction
  • News
    • General News
    • FileSharing News
    • Mobile News
    • Software News
    • Security & Privacy News
    • Technology News
  • Downloads
    • nsane.down
  • General Discussions & Support
    • Filesharing Chat
    • Security & Privacy Center
    • Software Chat
    • Mobile Mania
    • Technology Talk
    • Entertainment Exchange
    • Guides & Tutorials
  • Off-Topic Chat
    • The Chat Bar
    • Jokes & Funny Stuff
    • Polling Station

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...

Found 7 results

  1. MITM, remote code execution If you use an app called eVestigator, billed as checking Android phones for compromise, delete it. That's the word from someone signing their name as MaXe from InterN0T, who looked at what the Android app does. The app claimed to test Android phones to see if they've been compromised, but MaXe found it ran a connect() scan across every available TCP port – all 65,535 of them – and tell the user there are “87,375 threats” on their phone. The “report” button didn't do anything much apart from sending the user's external IP address back to the developer, “along with other details about the Android environment + user-entered details”, the advisory says. The app is vulnerable to remote code execution via a man-in-the-middle attack, the note says: “If an attacker performs a MITM attack against "api.ipify.org" by e.g. hijacking the domain name, DNS, IP prefix, or by serving a malicious wireless access point (or hijacking a legitimate one), or by hacking the server at "api.ipify.org", then the attacker can instruct the Android application to execute attacker controlled Java code that the phone will execute in the context of the application. “The root cause of this vulnerability is caused by addJavascriptInterface() within the WebViewer, which in older API versions can be used to execute arbitrary Java code by using reflection to access public methods with attacker provided JavaScript.” MaXe says the vendor was notified on June 25, responded with a legal threat, the vendor pulled the app from Google Play, and tried to get YouTube to pull the video below, before MaXe went ahead with publication. Youtube Video: eVestigator Forensic PenTester v1 - Remote Code Execution via MITM Article source
  2. WikiLeaks dumped today the documentation of a new supposed CIA hacking tool called Archimedes, which the Agency had used to perform Man-in-the-Middle attacks on local networks. According to the nine leaked documents, this tool was previously named Fulcrum but was renamed to Archimedes when it reached v1. Timestamps in the documents reveal the tool was developed and most likely used between 2011 and 2014. The Archimedes manual describes the tool's purpose as follows. As you can see, the tool does not execute the MitM attack itself, but only redirects the target's traffic to another PC on the same network. That second machine will be responsible for breaking down connections, reading the user's traffic, and then relaying the traffic to the LAN's gateway server. Archimedes a repackaged version of Ettercap? The tool itself is very simple, as Jake Williams, founder of Rendition Infosec, writes on Twitter. In fact, according to a quick analysis, the tool isn't even original, appearing to be a repackaged version of Ettercap, an open source toolkit for MitM attacks. The most interesting detail in the entire leak are the MD5 hashes for each of the Archimedes files. Security researchers can now take these hashes and scan artifacts from previous cyber-incidents and see cases where the tool might have been deployed, but they failed to detect it at the time. The Archimedes leak is part of a WikiLeaks series called "Vault 7," during which the non-profit organization has dumped the documentation and user manuals of several hacking tools WikiLeaks claims belong to the CIA. WikiLeaks says it received these tools from hackers and whistleblowers. You can follow our WikiLeaks Vault 7 coverage here. Below is a list of the most notable WikiLeaks "Vault 7" dumps: Source
  3. Karma has long been a staple man-in-the-middle attack used in authorised wireless security assessments and unsanctioned ones, but as many modern operating systems now provide effective countermeasures, other approaches for tricking wireless clients into automatically associating with a rogue access point are wanted. Enter Lure10 – a new attack that, by taking advantage of Wi-Fi Sense, tricks wireless devices running Windows into doing exactly that. What is Wi-Fi Sense? Wi-Fi Sense, enabled by default on Windows 10 and Windows Phone 8.1, is a feature that automatically connects users to crowdsourced open wireless networks it knows about. Based on information previously collected by devices that connected to one or another of these open networks, Microsoft evaluates whether they provide a good-quality connection and, if they do, adds it to the list of hotspots that will be suggested by Wi-Fi Sense. Wi-Fi Sense will pick one when the user is in range, automatically accept its terms of use, and the user will seamlessly be connected to it. The Lure10 technique The success of the attack, which was presented by security engineer George Chatzisofroniou at this year’s Hack in the Box conference in Amsterdam, relies on: The victim’s device being fooled into believing it is within the geographical area of a Wi-Fi Sense-tagged open wireless network The attacker successfully disrupting the victim device’s existing Wi-Fi connection (by spoofing DEAUTH frames), and The attacker successfully mimicking the Wi-Fi Sense network in question (broadcasting a network with the same ESSID – extended service set identifier – is enough to do that). That last prerequisite can be achieved by finding a Wi-Fi Sense network that exists in an area relatively close to the victim (e.g. in their home city), and collecting its ESSID (e.g. “AIRPORT_FREE”). At the same time, through, the attacker also needs to collect the BSSIDs (the MAC addresses of the access points) of the other wireless networks in the same area, as this information is used by Windows Location Service to determine the location of a device. By broadcasting beacon frames with these BSSIDs, the attacker fools WLS into thinking the device is in the area of the impersonated network (first prerequisite of the attack). Once the attacker goes through the two steps, the fact that the rogue access point is sending out beacon frames with the ESSID of the Wi-Fi Sense network it mimics is enough for the victim device to connect to it automatically – IF the victim device has no shared WLANs in its Preferred Networks List and Available Networks List. But even that last condition can be achieved (see Chatzisofroniou’s presentation slides for more details). How to protect yourself? The Lure10 attack technique has been added to the latest version of the open source Wifiphisher rogue Access Point tool, of which Chatzisofroniou is the lead developer. The engineer says that Microsoft has been informed about this issue and has acknowledged its impact, but has not taken steps to mitigate it, as they consider it an “accepted risk.” Users can protect themselves against this attack by simply disabling Wi-Fi Sense on their device. Article source
  4. Explained — What's Up With the WhatsApp 'Backdoor' Story? Feature or Bug! What is a backdoor? By definition: "Backdoor is a feature or defect of a computer system that allows surreptitious unauthorized access to data, " either the backdoor is in encryption algorithm, a server or in an implementation, and doesn't matter whether it has previously been used or not. Yesterday, we published a story based on findings reported by security researcher Tobias Boelter that suggests WhatsApp has a backdoor that "could allow" an attacker, and of course the company itself, to intercept your encrypted communication. The story involving the world's largest secure messaging platform that has over a billion users worldwide went viral in few hours, attracting reactions from security experts, WhatsApp team, and Open Whisper Systems, who partnered with Facebook to implement end-to-end encryption in WhatsApp. Note: I would request readers to read complete article before reaching out for a conclusion. And also, suggestions and opinions are always invited What's the Issue: The vulnerability relies on the way WhatsApp behaves when an end user's encryption key changes. WhatsApp, by default, trusts new encryption key broadcasted by a contact and uses it to re-encrypt undelivered messages and send them without informing the sender of the change. In my previous article, I have elaborated this vulnerability with an easy example, so you can head on to read that article for better understanding. Facebook itself admitted to this WhatsApp issue reported by Boelter, saying that "we were previously aware of the issue and might change it in the future, but for now it's not something we're actively working on changing." What Experts argued: According to some security experts — "It's not a backdoor, rather it’s a feature to avoid unnecessarily re-verification of encryption keys upon automatic regeneration." Open Whisper Systems says — "There is no WhatsApp backdoor," "it is how cryptography works," and the MITM attack "is endemic to public key cryptography, not just WhatsApp." A spokesperson from WhatsApp, acquired by Facebook in 2014 for $16 Billion, says — "The Guardian's story on an alleged backdoor in WhatsApp is false. WhatsApp does not give governments a backdoor into its systems. WhatsApp would fight any government request to create a backdoor." What's the fact: Notably, none of the security experts or the company has denied the fact that, if required, WhatsApp, on government request, or state-sponsored hackers can intercept your chats. What all they have to say is — WhatsApp is designed to be simple, and users should not lose access to messages sent to them when their encryption key is changed. Open Whisper Systems (OWS) criticized the Guardian reporting in a blog post saying, "Even though we are the creators of the encryption protocol supposedly "backdoored" by WhatsApp, we were not asked for comment." What? "...encryption protocol supposedly "backdoored" by WhatsApp…" NO! No one has said it's an "encryption backdoor;" instead this backdoor resides in the way how end-to-end encryption has been implemented by WhatsApp, which eventually allows interception of messages without breaking the encryption. As I mentioned in my previous story, this backdoor has nothing to do with the security of Signal encryption protocol created by Open Whisper Systems. It's one of the most secure encryption protocols if implemented correctly. Then Why Signal is more Secure than WhatsApp? You might be wondering why Signal private messenger is more secure than Whatsapp, while both use the same end-to-end encryption protocol, and even recommended by the same group of security experts who are arguing — "WhatsApp has no backdoor." It's because there is always room for improvement. The signal messaging app, by default, allows a sender to verify a new key before using it. Whereas, WhatsApp, by default, automatically trusts the new key of the recipient with no notification to the sender. And even if the sender has turned on the security notifications, the app notifies the sender of the change only after the message is delivered. So, here WhatsApp chose usability over security and privacy. It’s not about 'Do We Trust WhatsApp/Facebook?': WhatsApp says it does not give governments a "backdoor" into its systems. No doubt, the company would definitely fight the government if it receives any such court orders and currently, is doing its best to protect the privacy of its one-billion-plus users. But what about state-sponsored hackers? Because, technically, there is no such 'reserved' backdoor that only the company can access. Why 'Verifying Keys' Feature Can't Protect You? WhatsApp also offers a third security layer using which you can verify the keys of other users with whom you are communicating, either by scanning a QR code or by comparing a 60-digit number. But here’s the catch: This feature ensure that no one is intercepting your messages or calls at the time you are verifying the keys, but it does not ensure that no one, in the past had intercepted or in future will intercept your encrypted communication, and there is no way, currently, that would help you identify this. WhatsApp Prevention against such MITM Attacks are Incomplete WhatsApp is already offering a "security notifications" feature that notifies users whenever a contact's security code changes, which you need to turn on manually from app settings. But this feature is not enough to protect your communication without the use of another ultimate tool, which is — Common Sense. Have you received a notification indicating that your contact's security code has changed? Instead of offering 'Security by Design,' WhatsApp wants its users to use their common sense not to communicate with the contact whose security key has been changed recently, without verifying the key manually. The fact that WhatsApp automatically changes your security key so frequently (for some reasons) that one would start ignoring such notifications, making it practically impossible for users to actively looking each time for verifying the authenticity of session keys. What WhatsApp should do? Without panicking all one-billion-plus users, WhatsApp can, at least: Stop regenerating users' encryption keys so frequently (I clearly don't know why the company does so). Give an option in the settings for privacy-conscious people, which if turned on, would not automatically trust new encryption key and send messages until manually accepted or verified by users. ...because just like others, I also hate using two apps for communicating with my friends and work colleagues i.e. Signal for privacy and WhatsApp because everyone uses it. Source
  5. SSL is a great way to encrypt and protect data transferred between servers or between browser and servers from any attempt to spy on the data on its way or as known as man in the middle attack, we will focus in this article on HTTPS protocol and the method to attack it and proper way to fight against this attacks. Is HTTPS that important ? first let’s declare the importance of using SSL with HTTP traffic. Imagine the next scenario. you are trying to login to your bank account with your laptop connected in your wifi and you know its secure its you and your little sister who connect in the same wifi, secure right? ? but your wifi uses weak password or vulnerable to exploits, so someone gain access to the same wifi and with a simple tool he can run a packet sniffer and catch all your and your sister’s traffic and look into your password and even change the data if he wants. Imaging the same scenario but your bank is using HTTPS, when you access the website you receive the website certificate signed and your browser validate the signature to make sure that certificate belongs to the website, then your browser encrypt all data then send the encrypted data to the server and do it vice versa, so if our attacker try to sniff the data all what he will get is the encrypted data, cool right ? Lets be honest no one is 100% secure and SSL had a tough couple of years from attacks like Heartblead, DROWN and POODLE , this attacks target the SSL it self , all what you have to do to mitigate this attacks is to be up to date always and apply vendors patches as it appears. But what about sniffing dangerous, does using HTTPS solve it? the answer is not completely, some researchers tried to sniff HTTPS packages by inventing tools like SSL sniff and SSL strip. SSL sniff :- SSL sniff is tool programmed by Moxie Marlinspike based on vulnerability he discovered, let us quickly describe it. When you request a website for example ( example.com ) as we said before you receive the example.com certificate the certificate must be issued by one of the valid vendors, so if follow certificate chain from the root certificate ( root certificate embedded in the browsers by default) to the leaf certificate ( example.com certificate) but what if leaf certificate tried to generate another certificate in the chain? lets say to website like paypal.com! the surprising thing that it worked and no one bothered himself by checking that leaf certificate generated another leaf certificate, but how attacker can use this? the website still be example.com not paypal.com, and that’s why he made SSL Sniff tool. by intercepting the traffic (man in the middle attack) you will intercept the request to paypal.com and with SSL Sniff, then you can generate the paypal.com certificate from the leaf certificate you have example.com and send it back to the browser instead of original paypal.com certificate, when the browser try to validate the certificate it will pass because the chain is correct, then any request between the browser and the server will be signed by the certificate you generate so you can decrypt the data as you want, and then re-transfer it by using the original paypal.com certificate, Boom. fortunately it had been fixed and now the leaf certificate cannot generate another certificate. SSL Strip:- Another tool by the same man Moxie Marlinspike. but in this time he came up with another trick using man in the middle, but what if he changed the request to http instead of HTTPS, and he will request the website on behalf of the user using HTTPS but between the attacker and the user its plain http, and the user will not be so suspicious to notice the difference in his browser. How to defend against this techniques ? Using HTTPS only will not solve it completely, even if you restricted the connection to HTTPS only in the server side, the attacker still can force user to use HTTP by using SSL strip and you will not notice the request still HTTPS in your end, and here HSTS header comes. HTTP Strict Transport Security (HSTS) is a web security policy mechanism it tells the browser that he must only connect to the website using secure HTTPS connection. just send header like this from your server. Strict-Transport-Security: max-age=31536000 The key is Strict-Transport-Security that tells the browser or any other agent to strict the transportation to ssl . the value is maximum age to use this header in seconds 31536000 equal to one non-leap year. Then the user agent will automatically change any url to HTTPS before it send it to the server allowing only secure connections. Bottom line , using HTTPS comes with responsibilities , you must be up to date , patch your system if any vulnerability comes up, renew your certificate on time and don’t forget to use Strict-Transport-Security Policy. Article source
  6. The coolest talk of this year's Blackhat must have been the one of Sean Devlin and Hanno Böck. The talk summarized this early year's paper, in a very cool way: Sean walked on stage and announced that he didn't have his slides. He then said that it didn't matter because he had a good idea on how to retrieve them. He proceeded to open his browser and navigate to a malicious webpage. Some javascript there seemed to send various requests to a website in his place, until some MITM attacker found what they came for. The page refreshed and the address bar now whoed https://careers.mi5.gov.uk as well as a shiny green lock. But instead of the content we would have expected, the white title of their talk was blazing on a dark background. What happened is that a MITM attacker tampered with the mi5's website page and injected the slides in a HTML format in there. They then went ahead and gave the whole presentation via the same mi5's webpage. How it worked? The idea is that repeating a nonce in AES-GCM is... BAD. Here's a diagram from Wikipedia. You can't see it, but the counter has a unique nonce prepended to it. It's supposed to change for every different message you're encrypting. AES-GCM is THE AEAD mode. We've been using it mostly because it's a nice all-in-one function that does encryption and authentication for you. So instead of shooting yourself in the foot trying to MAC then-and-or Encrypt, an AEAD mode does all of that for you securely. We're not too happy with it though, and we're looking for alternatives in the CAESAR's competition (there is also AES-SIV). The presentation had an interesting slide on some opinions: "We conclude that common implementations of GCM are potentially vulnerable to authentication key recovery via cache timing attacks." (Emilia Käsper, Peter Schwabe, 2009) "AES-GCM so easily leads to timing side-channels that I'd like to put it into Room 101." (Adam Langley, 2013) "The fragility of AES-GCM authentication algorithm" (Shay Gueron, Vlad Krasnov, 2013) "GCM is extremely fragile" (Kenny Paterson, 2015) One of the bad thing is that if you ever repeat a nonce, and someone malicious sees it, that person will be able to recover the authentication key. It's the H in the AES-GCM diagram, and it is obtained by hashing the encryption key K. If you want to know how, check Antoine Joux' comment on AES-GCM. Now, with this attack we lose integrity/authentication as soon as a nonce repeats. This means we can modify the ciphertext in the middle and no-one will realize it. But modifying the ciphertext doesn't mean we can modify the plaintext right? Wait for it... Since AES-GCM is basically counter mode (CTR mode) with a GMac, the attacker can do the same kind of bitflip attacks he can do on CTR mode. This is pretty bad. In the context of TLS, you often (almost always) know what the website will send to a victim, and that's how you can modify the page with anything you want. Look, this is CTR mode if you don't remember it. If you know the nonce and the plaintext, fundamentally the thing behaves like a stream cipher and you can XOR the keystream out of the ciphertext. After that, you can encrypt something else by XOR'ing the something else with the keystream They found a pretty big number of vulnerable targets by just sending dozen of messages to the whole ipv4 space. My thoughts Now, here's how the TLS 1.2 specification describe the structure of the nonce + counter in AES-GCM: [salt (4) + nonce (8) + counter (4)]. The whole thing is a block size in AES (16 bytes) and the salt is a fixed part of 4 bytes derived from the key exchange happening during TLS' handshake. The only two purposes of the salt I could think of are: preventing against multi-target attacks on AES making the nonce smaller to make nonce-repeating attacks easier Pick the reason you prefer. Now if you picked the second reason, let's recap: the nonce is the part that should be different for every different message you encrypt. Some increment it like a counter, some others generate them at random. This is interesting to us because the birthday paradox tells us that we'll have more than 50% chance of seeing a nonce repeat after \(2^{32}\) messages. Isn't that pretty low? Article source
  7. Ponting

    SSL EYE v1.5

    SSL Eye is a unique tool that detects SSL man in the middle spying, by comparing SSL fingerprints of single or multiple sites across many remote nodes that are owned and managed by EEDS located in different countries such as Singapore, USA, and Netherlands. In order to compare the results with your own fingerprint that comes through your local ISP. Additionally the tool will tell you if the site is using Extended Validation (EV) certificates or perfect forward secrecy as the key exchange mechanism such as DHE_RSA or ECDHE_RSA which is used by google. We have also implemented global shortcut keys on the application so that you can copy a site from the browser address bar and call it for instant scan to check if you are a victim of Man in The Middle Attack (MITM). Where the attacker listens to your communication channel in a public key exchange re-sends the keys on your behalf, substituting his own fake keys for the requested one, so that the two original parties (you and your bank) will still appear to be communicating with each other. Screenshots Features Retrieve fingerprint of any given ssl url from single or multiple sites with SNI support across EEDS nodes located in Netherlans, USA and Singapore.Check if the site is using Extended Validation (EV) certificates.Check if the site is implementing perfect forward secrecy on key exchange.Export results into HTML report.Sound alerts for invalid certificates.Scan with global keys from clipboard without user interaction.Homepage: https://www.digi77.com/ssl-eye-prism-protection/ Download Link: http://www.digi77.com/software/ssleye/update/SSLEye_Setup.exe
  • Create New...