In the last few days there was another hack. 45 million accounts stolen, weak cyphers and decrypted passwords. With Linkedin, MySpace (discovered after years!), Adobe, VK and too many others, according to website haveibeenpwned.com we are above 1 BILLION accounts stolen. It is a real, really big problem. There’s something simply not working with all of this. And I’m just tired of hearing “Never user the same password on different accounts”, it is just plain crazy to have to remember something like 200 passwords, one for every account I have. Moreover, nowadays every fucking website wants you to create an account, and you cannot use their service without it.

Well, let’s start from here.

Why do you need an account? A fairly general reason is to assure that you are allowed to use the service. Maybe you have to pay, or maybe, like in a blog, only few or one person can access a management console. What’s the general rule? YOU HAVE TO IDENTIFY YOURSELF. User and password is a simple way to prove to the website that is really you that is trying to access that reserved area. The concept at the bases is the identity.

How can you prove your identity? Remember, the process to prove an identity implies that there’s someone else besides you, that this someone knows something about you, and that this something is sufficient to prove that you is really you.

Philosophically, as I found in information technology studies, there are only 3 ways to prove it: show something you know, show something you have, show something you are. This is the base, from here we can build up.

Just as an example, imagine for a moment an old world, a world before the digital era. Imagine, let’s say, a military camp in times of war. A messenger comes in, he says he’s bringing new orders from the general. How can the commander of the camp be sure that he is really a messenger and not an enemy spy, bringing false orders? Well, one way could be a set of words, or phrases, chosen before the separation of the two contingent, kept well guarded, known only to the commanders and the messengers. It’s not very foolproof, a man could be captured and tortured to say that password – something the messenger knows. Another way is to show the message: it should be sealed with the unique seal and maybe wax of the general. The symbol of the seal must be well known and difficult to reproduce; moreover the handwriting and the sign could be used if they are well known – something the messenger has. One last way, to be way more sure, is to find someone in the camp that recognizes the messenger, maybe someone that served with him in another camp – something he is.

These are just three examples; maybe it could happen something else, but it will inevitably fall within one (or more) of these three categories. A savvy commander would probably prefer to have all three proofs, if possible.

Let’s come back to our dangerous digital era, and access to Facebook. First thing, you write your username, that is who you claim you are. Now you have to prove that is really you trying to access, so you enter your very difficult password. You are writing something you know. Then you remember that you’re at work, so to start working you have to log to the corporate network plugging in your PC your security token  – something you have. You have to go to the bathroom, so you lock your PC; when you come back, to unlock it you use Windows Hello, a facial recognition system – something you are.

In the military camp example I introduced another concept: the trusted third party. It is the soldier who knows the messenger. Let’s expand with another example: like in the best movies, a New York criminal wants to trade drugs. He has to buy it from some Chinese mafia member that he doesn’t know and doesn’t trust. What does he do? He contacts a local politician that knows both – and obviously can reassure both parts that they aren’t police under cover or something else. The important part for this article is that the New York criminal trusts the politician, and that the politician knows the chinese.

Coming again in our incredibly dangerous digital world, we do (or better, the browser does) the same as above when we visit an HTTPS website. We don’t know if PayPal website is really PayPal and not some phishing attempt, but Symantec, a well known and trusted antivirus producer and certification authority, says that it is really PayPal, and we trust them.

Now we have a general view of all the basic concepts on how to prove our identity. Passwords in today’s world are largely the most used method, basically because it is very simple to implement and because it can be managed only on the website side: there’s no need for special devices to read fingerprints or cards and card readers. There are a lot of other reasons, I’ll talk about them in the next article. Anyway, when we go to into the web, a password it is also most easily broken by persons – or programs – that pretends to be you.

 

MORE IN DEPTH

  • https://www.cs.cornell.edu/courses/cs513/2005fa/nnlauthpeople.html
  • http://www.csoonline.com/article/2976884/data-protection/maybe-it-s-time-to-eliminate-something-you-know-as-an-authentication-method.html
  • http://security.stackexchange.com/questions/69195/why-is-something-you-know-the-weakest-factor-of-authentication

New HTTPS vulnerability: DROWN

by admin on

Another known attack to old SSLv2 … Welcome, if I can say so, to Decrypting RSA with Obsolete and Weakened eNcryption, a.k.a. DROWN .

To Windows Server (2008 up) users, if you didn’t mess too much around with registry keys, SSLv2 should be already disabled.

To Linux/Unix users, you should disable SSLv2 and, if you didn’t already, update OpenSSL to one of the most recent versions. It seems that are vulnerable only versions older than march 2015.

I wouldn’t signore this vulnerability, for,as I understood, it exposes you private key for HTTPS encryption in a very limited amount of time – 8 to 16 hours or even less.

So please disable SSLv2 and check that TLS is not using it for legacy support.

