50 ms·

It's amazing how many people out there consider MITM as something they don't have to defend against. If you're a developer you have to assume your system will

by YZF 10y ago

It's amazing how many people out there consider MITM as something they don't have to defend against. If you're a developer you have to assume your system will be MITMed. It doesn't matter if you're on the Internet or behind a firewall. Trust on first use is not a good solution because someone can tailor their attack against that first use.

ge96 10y ago
What are some clear signs that this is happening to you? I track the url requested on my server(s) and some of them don't make sense/looking for exploits like wordpress login exploits. I don't know I have SSL/A+ according to Qualys, I'm kind of drawing a blank where MITM happens. I've seen/read about it before. Heartbleed? No I don't know... really tired, but interested, gots to Google. edit: I'm still on LAMP stack for clarification. Too bad to hear about Golang though I'm still looking to learn it I hear a lot of great things about it.
- F30 10y ago
  MITM attacks are designed to not be detectable, so the solution is to have tooling which prohibits them – exactly what is lacking in this case. For web, using TLS (SSL) is a good start. This could be improved further by using HSTS, HPKP, DANE etc. (not sure if A+ already implies them anyway). For SSH, you need to have an out-of-band way to get the host keys or use something like an SSH CA.
  - ge96 10y ago
    What does that mean out-of-band? I'm not good with SSH, I'm not using 2-factor key based, also in general it makes sense to have separate servers right? Like one server that transfers request to a server closer to another country. Not Cloudflare but your own thing assuming you rented from different datacenters in the world. Sorry not related to the question. edit: literally band? Like another wavelength/connection?
    - js2 10y ago
      Out-of-band means you need to transfer (or at verify) the ssh host key over something other than ssh for the initial connection. The host key is how the client verifies the server is who it says it is. The client caches the key after the initial connection. But for that initial connection, there's no way to know that the key isn't that of a MITM attacker. One way to get the key out of band might be from the AWS console for example. Presumably that connection is protected via HTTPS where the CA infrastructure (theoretically) can protect against MITM attacks. BTW, it's also possible to setup ssh to use certificates instead of simple keys which might make sense depending upon how many hosts you manage.
      - ge96 10y ago
        Thanks a lot for the information. You mentioned AWS console, that's not service-specific right? I haven't used AWS before. At any rate, lots too look up/research I appreciate your time. At the moment I'm just dealing with a cheap domain-mapped single-core vps
        azernik 10y ago
        In that case, from an existing client with the SSH host key installed, or with your VPS provider's login shell system (if any), read the files '/etc/ssh/ssh_host_$ALGO_key.pub'. Each of these files will yield a line like this: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBA4Ljuxwb9ss74agSmMRlBZdnIwMHprWIZ3Ts3G+hxnMmcQxeMAWoA4YXZwbrpQulFjDhjGqQoAGF+MKWXBpaeU= root@ip-172-31-17-215 These are all different hostkeys that the server might give to clients, depending on their mutually-agreed signature algorithm. This is in the same format as a line in the known-hosts file; all you need to do is replace that last bit (in my example, root@ip-172-31-17-215) with the hostname by which you log in (e.g. someserver.example.com). Once you've done that, append the results to the known_hosts file, either for your user account (~/.ssh/known_hosts) or system-wide (/etc/ssh/ssh_known_hosts). tl;dr: replacing HOSTNAME with the hostname by which you access the server, run the following command on your server and append its output to ~/.ssh/known_hosts on new clients: cat /etc/ssh/ssh_host_*_key.pub | awk '$3="HOSTNAME"'
- vbezhenar 10y ago
  There are bots who mindlessly throwing HTTP requests on some known vulnerabilities, they don't really check whether you're running wordpress or not. Every web server bombarded by those requests, that's not something you should be worried about.
  - ge96 10y ago
    Yeah I don't use Wordpress but I just happened to see them looking at logs. I am worried because I don't know. I covered some basics like SSL, XSS (htmlescape), sessions are redirect related, PDO/sql... no ddos/load balance... backup backup
    - openasocket 10y ago
      That is what we like to call the background noise of the internet. Scanners are always scanning. Try this as an experiment sometime: make a brand new instance on your favorite cloud provider, and just run tcpdump on it for a few hours. You'll see all kinds of cool things: from people scanning for HTTP, Telnet, people scanning for SSH servers with weak passwords, router exploits with shellcode embedded in a UDP packet, back-scatter from DDoS attacks, cool stuff. Honestly looking at each packet and trying to figure out what's going on is a pretty great way to learn.
      - CapacitorSet 10y ago
        If you want to study the background noise, I think you would have better luck reacting to it - as well as running tcpdump, set up a trivial HTTP and SSH server and observe the interactions.
        ge96 10y ago
        I'll have to lookup TCP dump, I wrote a basic ip-incoming-request tracker and also sometimes see the error log. it is crazy to just randomly try different octet combinations to form a new ip and see what you get... what about ipv6 hoho thanks
      - 10y ago
