Mighty Treps

Sunday, January 28, 2024

Practical Bleichenbacher Attacks On IPsec IKE

We found out that reusing a key pair across different versions and modes of IPsec IKE can lead to cross-protocol authentication bypasses, enabling the impersonation of a victim host or network by attackers. These vulnerabilities existed in implementations by Cisco, Huawei, and others.

This week at the USENIX Security conference, I will present our research paper on IPsec attacks: The Dangers of Key Reuse: Practical Attacks on IPsec IKE written by Martin Grothe, Jörg Schwenk, and me from Ruhr University Bochum as well as Adam Czubak and Marcin Szymanek from the University of Opole [alternative link to the paper]. This blog post is intended for people who like to get a comprehensive summary of our findings rather than to read a long research paper.

IPsec and Internet Key Exchange (IKE)

IPsec enables cryptographic protection of IP packets. It is commonly used to build VPNs (Virtual Private Networks). For key establishment, the IKE protocol is used. IKE exists in two versions, each with different modes, different phases, several authentication methods, and conﬁguration options. Therefore, IKE is one of the most complex cryptographic protocols in use.

In version 1 of IKE (IKEv1), four authentication methods are available for Phase 1, in which initial authenticated keying material is established: Two public key encryption based methods, one signature based method, and a PSK (Pre-Shared Key) based method.

Attacks on IKE implementations

With our attacks we can impersonate an IKE device: If the attack is successful, we share a set of (falsely) authenticated symmetric keys with the victim device, and can successfully complete the handshake – this holds for both IKEv1 and IKEv2. The attacks are based on Bleichenbacher oracles in the IKEv1 implementations of four large network equipment manufacturers: Cisco, Huawei, Clavister, and ZyXEL. These Bleichenbacher oracles can also be used to forge digital signatures, which breaks the signature based IKEv1 and IKEv2 variants. Those who are unfamiliar with Bleichenbacher attacks may read this post by our colleague Juraj Somorovsky for an explanation.

The affected hardware test devices by Huawei, Cisco, and ZyXEL in our network lab.

We show that the strength of these oracles is sufficient to break all handshake variants in IKEv1 and IKEv2 (except those based on PSKs) when given access to powerful network equipment. We furthermore demonstrate that key reuse across protocols as implemented in certain network equipment carries high security risks.

We additionally show that both PSK based modes can be broken with an offline dictionary attack if the PSK has low entropy. Such an attack was previously only documented for one of those modes (edit: see this comment). We thus show attacks against all authentication modes in both IKEv1 and IKEv2 under reasonable assumptions.

The relationship between IKEv1 Phase 1, Phase 2, and IPsec ESP. Multiple simultaneous Phase 2 connections can be established from a single Phase 1 connection. Grey parts are encrypted, either with IKE derived keys (light grey) or with IPsec keys (dark grey). The numbers at the curly brackets denote the number of messages to be exchanged in the protocol.

Where's the bug?

The public key encryption (PKE) based authentication mode of IKE requires that both parties exchanged their public keys securely beforehand (e. g. with certiﬁcates during an earlier handshake with signature based authentication). RFC 2409 advertises this mode of authentication with a plausibly deniable exchange to raise the privacy level. In this mode, messages three and four of the handshake exchange encrypted nonces and identities. They are encrypted using the public key of the respective other party. The encoding format for the ciphertexts is PKCS #1 v1.5.

Bleichenbacher attacks are adaptive chosen ciphertext attacks against RSA-PKCS #1 v1.5. Though the attack has been known for two decades, it is a common pitfall for developers. The mandatory use of PKCS #1 v1.5 in the PKE authentication methods raised suspicion of whether implementations resist Bleichenbacher attacks.

PKE authentication is available and fully functional in Cisco's IOS operating system. In Clavister's cOS and ZyXEL's ZyWALL USG devices, PKE is not ofﬁcially available. There is no documentation and no conﬁguration option for it and it is therefore not fully functional. Nevertheless, these implementations processed messages using PKE authentication in our tests.

Huawei implements a revised mode of the PKE mode mentioned in the RFC that saves one private key operation per peer (we call it RPKE mode). It is available in certain Huawei devices including the Secospace USG2000 series.

