Why, after the discovery of Heartbleed, we do not offer Mail.Ru Mail users to change passwords
The short answer to the question voiced in the title: because it is not required. Heartbleed, one of the most critical vulnerabilities in the history of OpenSSL, did not hit our users. Slightly more detailed answer - under the cut.
We, like many other services, use the OpenSSL library in our projects, but most of our servers, including mail servers, are out of the risk zone. On many of our projects, we use OpenSSL 1.0.0, which has proven to be immune to attack.
Nevertheless, we were in no hurry to relax - first you had to check the other projects. An NSE script was written on the knee to Nmap, which exploits the vulnerability, and after half an hour we received a list of machines with vulnerable versions of OpenSSL.
')
Vulnerable to attack were our banner system servers and several content projects. A little panic, and by 2:00 pm on April 8th the vulnerability was patched.
Although these projects did not allow Heartbleed to gain access to personal data, usernames or passwords of users, attackers could still get authenticated sessions (cookies) of random people, and also potentially compromise our SSL certificates.
We started to deal with SSL certificates immediately. All critical certificates have already been reissued and will be replaced, work on replacing the rest continues.
As for the authorization sessions of users, then we were protected. So-called session sharing works on our mission-critical projects. Its essence is as follows: if even an attacker somehow gets hold of the user's authorization session, then with its help he will not be able to gain access to other portal projects.
Maybe the Codenomicon forecast will come true, and Heartbleed will indeed become a reason for many services to strengthen the security system. For us, this whole story played the role of a training alarm - we were trained to respond quickly to the message about the threat and quickly close all loopholes. Well, and perhaps speak to the attackers "no pasarán!".
We, like many other services, use the OpenSSL library in our projects, but most of our servers, including mail servers, are out of the risk zone. On many of our projects, we use OpenSSL 1.0.0, which has proven to be immune to attack.
Nevertheless, we were in no hurry to relax - first you had to check the other projects. An NSE script was written on the knee to Nmap, which exploits the vulnerability, and after half an hour we received a list of machines with vulnerable versions of OpenSSL.
')
Vulnerable to attack were our banner system servers and several content projects. A little panic, and by 2:00 pm on April 8th the vulnerability was patched.
Although these projects did not allow Heartbleed to gain access to personal data, usernames or passwords of users, attackers could still get authenticated sessions (cookies) of random people, and also potentially compromise our SSL certificates.
We started to deal with SSL certificates immediately. All critical certificates have already been reissued and will be replaced, work on replacing the rest continues.
As for the authorization sessions of users, then we were protected. So-called session sharing works on our mission-critical projects. Its essence is as follows: if even an attacker somehow gets hold of the user's authorization session, then with its help he will not be able to gain access to other portal projects.
Maybe the Codenomicon forecast will come true, and Heartbleed will indeed become a reason for many services to strengthen the security system. For us, this whole story played the role of a training alarm - we were trained to respond quickly to the message about the threat and quickly close all loopholes. Well, and perhaps speak to the attackers "no pasarán!".
Source: https://habr.com/ru/post/218913/
All Articles