Beating 2-Factor Authentication

I can imagine how it goes.

The provider implements 2FA to its clients, using text messages only.

Clients adopt it. Then, clients claim they are not getting the text messages.

Business asks for IT: “Please, improve the 2FA system, texts messages are not enough”
IT thinks: “Ok, we can call the client if text messages are not working. Should we submit this system change to CSO approval?”
Business answers “No, it will delay the process and it is only a minor change”.

The rest of story is below.


Vulnerability Monster Reports? You are a Tool!

If you have a scanner to search your entire network for problems, know this:

1 – The scanner is not the Oracle. No matter how much you trust the vendor, you can’t just send 16.000 “high” vulnerabilities to your IT department, without any kind of relevance classification, expecting they are going to read;

Dr Scanner Evil

2 – If you do this, you are just “washing your hands” and preparing an idiot line like “my last report had this warning to you and nothing was done!” in case something bad happens. Plus, if a breach really does happen, you are not likely to be informed, because the CIO is not going to feed you with rocks to break his own window;

3 – Scanners have some kind of False Positives list. USE IT. This could reduce a lot of that 500 Mb pdf you intend to send;

4 – If you are too coward to pick a vulnerability out of 16.000 and classify it as bullshit not relevant, then everybody else in your company will know you have Zero Knowledge to do vulnerability management;

5 – Choose an application with real severe problems, not those with “too many problems in the report” before asking IT for an action. People will know you are being driven by numbers and they will put almost no effort on testing a new package to minimize amounts in a report;

6 – Don’t use Pivot Tables or Count functions to determine which problem you want to attack first, otherwise, again, you are a slave for numbers. This is not vulnerability management;

7 – If you can’t read blogs and research sites looking for exploits, and when you do, you can’t figure which exploit is suitable for your environment, then you will never be able to call a problem as relevant or classify anything;

8 – Bring the IT teams to your side by explaining with technical details why you would like to test and install that patch to all computers. Be ready to defend your idea with real arguments, not using F.U.D;

9 – If after all of the above tips, you are still planning to keep your way of work, be sure your network is about to be or is already exploited;

10 – Finally, if you think breaches are an IT problem as long as you reported all possible holes with your monster list, you should really start to consider another career away from Information Security.

Did I say anything wrong or obtuse? Write your thoughts below. I’ll be happy to read your ideas!

Not you, Linux!

Linux 2.6.x, 3.x, Ubuntu 10, 11, 12, all vulnerable to a race condition within ptrace.

Linux 3.3 to 3.8 vulnerable at netlink messages.

C’mon, Penguin, we always had you as the strongest brother. If you start getting sick, people would get really scared. I mean, zombie apocalypse style.

Edit 1: the race condition / ptrace has some workarounds, that would give you sometime before that “simple” Update-Kernel task… Hiding your Linux from Internet direct connections (could be hard, in some cases) and using strong authentication to all accounts with tokens (could be even harder, plus $$$).