We were able to conﬁrm the existence of Bleichenbacher oracles in all these implementations. Here are the CVE entries and security advisories by the vendors (I will add links once they are available):

Cisco: CVE-2018-0131, Security Advisory
Huawei: CVE-2017-17305, Security Advisory
Clavister: CVE-2018-8753, Security Advisory
Zyxel: CVE-2018-9129, Security Advisory

On an abstract level, these oracles work as follows: If we replace the ciphertext of the nonce in the third handshake message with a modiﬁed RSA ciphertext, the responder will either indicate an error (Cisco, Clavister, and ZyXEL) or silently abort (Huawei) if the ciphertext is not PKCS #1 v1.5 compliant. Otherwise, the responder continues with the fourth message (Cisco and Huawei) or return an error notiﬁcation with a different message (Clavister and ZyXEL) if the ciphertext is in fact PKCS #1 v1.5 compliant. Each time we learn that the ciphertext was valid, we can advance the Bleichenbacher attack one more step.

A Bleichenbacher Attack Against PKE

If a Bleichenbacher oracle is discovered in a TLS implementation, then TLS-RSA is broken since one can compute the Premaster Secret and the TLS session keys without any time limit on the usage of the oracle. For IKEv1, the situation is more difﬁcult: Even if there is a strong Bleichenbacher oracle in PKE and RPKE mode, our attack must succeed within the lifetime of the IKEv1 Phase 1 session, since a Diffie-Hellman key exchange during the handshake provides an additional layer of security that is not present in TLS-RSA. For example, for Cisco this time limit is currently ﬁxed to 60 seconds for IKEv1 and 240 seconds for IKEv2.

To phrase it differently: In TLS-RSA, a Bleichenbacher oracle allows to perform an ex post attack to break the conﬁdentiality of the TLS session later on, whereas in IKEv1 a Bleichenbacher oracle only can be used to perform an online attack to impersonate one of the two parties in real time.

Bleichenbacher attack against IKEv1 PKE based authentication.

The figure above depicts a direct attack on IKEv1 PKE:

The attackers initiate an IKEv1 PKE based key exchange with Responder A and adhere to the protocol until receiving the fourth message. They extract the encrypted nonce from this message, and record the other public values of the handshake.
The attackers keep the IKE handshake with Responder A alive as long as the responder allows. For Cisco and ZyXEL we know that handshakes are cancelled after 60 seconds, Clavister and Huawei do so after 30 seconds.
The attackers initiate several parallel PKE based key exchanges to Responder B.

In each of these exchanges, they send and receive the ﬁrst two messages according to the protocol speciﬁcations.
In the third message, they include a modiﬁed version of the encrypted nonce according to the the Bleichenbacher attack methodology.
They wait until they receive an answer or they can reliably determine that this message will not be sent (timeout or reception of a repeated second handshake message).

After receiving enough answers from Responder B, the attackers can compute the plaintext of the nonce.
The attackers now have all the information to complete the key derivation and the handshake. They thus can impersonate Responder B to Responder A.

Key Reuse

Maintaining individual keys and key pairs for each protocol version, mode, and authentication method of IKE is difﬁcult to achieve in practice. It is oftentimes simply not supported by implementations. This is the case with the implementations by Clavister and ZyXEL, for example. Thus, it is common practice to have only one RSA key pair for the whole IKE protocol family. The actual security of the protocol family in this case crucially depends on its cross-ciphersuite and cross-version security. In fact, our Huawei test device reuses its RSA key pair even for SSH host identification, which further exposes this key pair.

A Cross-Protocol Version Attack with Digital Signature Based Authentication

Signature Forgery Using Bleichenbacher's Attack

It is well known that in the case of RSA, performing a decryption and creating a signature is mathematically the same operation. Bleichenbacher's original paper already mentioned that the attack could also be used to forge signatures over attacker-chosen data. In two papers that my colleagues at our chair have published, this has been exploited for attacks on XML-based Web Services, TLS 1.3, and Google's QUIC protocol. The ROBOT paper used this attack to forge a signature from Facebook's web servers as proof of exploitability.

