pondělí 23. prosince 2019

Život na vedlejších efektech

Znáte tu situaci, když nějaký produkt používáte způsobem, jak nebyl zamýšlen? Někdy se jeho nedostatky dokonce stanou žádoucí vlastností? Asi jako v komisku XKCD workflow:

XKCD workflow

Já to tak mám často, uvedu pár příkladů.

Kdysi dávno jsme v počítači měli disk, který nejen vydával hluk, když se točil, ale ještě k tomu vydával specifický výrazný hluk, když disk zrovna něco četl nebo zapisoval. Nový disk pak sice měl větší kapacitu, ale bohužel postrádal tuto užitečnou zvukovou signalizaci, na kterou jsem si zvykl.

Na telefonu Nokia 3120 snad nebylo možné bez odemčení kláves rozsvítit displej. Teda bylo. Stačilo napsat některé z vybraných nouzových čísel, jako například 112 nebo 911. Asi není moudré pro tyto účely používat místní nouzové číslo 112 (kdybych to omylem vytočil), ale naštěstí telefon takto z nějakého důvodu reagoval i na číslo 08. Stiskem další číslice jsem pak zrušil psaní nouzového čísla. Takže jsem používal sekcenci 080, abych zkontroloval stav telefonu. Bylo to praktické, protože 0 a 8 jsou poblíž.

Na touchpadu jsem si kdysi aktivoval emulaci multitouch. Potom systém například plochu palce bral jako dva prsty, což mi přišlo velice praktické. Bohužel jsem byl v tomto vnímání asi osamocen a novým notebookem jsem o tuto praktickou vlastnost přišel.

V autoškole jsem se naučil řídit starou Fabii 1.9 SDI skoro bez dívání na budíky. Rychlost odhadnu podle převodu a otáček. A na otáčky je tu „zvukový otáčkoměr“. Jenže, pokud budu mít relativně moderní auto, bude mít nejspíš příliš tichý motor…

Naštěstí tento problém až tak řešit nemusím. Asi vás nepřekvapí, že cílem autoškoly nebylo stát se řidičem…

pátek 4. října 2019

A non-technical aspect of security – how could I have prevented the 2014 Jabbim password leak?

The 2014 Jabbim breach has happened almost five years ago, but there is still one interesting information to reveal. It is something I am not much proud of, but we can learn from both my mistake and Jabbim's mistake.

My experience with a past vulnerability report

Some time before the breach (2013-11-21), I had reported some seemingly unrelated vulnerability. Well, it was also an SQL injection, but on a different place. Moreover, just a script crash there had some unexpected consequences:

  1. Some part of the DB remained locked.
  2. This has caused many script waiting for releasing the lock.
  3. As many web scripts were waiting, the server has reached the fork limit. As far as I remember, it was unable to serve even static files.

Maybe you can imagine what happened. Without having an idea that the status icon script is backed by a SQL database and without any bad intentions, just putting an apostrophe in the url accidentally caused an SQL injection and subsequent webserver crash.

I had good intentions, so I promptly reported the issue to admins. The reaction was like “Thank you for crashing our server. I could have been at home right now.”. Well, they fixed the issue, but my feeling from the communication was not much good.

My report of the vulnerability abused in the breach

The same day, I had also discovered another SQL injection vulnerability – in user search. That is, the same vulnerability that was abused in the 2014 breach. I also reported it, but I decided to contact another (hopefully more friendly) admin. However, I was just told about not having enough time for handling it.

So, I was about to report it to the unpleasant admin. He was offline that time, so I had to wait. When waiting, I started thinking about giving a report that demonstrates the danger but stands in limits of white-hat hacking.

However, this takes some time. As I was doing this in my free time for my fun and someone's else profit, I did not have enough time for making the report perfect. I needed to do some other duties, maybe something school-related. So, I postponed it for indefinite amount of time and you know the result… I am really sorry for that.

What could have been done better from the reporter side?

Although I would not describe me as a perfectionist, I admit I sometimes have some perfectionistic traits in a limited way. That said, I am not perfect at avoiding perfectionism. But “perfect” is an enemy of “done”. I could have opted for a trade-off – to try to make the report perfect until some deadline. Once the deadline passes, I would report it in however imperfect form.

What could have been done better from the admin side?

This is much related to the first vulnerability report.

  • Do not discourage white hats: While I understand that a vulnerability report might be something unpleasant to handle in general, they could have responded in a more kind way. I believe it was obvious I had no bad intentions and tried to behave as responsibly as possible.
  • Encourage white hats: There are some companies that even reward vulnerability reports and/or put your name to a hall of fame. If vulnerability rewards are expensive, you still can have a hall of fame, like some companies (even Google) have.
  • Have a contact for reporting of security issues. It is also a good idea to have security.txt file, but it should not be the only way to contact responsible persons. (I know, security.txt has started in 2017, so they could not have it. But today, it is a good idea to have one.)
  • When you receive a vulnerability report but you are not the right person to handle it, forward it to someone responsible as soon as possible.