Tag Info

New answers tagged

0

The fact that the user is going to the site at all. I'm guessing that there would likely have been a DNS request for the domain name, and that request wouldn't have been encrypted, so the hacker knows at the very least that the user is accessing this specific site. Yes, the DNS request will reveal the host name if the DNS request can be MITM'd and the ...


2

In an SSL connection, the GET or POST portion is encrypted. For example: visitor: https://www.yoursite.com/shoppingcart.aspx www.yoursite.com visible GET /shoppingcart.aspx encrypted HTTP/1.0 encrypted What you're thinking about is called an inference attack, where with little bits of information, an attacker can put together ...


0

With MitM over a HTTPS website, the greatest threat comes from the ability to replace the site's SSL cert with his rogue one. Yes, the user will receive a warning that the site does not match the cert but users are likely to just click continue. Once the cert has been replaced, he can decrypt all communication as he has the private key for his own cert. If ...


0

If the software is using a fixed port and an hostname rather than IP to connect you could redirect the traffic to your local computer and use, e.g. ncat to remove and readd ssl, then inspect the traffic in between. Comment if you need more details.


3

Wireshark should be able to do it. However, the process is not as straightforward as you would have to scan the memory for the master secret. Here is a tutorial on how to decrypt SSL without access to the master private key. http://www.cloudshield.com/blog/advanced-malware/how-to-decrypt-openssl-sessions-using-wireshark-and-ssl-session-identifiers/


0

In the case of OpenVPN the certificate is already known to the client, there is no exchange at that point, so MiTM is mitigated based on the idea that they would have to compromise the server cert in order to mislead the client into communicating with the middle device. If the MiTM presented an alternate cert for communication, the client would reject it, ...


0

If you have a rooted Android connected over WiFi, dsploit is an excellent tool. It can perform active attacks of various kinds, as well as network scans. MITM with sslstrip and content substitution is an option. http://www.dsploit.net/


1

This also applies to normal chip cards. Its not limited to NFC. If you manage to social engineer a user into using the card at a fake terminal, then the relay attack can happen too. One solution of distance bounding, is to apply logic on the server side that would check if a specific authentication attempt can be logically correct. Lets say you have 2 ...


0

You might be interested in the WiFi Pineapple from Hak5, which provides turn-key MitM functionality. Troy Hunt has a helpful quick start guide.


0

The idea behind this is that the code generated by Device A must be transmitted separately to Device B. Any method of communication will do: email, text message, phone call, etc. To answer your questions: How is the code calculated in the first place? From a keypair? This depends on the software of the device. Some vendors will generate a random 4 ...


6

For NFC technology, the main solution that has been offered to date is distance bounding, in which a tightly timed exchange of challenges and responses persuades the verfier that the prover cannot be further away than a certain distance. This solution, however, has some drawbacks: It still won't say whether the specific endpoint the verifier is talking to ...


0

There should be some flaw in the certificate pinning code that you have written for your app. If certificate pinning was done correctly , then no proxy can intercept the traffic, assuming that you are not tampering with the application. I would suggest you to check some great examples on how to implement certificate pinning here.


3

No, you won't be able to do a MITM attack on the edge router and your access point/router. In order to perform a man in the middle attack you must be on a network segment that allows your device to actually get in between these two routers. As programings already pointed out your gateway is the internal router/access point, which means that without it you ...


2

If Charles proxy is able to intercept SSL/TLS traffic, then certificate validation has failed. This demonstrates that the mobile device is not properly verifying the server's certificate. In a mobile security assessment, certificate pinning can be disabled by hooking the platform's SSL/TLS implementation and changing how certificate validation works. An ...


2

After all of us effectively signed a "don't ever disclose your login details to anybody else under any circumstances, or else" agreement with our banks, how is this possible? Sofort AG is a german company, so I'll focus on Germany: There was an antitrust proceeding, and as a result of it, most banks changed their terms and conditions to allow this (at ...


1

In order to act as a proper access point, your card needs to support "master"/"AP" mode. You can fake it if the card supports "monitor" mode with packet injection (in this case, your AP software will be performing many of the tasks that the driver/card would be performing in "master" mode), and you can get some of the functionality of an AP if your card ...


0

When I perform iw list I have a third option, monitor. Supported interface modes: * IBSS * managed * monitor I think this is what your IOCTL failure is stemming from. Your wireless interface needs to have a monitor mode. Try the following command (as root) to enable RFMON and I believe it will fix your problem. iwconfig [interface] ...


10

In "hash" of the handshake messages, as used in the Finished messages, is computed with the PRF, which uses the master secret as additional parameter (in SSL 3.0 the computation is different but the master secret is still used; the 36-byte values are sort-of-HMAC with both MD5 and SHA-1). If the attacker alters one of the previous handshake messages, then he ...


2

Correct me if I am wrong, according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. its only after the tunnel is created that the complete GET or POST request is sent. No, this is not a HTTP CONNECT, it is a TCP connection request. The HTTP CONNECT method is only used if you are connecting over a HTTP proxy ...


1

according to HTTP v1.1 a simple CONNECT request initiates a SSL tunnel between the server and a client. Not really correct. CONNECT is only used together with proxies. And even then it does only establish a tunnel directly to the other side, but not yet the SSL tunnel. The SSL tunnel is with and without proxy only established with the SSL handshake ...


8

There are 2 main reasons why cookies are easier to steal than login credentials: Cookies are sent for every request, login credentials are only sent once for each "session" If you sniff a network, it is less likely that you will be in place at the point when a user actually perform a login using its username and password. Cookies on the other hand, are ...


3

If the username and password were sent in plaintext, then yes, sniffing them is a better option. However, a common pattern is for the login process to be encrypted (for security), and then the remainder of the session takes place in the clear (because encryption imposes a bit of a performance penalty). In such a case, the username and password cannot be ...



Top 50 recent answers are included