IKEv2 With Digital Signatures

Digital signature based authentication is supported by both IKEv1 and IKEv2. We focus here on IKEv2 because on Cisco routers, an IKEv2 handshake may take up to four minutes. This more relaxed timer compared to IKEv1 makes it an interesting attack target.

I promised that this blogpost will only give a comprehensive summary, therefore I am skipping all the details about IKEv2 here. It is enough to know that the structure of IKEv2 is fundamentally different from IKEv1.

If you're familiar with IT-security, then you will believe me that if digital signatures are used for authentication, it is not particularly good if an attacker can get a signature over attacker chosen data. We managed to develop an attack that exploits an IKEv1 Bleichenbacher oracle at some peer A to get a signature that can be used to break the IKEv2 authentication at another peer B. This requires that peer A reuses its key pair for IKEv2 also for IKEv1. For the details, please read our paper [alternative link to the paper].

Evaluation and Results

For testing the attack, we used a Cisco ASR 1001-X router running IOS XE in version 03.16.02.S with IOS version 15.5(3)S2. Unfortunately, Cisco's implementation is not optimized for throughput. From our observations we assume that all cryptographic calculations for IKE are done by the device's CPU despite it having a hardware accelerator for cryptography. One can easily overload the device's CPU for several seconds with a standard PC bursting handshake messages, even with the default limit for concurrent handshakes. And even if the CPU load is kept below 100 %, we nevertheless observed packet loss.

For the decryption attack on Cisco's IKEv1 responder, we need to ﬁnish the Bleichenbacher attack in 60 seconds. If the public key of our ASR 1001-X router is 1024 bits long, we measured an average of 850 responses to Bleichenbacher requests per second. Therefore, an attack must succeed with at most 51,000 Bleichenbacher requests.

But another limit is the management of Security Associations (SAs). There is a global limit of 900 Phase 1 SAs under negotiation per Cisco device in the default conﬁguration. If this number is exceeded, one is blocked. Thus, one cannot start individual handshakes for each Bleichenbacher request to issue. Instead, SAs have to be reused as long as their error counter allows. Furthermore, establishing SAs with Cisco IOS is really slow. During the attack, the negotiations in the first two messages of IKEv1 require more time than the actual Bleichenbacher attack.

We managed to perform a successful decryption attack against our ASR 1001-X router with approximately 19,000 Bleichenbacher requests. However, due to the necessary SA negotiations, the attack took 13 minutes.

For the statistics and for the attack evaluation of digital signature forgery, we used a simulator with an oracle that behaves exactly as the ones by Cisco, Clavister, and ZyXEL. We found that about 26% of attacks against IKEv1 could be successful based on the cryptographic performance of our Cisco device. For digital signature forgery, about 22% of attacks could be successful under the same assumptions.

Note that (without a patched IOS), only non-cryptographic performance issues prevented a succesful attack on our Cisco device. There might be faster devices that do not suffer from this. Also note that a too slow Bleichenbacher attack does not permanently lock out attackers. If a timeout occurs, they can just start over with a new attack using fresh values hoping to require fewer requests. If the victim has deployed multiple responders sharing one key pair (e. g. for load balancing), this could also be leveraged to speed up an attack.

Responsible Disclosure

We reported our ﬁndings to Cisco, Huawei, Clavister, and ZyXEL. Cisco published ﬁxes with IOS XE versions 16.3.6, 16.6.3, and 16.7.1. They further informed us that the PKE mode will be removed with the next major release.

Huawei published ﬁrmware version V300R001C10SPH702 for the Secospace USG2000 series that removes the Bleichenbacher oracle and the crash bugs we identiﬁed. Customers who use other affected Huawei devices will be contacted directly by their support team as part of a need-to-know strategy.

Clavister removed the vulnerable authentication method with cOS version 12.00.09. ZyXEL responded that our ZyWALL USG 100 test device is from a legacy model series that is end-of-support. Therefore, these devices will not receive a ﬁx. For the successor models, the patched ﬁrmware version ZLD 4.32 (Release Notes) is available.

FAQs

