Tag Info

New answers tagged

2

It's sort of like asking the difference between a car and steering. When you are driving a car, you can (and probably should!) steer it. But you can steer a bike too... Enough with the analogy, the difference, in my view, is that MitM is a class of attack and the sniffing is simply the word for analyzing packets on the network (and often just the packets ...


2

A sniffing attack is a attack on confidentiality. It can be via a span port on a switch, processes on servers through which the traffic passes, on the end user client. Sniffing is often an MITM attack but it is passive. A MITM attack is typically a more active attack where the traffic route has been altered to include the adversary, such as a rogue access ...


6

Typically, an eavesdropper (sniffer) will be passive -- that is they will not modify the traffic. Man-in-the-middle (MiTM) attacks usually imply an active adversary -- one who will change the contents of the message before passing it on. The two are not entirely distinct, as a MiTM may use their active attack to read the contents of messages, or simply to ...


-1

What do both parties use their computers for? If either machine is infected then it really doesn't matter if you live next door to each other or in separate continents. End points are leaky little beasts. To be more specific, You need to share how the communications are taking place. Are you using Skype or some other IM program? Email? VoIP? Because some ...


2

By sending a SHA-512 hash of it, you don't expose more useful information about the key, than the attacker had from the Diffie-Hellman messages. However, it is completely insecure to rely on that hash. The man in the middle could give every side its needed hash, and still could intercept the traffic. For Diffie-Hellman to provide any security, either the ...


0

While I'm not 100% sure I follow your question, SiteKeys are designed to prevent phishing as the phishing site will not know the users custom image or the users word/phrase that they have associated with that image. While user-agent identification does provide some security in certain situations, it really can't provide much security in this instance. ...


4

Your problem is a problem of authorization. SSL has nothing to do with your problem. While you must use SSL to protect your data from leaking and tampering, it will not help in any way to solve your authorization problems. Encrypting the parameters is insufficient. It will keep the common user from tampering with the parameters, but it will not stop any ...


0

I think the pen test team misspoke. MITM is a much more serious threat than a XSS, because the MITM attacker can monitor and replace any of the content of your site. It's invalid to complain about the content of a site attributing a MITM attack, because the content is irrelevant to a MITM. MITM can always inject content into your site. XSS is a ...


0

Man-in-the-middle might not be the only way to manipulate the cookie. If, for example, the cookie is used for example.org and you have subdomains like user1.example.org which you either don't control or which might have XSS problems, then it will be possible to set the cookie for example.org from user1.example.org. You will probably not be able to read it, ...


1

You would normally be correct, however you cannot protect against this MITM vulnerability even if you use a secure cookie over SSL. This cookie could still be MITM'd to inject XSS. The pen test report is correct - the fact that the XSS mechanism is a cookie gives rise to the MITM vulnerability. This is because the Same Origin Policy for cookies does not ...


0

Google "MITM PROXY", you will find a lot of tools. One example is: http://mitmproxy.org/ With cell phones, MiTM attacks are multi-route, so you have to sometimes do some pretty technical set up of environments to completely cover all the paths. Remember you have 3g/4g, sms/mms, wireless, NFC, BT/BTLE. Of course if you are using just the emulator, then you ...


2

If your site only serves content over HTTPS and hard fails on HTTP requests, with no redirect, are you still vulnerable? If the user accidentally enters http://example.com in their address bar instead of https://example.com, sslstrip could still intercept the connection and trick the user. This could also be true of user's following malicious links - ...


5

Yes, without further measures, the attacker still can perform SSLStrip. For SSLStrip to work, the attacker only needs to be a man in the middle, unrelated from your behaviour regarding HTTP. On an incoming HTTP request, the attacker would open an HTTPS connection to the real server, and "strip" the SSL off the HTTPS. So, there would be no HTTP communication ...


1

As part of the attack is doing a MITM for all the victims TCP/UDP traffic, as long as the user does not use an https address explicitly, he could be tricked. For example: if a victim tries to go to "mail.google.com" and trusts the automatic redirect Google does from the http to https (try it for yourself), and he does not check the address bar gots the ...


1

Can an attacker intercept your HTTPS request and perform the request "on your behalf", so-to-speak, and serve your browser an HTTP version If you access an HTTPS site directly (from bookmark for example) then a SSLStrip MITM attack would be highly unlikely. The request would either fail due to the browser looking for a TLS handshake, or prompt you ...


1

You are correct that if the attacker gets onto your proxy, then all systems that trust the proxy are vulnerable in some way. Your proxy is now as valuable a target as the sum of all the traffic flowing to the machines that trust it. What you can do to help limit your exposure is to restrict the intended key usage on your root certificate, limiting its use ...


1

The certificate file by itself does not suppose a threat. When you load it into your browser it only lists it as a trusted source. That means that any certificate signed by that issuer should be trusted and thus allow you to connect to a site. Without access to the corredponding private key (which should be only present in the proxy), it cannot be used to ...


0

Turns out LTE can use two types of algorithms for authentication and key generation: Test – For Test algorithm the OP is not required, so if current LTE operator is supporting Test algorithm for authentication and key generation then OP is not required and in this case USIM doesn’t contain OP. MILENAGE – For MILENAGE OP is mandatory. Meaning: if operator ...


0

Yes, if you see HTTPS:// in your browser window, haven't accepted any certificate warnings and you are visiting trustworthy website like a bank, your data back and forth would remain private. If you HTTPS session were being attacked you should get a certificate warning. This might happen a) due to a fake certificate from an attacker, or b) sometimes just ...


1

First, you can never be 100% sure about anything security, it's all on a scale. As for SSL, that just means your traffic from the site to your browser is encrypted it does not mean that you are ever secure, it is just a tool -employed properly and it does a great job (not perfect, but great). Now as for MiTM attacks... well... unless you are the network ...



Top 50 recent answers are included