- drostie 10y ago
  I think you're being downvoted because there are two readings of your first question and reading the whole paragraph is needed to understand that the flippant reading "Psh, you say this is happening to you but I don't believe you, show me some evidence" is wrong and the humble reading "hey, how can I know that this is happening to me -- is it in the log files?" is correct. (It could also be that you're confessing ignorance even though you're also claiming certification though.) The easiest MITM attacks for a civilian to perform involve a wireless router that traffic is routed over, with mildly more complicated but similar setups near a server -- say an untrusted server farm for example, or a malicious employee at a self-hosted location. More complicated attacks require messing with DNS so that people wanting to connect to that host instead connect to you; and really big entities like governments or advertising-hungry service providers could of course try to set something bigger up that affects more people. The basic necessity is that the MITM computer needs to have an IP address, because the premise of MITM is, "you issue a request to connect securely to server IP 123.45.67.89, but you send your packets through me, and I have access to some IP 98.76.54.32. So now I intercept them rather than forwarding them on, and I connect securely to 123.45.67.89 myself, as well as to you. Now everything you try to send to them gets through, and its response gets back to you, but not before I intercept it and decrypt it and store it for later retrieval. So the simplest way to do something like SSH is to imagine that I ask for your public key, you give it to me, I encrypt a shared private key with your public key, I send it to you, you decrypt it, and we use this private key for the rest of our communication. (That's not what SSH does, SSH does Diffie-Hellman, but similar reasoning applies.) A MITM attack is then, you ask for the public key, I make a public/private key pair, I send you that public key, I ask for the remote server's private key for myself. You send me a private key, I send the remote server a different private key, and when you send something to the server, I now decrypt what you sent me, then encrypt it and send to the server. Your main means of security in this scenario is actually 100% the same as your main means of security in SSH, it is that you trust that the private key of the server does not change very often. Therefore when you connect, you store the first public key you ever see; then each time you connect, you double-check it's the same or else you shout at the user "HEY! someone could be overhearing your data! Are you SURE you want to connect still?" What's at issue in the article is that this crucial step was totally ignored by Hashicorp, it was brought to their attention and they just missed it.
ams6110 10y ago
I see so many people who just don't bother when using cloud VMs. They let the instance create a host key when it starts up, they have their own ~/.ssh/known_hosts symlinked to /dev/null, and they use -o "StrictHostKeyChecking no" with ssh.
- Xylakant 10y ago
  Curl -k and disabling certificate checks on tooling that talks to TLS secured endpoints. If I'd get a cent each time I see this, I'd be billionaire.
paulddraper 10y ago
You don't have to defend against MITM if you (or only people you trust) control the network infrastructure. Obviously doesn't apply to the interwebs but it does apply to some setups.

by YZF 10y ago

ge96 10y ago

What are some clear signs that this is happening to you? I track the url requested on my server(s) and some of them don't make sense/looking for exploits like wordpress login exploits. I don't know I have SSL/A+ according to Qualys, I'm kind of drawing a blank where MITM happens. I've seen/read about it before. Heartbleed? No I don't know... really tired, but interested, gots to Google. edit: I'm still on LAMP stack for clarification. Too bad to hear about Golang though I'm still looking to learn it I hear a lot of great things about it.

F30 10y ago
MITM attacks are designed to not be detectable, so the solution is to have tooling which prohibits them – exactly what is lacking in this case. For web, using TLS (SSL) is a good start. This could be improved further by using HSTS, HPKP, DANE etc. (not sure if A+ already implies them anyway). For SSH, you need to have an out-of-band way to get the host keys or use something like an SSH CA.
- ge96 10y ago
  What does that mean out-of-band? I'm not good with SSH, I'm not using 2-factor key based, also in general it makes sense to have separate servers right? Like one server that transfers request to a server closer to another country. Not Cloudflare but your own thing assuming you rented from different datacenters in the world. Sorry not related to the question. edit: literally band? Like another wavelength/connection?
  - js2 10y ago
    Out-of-band means you need to transfer (or at verify) the ssh host key over something other than ssh for the initial connection. The host key is how the client verifies the server is who it says it is. The client caches the key after the initial connection. But for that initial connection, there's no way to know that the key isn't that of a MITM attacker. One way to get the key out of band might be from the AWS console for example. Presumably that connection is protected via HTTPS where the CA infrastructure (theoretically) can protect against MITM attacks. BTW, it's also possible to setup ssh to use certificates instead of simple keys which might make sense depending upon how many hosts you manage.
    - ge96 10y ago
      Thanks a lot for the information. You mentioned AWS console, that's not service-specific right? I haven't used AWS before. At any rate, lots too look up/research I appreciate your time. At the moment I'm just dealing with a cheap domain-mapped single-core vps
      - azernik 10y ago
        In that case, from an existing client with the SSH host key installed, or with your VPS provider's login shell system (if any), read the files '/etc/ssh/ssh_host_$ALGO_key.pub'. Each of these files will yield a line like this: ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBA4Ljuxwb9ss74agSmMRlBZdnIwMHprWIZ3Ts3G+hxnMmcQxeMAWoA4YXZwbrpQulFjDhjGqQoAGF+MKWXBpaeU= root@ip-172-31-17-215 These are all different hostkeys that the server might give to clients, depending on their mutually-agreed signature algorithm. This is in the same format as a line in the known-hosts file; all you need to do is replace that last bit (in my example, root@ip-172-31-17-215) with the hostname by which you log in (e.g. someserver.example.com). Once you've done that, append the results to the known_hosts file, either for your user account (~/.ssh/known_hosts) or system-wide (/etc/ssh/ssh_known_hosts). tl;dr: replacing HOSTNAME with the hostname by which you access the server, run the following command on your server and append its output to ~/.ssh/known_hosts on new clients: cat /etc/ssh/ssh_host_*_key.pub | awk '$3="HOSTNAME"'
vbezhenar 10y ago
There are bots who mindlessly throwing HTTP requests on some known vulnerabilities, they don't really check whether you're running wordpress or not. Every web server bombarded by those requests, that's not something you should be worried about.
- ge96 10y ago
  Yeah I don't use Wordpress but I just happened to see them looking at logs. I am worried because I don't know. I covered some basics like SSL, XSS (htmlescape), sessions are redirect related, PDO/sql... no ddos/load balance... backup backup
  - openasocket 10y ago
    That is what we like to call the background noise of the internet. Scanners are always scanning. Try this as an experiment sometime: make a brand new instance on your favorite cloud provider, and just run tcpdump on it for a few hours. You'll see all kinds of cool things: from people scanning for HTTP, Telnet, people scanning for SSH servers with weak passwords, router exploits with shellcode embedded in a UDP packet, back-scatter from DDoS attacks, cool stuff. Honestly looking at each packet and trying to figure out what's going on is a pretty great way to learn.
    - CapacitorSet 10y ago
      If you want to study the background noise, I think you would have better luck reacting to it - as well as running tcpdump, set up a trivial HTTP and SSH server and observe the interactions.
      - ge96 10y ago
        I'll have to lookup TCP dump, I wrote a basic ip-incoming-request tracker and also sometimes see the error log. it is crazy to just randomly try different octet combinations to form a new ip and see what you get... what about ipv6 hoho thanks
    - 10y ago
drostie 10y ago
I think you're being downvoted because there are two readings of your first question and reading the whole paragraph is needed to understand that the flippant reading "Psh, you say this is happening to you but I don't believe you, show me some evidence" is wrong and the humble reading "hey, how can I know that this is happening to me -- is it in the log files?" is correct. (It could also be that you're confessing ignorance even though you're also claiming certification though.) The easiest MITM attacks for a civilian to perform involve a wireless router that traffic is routed over, with mildly more complicated but similar setups near a server -- say an untrusted server farm for example, or a malicious employee at a self-hosted location. More complicated attacks require messing with DNS so that people wanting to connect to that host instead connect to you; and really big entities like governments or advertising-hungry service providers could of course try to set something bigger up that affects more people. The basic necessity is that the MITM computer needs to have an IP address, because the premise of MITM is, "you issue a request to connect securely to server IP 123.45.67.89, but you send your packets through me, and I have access to some IP 98.76.54.32. So now I intercept them rather than forwarding them on, and I connect securely to 123.45.67.89 myself, as well as to you. Now everything you try to send to them gets through, and its response gets back to you, but not before I intercept it and decrypt it and store it for later retrieval. So the simplest way to do something like SSH is to imagine that I ask for your public key, you give it to me, I encrypt a shared private key with your public key, I send it to you, you decrypt it, and we use this private key for the rest of our communication. (That's not what SSH does, SSH does Diffie-Hellman, but similar reasoning applies.) A MITM attack is then, you ask for the public key, I make a public/private key pair, I send you that public key, I ask for the remote server's private key for myself. You send me a private key, I send the remote server a different private key, and when you send something to the server, I now decrypt what you sent me, then encrypt it and send to the server. Your main means of security in this scenario is actually 100% the same as your main means of security in SSH, it is that you trust that the private key of the server does not change very often. Therefore when you connect, you store the first public key you ever see; then each time you connect, you double-check it's the same or else you shout at the user "HEY! someone could be overhearing your data! Are you SURE you want to connect still?" What's at issue in the article is that this crucial step was totally ignored by Hashicorp, it was brought to their attention and they just missed it.

ams6110 10y ago

I see so many people who just don't bother when using cloud VMs. They let the instance create a host key when it starts up, they have their own ~/.ssh/known_hosts symlinked to /dev/null, and they use -o "StrictHostKeyChecking no" with ssh.

Xylakant 10y ago
Curl -k and disabling certificate checks on tooling that talks to TLS secured endpoints. If I'd get a cent each time I see this, I'd be billionaire.

paulddraper 10y ago

You don't have to defend against MITM if you (or only people you trust) control the network infrastructure. Obviously doesn't apply to the interwebs but it does apply to some setups.