Why don't you have a cool name for this attack?
The attack itself already has a name, it's Bleichenbacher's attack. We just show how Bleichenbacher attacks can be applied to IKE and how they can break the protocol's security. So, if you like, call it IPsec-Bleichenbacher or IKE-Bleichenbacher.
Do you have a logo for the attack?
No.
My machine was running a vulnerable firmware. Have I been attacked?
We have no indication that the attack was ever used in the wild. However, if you are still concerned, check your logs. The attack is not silent. If your machine was used for a Bleichenbacher attack, there should be many log entries about decryption errors. If your machine was the one that got tricked (Responder A in our figures), then you could probably find log entries about unfinished handshake attempts.
Where can I learn more?
First of all, you can read the paper [alternative link to the paper]. Second, you can watch the presentation, either live at the conference or later on this page.
What else does the paper contain?
The paper contains a lot more details than this blogpost. It explains all authentication methods including IKEv2 and it gives message flow diagrams of the protocols. There, we describe a variant of the attack that uses the Bleichenbacher oracles to forge signatures to target IKEv2. Furthermore, we describe the quirks of Huawei's implementation including crash bugs that could allow for Denial-of-Service attacks. Last but not least, it describes a dictionary attack against the PSK mode of authentication that is covered in a separate blogpost.

Media Coverage, Blogs, and more

English

German

Saturday, January 27, 2024

Attacking Financial Malware Botnet Panels - SpyEye

This is the second blog post in the "Attacking financial malware botnet panels" series. After playing with Zeus, my attention turned to another old (and dead) botnet, SpyEye. From an ITSEC perspective, SpyEye shares a lot of vulnerabilities with Zeus.

The following report is based on SpyEye 1.3.45, which is old, and if we are lucky, the whole SpyEye branch will be dead soon.

Google dorks to find SpyEye C&C server panel related stuff:

if the img directory gets indexed, it is rather easy, search for e.g. inurl:b-ftpbackconnect.png
if the install directory gets indexed, again, easy, search for e.g. inurl:spylogo.png
also, if you find a login screen, check the css file (style.css), and you see #frm_viewlogs, #frm_stat, #frm_botsmon_country, #frm_botstat, #frm_gtaskloader and stuff like that, you can be sure you found it
otherwise, it is the best not to Google for it, but get a SpyEye sample and analyze it

And this is how the control panel login looks like, nothing sophisticated:

The best part is that you don't have to guess the admin's username ;)

This is how an average control panel looks like:

Hack the Planet! :)

Boring vulns found (warning, an almost exact copy from the Zeus blog post)