For more information regarding DROWN vulnerability, read this excellent (even if a little technical) article from ArsTechnica.com:

More than 11 million HTTPS websites imperiled by new decryption attack

On Debian systems, sometimes I find that cron can give some problems. Not regarding the scheduling in itself; more of the process.

Lately I found this error in /var/log/messages:

repeated countless times, usually 1 message per second. This means that there is already a pid file locking the execution of the process, but since another cron is trying to start, probably there’s a problem: maybe previous process crashed so that it couldn’t delete its pid, or previous process is not responding (even if it is still running), or previous process is running correctly but something is trying to start another instance.

Following there’s a solutions I found for each case. The cause is usually too system dependant to be useful to discuss.

List of Solutions

CRON crashed

One possible scenario is that cron crashed (probably because of a script you wrote that made it crash or because of a syntax error in cron files). You can check and resolve this case by executing these commands:

this will tell you if there’s a process running with the above pid (the otherpid of the error). If there isn’t any process running, the above command should return nothing. In this case, you can delete the pid file and check if process can start without errors:

CRON is stuck

This is probably the simplest – and at least in my case – most frequent error. I have a lot of cron jobs doing lots of automatic operations. In a couple of system, sometimes I see the error above; one of my jobs is stuck, blocking cron – something like it can’t go on with operations. Automatically the system tries to restart cron, but it can’t, so I see the error above. Errors like these can be extremely tricky to debug – they happens 3 or 4 times a YEAR, so maybe is not worth the time to find the real cause.

Anyway – the solution is extremely simple in this case: kill the offending process.

Then what is trying to start the process again should immediatly restart it correctly.

To check if it worked run below commands:

If you see again the error in the title, this wasn’t the problem. You can try to restart the process (/etc/init.d/cron restart) but in my experience it didn’t solve the problem.


For the last case, I don’t know at the moment if there is a more common case. It seems to me that a mechanism that tries to restart cron once a second while the official one is running must be a custom one or a linux internal one – possibly with some sort of strange bug. But I don’t know for sure.

More In Depth

Above I said that the second but is not worth solving. Well, I hate leaving processes with known bugs, but I had to give up to similar bugs. If they are very rare, appears at random times, and causes relatively few damage, the cost in time to track down and solve those bugs may be too high to be worth the solution.

To be honest, sometimes in my (limited) experience, I spent at least a month (in total) hunting for a problem like the above, never to find a real solution and experiencing only a minor annoyance. In the end, the server reached its end of life and was migrated. I never really understood what was happening, but in fact the problem disappeared in the new server. So, in fact, the month I spent on this bug was just a big waste of time; and it is something I don’t want to do again.

Well, another of those absurd, incredible, unbelievable bugs. The ones that break your day and make you lose time, energy and ruins your mood, all for some sloppy programmer – or for an all-too-complicated environment.

Brief explanation of the situation:

  • I have a host with ESXi 5.1 with several virtual machines
  • There’s a PfSense firewall in a virtual machine in front of everything, connected to the only switch with internet access.
  • Within vSphere I created various vSwitch not connected to any physical network interface, to manage various network zones.
  • I attached a virtual network interface to the firewall for each vSwitch, so to manage with the firewall various zones and allow them to selectively connect to each other and to internet.

One beautiful day I had to create a new network area. This is not a tutorial to add a new vSwitch, so I’ll assume you know how to do it.

After creating it, I added the new interface to the virtual machine, then I added it to the firewall itself. For the moment this isn’t a mission critical server, so I decided to restart the firewall.

Then, BOOOOOOOM!!!! I couldn’t access to any of the servers behind the firewall. ANY!  Strangely, I could access to the firewall and through some tricks directly to vSphere. From the firewall I tried to ping the VMs – nothing. From the VMs I tried to access the firewall – nothing. The firewall was broadcasting ARP requests; the VMs told me the host was down.

At first I thought was something related to ESXi. Then I found that I could ping VM to VM behind the firewall, although couldn’t access internet or the firewall. So maybe it isn’t a vSphere problem but a virtual machine problem. But then I checked the configuration of the firewall and everything seemed to be ok.

So I thought: “Maybe is something in the configuration of the virtual machine!” – so I checked, and I noticed something very strange. NETWORK INTERFACE NAMES WERE IN THE WRONG ORDER.

Let me explain. When you add network interfaces in this way, the appearance seems to follow a first-add-first-appear rule, or maybe an alphabetical order. This time, last interface added wasn’t the last one in order, and surely it wasn’t alphabetical order. So a doubt occurred to me. Maybe something messed up the association MAC Address – vSwitch?

I checked the MAC Address – Network Zone in the firewall with the ones in the Virtual Machine configuration, and that was the case. As soon as I switched Network Zones in the VM configuration to match with the one in the firewall, everything worked correctly again.