Clear text HTTP login - you can sniff the login password via MiTM, or steal the session cookies
No password policy - admins can set up really weak passwords
No anti brute-force - you can try to guess the admin's password. There is no default username, as there is no username handling!
Password autocomplete enabled - boring
Missing HttpOnly flag on session cookie - interesting when combining with XSS
No CSRF protection - e.g. you can upload new exe, bin files, turn plugins on/off :-( boring. Also the file extension check can be bypassed, but the files are stored in the database, so no PHP shell this time. If you check the following code, you can see that even the file extension and type is checked, and an error is shown, but the upload process continues. And even if the error would stop the upload process, the check can be fooled by setting an invalid $uptype. Well done ...

        if ($_FILES['file']['tmp_name'] && ($_FILES['file']['size'] > 0))         {                 $outstr = "<br>";                 set_time_limit(0);                 $filename = str_replace(" ","_",$_FILES['file']['name']);                 $ext = substr($filename, strrpos($filename, '.')+1);                 if( $ext==='bin' && $uptype!=='config' ) $outstr .= "<font class='error'>Bad CONFIG extension!</font><br>";                 if( $ext==='exe' && $uptype!=='body' && $uptype!=='exe' ) $outstr .= "<font class='error'>Bad extension!</font><br>";                  switch( $uptype )                 {                 case 'body': $ext = 'b'; break;                 case 'config': $ext = 'c'; break;                 case 'exe': $ext = 'e'; break;                 default: $ext = 'e';                 }                 $_SESSION['file_ext'] = $ext;                 if( isset($_POST['bots']) && trim($_POST['bots']) !== '')                 {                         $bots = explode(' ', trim($_POST['bots']));                         //writelog("debug.log", trim($_POST['bots']));                         $filename .= "_".(LastFileId()+1);                 }                 if( FileExist($filename) ) $filename .= LastFileId();                 $tmpName  = $_FILES['file']['tmp_name'];                 $fileSize = $_FILES['file']['size'];                 $fileType = $_FILES['file']['type'];                 ## reading all file for calculating hash                 $fp = fopen($tmpName, 'r');

Clear text password storage - the MySQL passwords are stored in php files, in clear text. Also, the login password to the form panel is stored in clear text.
MD5 password - the passwords stored in MySQL are MD5 passwords. No PBKDF2, bcrypt, scrypt, salt, whatever. MD5. Just look at the pure simplicity of the login check, great work!

$query = "SELECT * FROM users_t WHERE uPswd='".md5($pswd)."'";

ClickJacking - really boring stuff

SQL injection

SpyEye has a fancy history of SQL injections. See details here, here, here, video here and video here.

It is important to highlight the fact that most of the vulnerable functions are reachable without any authentication, because these PHP files lack user authentication at the beginning of the files.

But if a C&C server owner gets pwned through this vuln, it is not a good idea to complain to the developer, because after careful reading of the install guide, one can see:

"For searching info in the collector database there is a PHP interface as formgrabber admin panel. The admin panel is not intended to be found on the server. This is a client application."

And there are plenty of reasons not to install the formgrabber admin panel on any internet reachable server. But this fact leads to another possible vulnerability. The user for this control panel is allowed to remotely login to the MySQL database, and the install guide has pretty good passwords to be reused. I mean it looks pretty secure, there is no reason not to use that.

CREATE USER 'frmcpviewer' IDENTIFIED BY 'SgFGSADGFJSDGKFy2763272qffffHDSJ';

Next time you find a SpyEye panel, and you can connect to the MySQL database, it is worth a shot to try this password.

Unfortunately the default permissions for this user is not enough to write files (select into outfile):

Access denied for user 'frmcpviewer' (using password: YES)

I also made a little experiment with this SQL injection vulnerability. I did set up a live SpyEye botnet panel, created the malware install binaries (droppers), and sent the droppers to the AV companies. And after more and more sandboxes connected to my box, someone started to exploit the SQL injection vulnerability on my server!

63.217.168.90 - - [16/Jun/2014:04:43:00 -0500] "GET /form/frm_boa-grabber_sub.php?bot_guid=&lm=3&dt=%20where%201=2%20union%20select%20@a:=1%20from%20rep1%20where%20@a%20is%20null%20union%20select%20@a:=%20@a%20%2b1%20union%20select%20concat(id,char(1,3,3,7),bot_guid,char(1,3,3,7),process_name,char(1,3,3,7),hooked_func,char(1,3,3,7),url,char(1,3,3,7),func_data)%20from%20rep2_20140610%20where%20@a=3%23 HTTP/1.1" 200 508 "-" "Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)"

Although the query did not return any meaningful data to the attacker (only data collected from sandboxes), it raises some legal questions.

Which company/organization has the right to attack my server?

police (having a warrant)
military (if we are at war)
spy agencies (always/never, choose your favorite answer)
CERT organisations?

But, does an AV company or security research company has the legal right to attack my server? I don't think so... The most problematic part is when they hack a server (without authorization), and sell the stolen information in the name of "intelligence service". What is it, the wild wild west?

The SQLi clearly targets the content of the stolen login credentials. If this is not an AV company, but an attacker, how did they got the SpyEye dropper? If this is an AV company, why are they stealing the stolen credentials? Will they notify the internet banking owners about the stolen credentials for free? Or will they do this for money?

And don't get me wrong, I don't want to protect the criminals, but this is clearly a grey area in the law. From an ethical point of view, I agree with hacking the criminal's servers. As you can see, the whole post is about disclosing vulns in these botnet panels. But from a legal point of view, this is something tricky ... I'm really interested in the opinion of others, so comments are warmly welcome.

On a side note, I was interested how did the "attackers" found the SpyEye form directory? Easy, they brute-forced it, with a wordlist having ~43.000 entries.

(Useless) Cross site scripting

Although parts of the SpyEye panel are vulnerable to XSS, it is unlikely that you will to find these components on the server, as these codes are part of the install process, and the installer fails to run if a valid install is found. And in this case, you also need the DB password to trigger the vuln...

Session handling

This is a fun part. The logout button invalidates the session only on the server side, but not on the client side. But if you take into consideration that the login process never regenerates the session cookies (a.k.a session fixation), you can see that no matter how many times the admin logs into the application, the session cookie remains the same (until the admin does not close the browser). So if you find a session cookie which was valid in the past, but is not working at the moment, it is possible that this cookie will be valid in the future ...

Binary server

Some parts of the SpyEye server involve running a binary server component on the server, to collect the form data. It would be interesting to fuzz this component (called sec) for vulns.

Log files revealed

If the form panel mentioned in the SQLi part is installed on the server, it is worth visiting the <form_dir>/logs/error.log file, you might see the path of the webroot folder, IP addresses of the admins, etc.

Reading the code

Sometimes reading the code you can find code snippets, which is hard to understand with a clear mind:

$content = fread($fp, filesize($tmpName)); if ( $uptype === 'config' )     $md5 = GetCRC32($content); else $md5 = md5($content); .... <script> if (navigator.userAgent.indexOf("Mozilla/4.0") != -1) {         alert("Your browser is not support yet. Please, use another (FireFox, Opera, Safari)");         document.getElementById("div_main").innerHTML = "<font class=\'error\'>ChAnGE YOuR BRoWsEr! Dont use BUGGED Microsoft products!</font>"; } </script>

Decrypting SpyEye communication

It turned out that the communication between the malware and C&C server is not very sophisticated (Zeus does a better job at it, because the RC4 key stream is generated from the botnet password).

function DeCode($content) {         $res = '';         for($i = 0; $i < strlen($content); $i++)         {                 $num = ord($content[$i]);                 if( $num != 219) $res .= chr($num^219);         }         return $res; }

Fixed XOR key, again, well done ...

This means that it is easy to create a script, which can communicate with the SpyEye server. For example this can be used to fill in the SpyEye database with crap data.

import binascii import requests import httplib, urllib  def xor_str(a, b):     i = 0     xorred = ''     for i in range(len(a)):         xorred += chr(ord(a[i])^b)     return xorred              b64_data= "vK6yv+bt9er17O3r6vqPnoiPjZb2i5j6muvo6+rjmJ/9rb6p5urr6O/j/bK+5uP16/Xs7evq9ers7urv/bSo5u316vXs7evq/a6v5pq/trK1/bi4qbjm453j6uPv7Or9tr/u5um+uuvpve3p7eq/4+vsveLi7Lnqvrjr6ujs7rjt7rns/au3vOa5sre3srW8s7q2tr6p4Lm3tLiw4LmuvKm+q7Spr+C4uPu8qbq5ub6p4Li4vKm6ubm+qeC4qb6/sq+8qbq54LiuqK+0tri0tbW+uK+0qeC/v7So4L+1qLqrsuC+trqyt7ypurm5vqngvb24vqmvvKm6ubm+qeC9/aivuq/mtLW3srW+" payload =xor_str (binascii.a2b_base64(b64_data), 219)  print ("the decrypted payload is: " + payload) params = (binascii.b2a_base64(xor_str(payload,219))) payload = {'data': params} r = requests.post("http://spyeye.localhost/spyeye/_cg/gate.php", data=payload)

Morale of the story?

Criminals produce the same shitty code as the rest of the world, and thanks to this, some of the malware operators get caught and are behind bars now. And the law is behind the reality, as always.

One Reason Why InfoSec Sucked In The Past 20 Years - The "Security Tips" Myth

From time to time, I get disappointed how much effort and money is put into securing computers, networks, mobile phones, ... and yet in 2016 here we are, where not much has changed on the defensive side. There are many things I personally blame for this situation, and one of them is the security tips.

The goal of these security tips is that if the average user follows these easy to remember rules, their computer will be safe. Unfortunately, by the time people integrate these rules into their daily life, these rules either become outdated, or these rules were so oversimplified that it was never true in the first place. Some of these security tips might sound ridiculous to people in InfoSec nowadays, but this is exactly what people still remember because we told them so for years.

PDF is safe to open

This is an oldie. I think this started at the time of macro viruses. Still, people think opening a PDF from an untrusted source is safer than opening a Word file. For details why this is not true, check: https://www.cvedetails.com/vulnerability-list/vendor_id-53/product_id-497/Adobe-Acrobat-Reader.html

On an unrelated note, people still believe PDF is integrity protected because the content cannot be changed (compared to a Word document).

Image stolen from Kaspersky

Java is secure

One of the best ones. Oracle started marketing Java as a safe language, where buffer overflows, format strings and pointer-based vulnerabilities are gone. Unfortunately, they forgot to tell the world that instead of "unsafe programs developed by others" they installed their unsafe program on 3 billion devices.

Stay away from rogue websites and you will be safe

This is a very common belief I hear from average people. "I only visit some trusted news sites and social media, I never visit those shady sites." I have some bad news. At the time of malvertising and infected websites, you don't have to visit those shady sites anymore to get infected.

Don't use open WiFi

I have a very long explanation of why this makes no sense, see here. Actually, the whole recommendation makes no sense as people will connect to public WiFis, no matter what we (InfoSec) recommend.

The password policy nightmare

Actually, this topic has been covered by myself in two blog posts, see here and here. Long story short: use a password manager and 2-factor authentication wherever possible. Let the password manager choose the password for you. And last but not least, corporate password policy sux.

Sites with a padlock are safe

We tell people for years that the communication with HTTPS sites are safe, and you can be sure it is HTTPS by finding a randomly changing padlock icon somewhere next to the URL. What people hear is that sites with padlocks are safe. Whatever that means. The same goes for WiFi - a network with a padlock is safe.

Use Linux, it is free from malware

For years people told to Windows users that only if they would use Linux they won't have so much malware. Thanks to Android, now everyone in the world can enjoy malware on his/her Linux machine.

OSX is free from malware

It is true that there is significantly less malware on OSX than on Windows, but this is an "economical" question rather than a "security" one. The more people use OSX, the better target it will become. Some people even believe they are safe from phishing because they are using a Mac!

Updated AV + firewall makes me 100% safe

There is no such thing as 100% safe, and unfortunately, nowadays most malware is written for PROFIT, which means it can bypass these basic protections for days (or weeks, months, years). The more proactive protection is built into the product, the better!

How to backup data

Although this is one of the most important security tips which is not followed by people, my problem here is not the backup data advise, but how we as a community failed to provide easy to use ways to do that. Now that crypto-ransomware is a real threat to every Windows (and some OSX) users, even those people who have backups on their NAS can find their backups lost. The only hope is that at least OSX has Time Machine which is not targeted yet, and the only backup solution which really works.

The worst part is that we even created NAS devices which can be infected via worms ...

Disconnect your computer from the Internet when not used

There is no need to comment on this. Whoever recommends things like that, clearly has a problem.

Use (free) VPN to protect your anonimity

First of all. There is no such thing as free service. If it is free, you are the service. On another hand, a non-free VPN can introduce new vulnerablities, and they won't protect your anonymity. It replaces one ISP with another (your VPN provider). Even TOR cannot guarantee anonymity by itself, and VPNs are much worse.

The corporate "security tips" myth

"Luckily" these toxic security tips have infected the enterprise environment as well, not just the home users.

Use robots.txt to hide secret information on public websites

It is 2016 and somehow web developers still believe in this nonsense. And this is why this is usually the first to check on a website for penetration testers or attackers.

My password policy is safer than ever

As previously discussed, passwords are bad. Very bad. And they will stick with us for decades ...

Use WAF, IDS, IPS, Nextgen APT detection hibber-gibber and you will be safe

Companies should invest more in people and less into magic blinking devices.

Instead of shipping computers with bloatware, ship computers with exploit protection software

Teach people how to use a password safe

Teach people how to use 2FA

Teach people how to use common-sense

Conclusion

Computer security is complex, hard and the risks change every year. Is this our fault? Probably. But these kinds of security tips won't help us save the world.

More information