Michal Čihař - Archive for Jan. 1, 2008

Do phpMyAdmina chtějí protlačit podporu pro jeden autentizační token. Jak tato věc funguje na hardwarové úrovni nevím (má tam být nějaký autentizační kalkulátor, který na výzvu vygeneruje nějakou unikátní odpověď), ale docela mě pobavil přístup k bezpečnosti softwarového řešení okolo. Celá popisovaná věc se jmenuje Swekey a stojí za ním firma Musbe, založená jen kvůli tomuto zařízení ( to develop and market an innovative authentication technology ).

Token se strká do USB (v dnešní době to asi ani jinak nejde) a celou věc obsluhuje v Linuxu jakási binárka komunikující s tokenem přes libusb. No aspoň, že to bude hnít v userspace a ne v kernelu. Bohužel pokud to chcete použít na něčem jiném než i386, máte smůlu. Protože nám se jedná o autentizaci webové aplikace, máme ještě k dispozici další binárku a to plugin do prohlížeče Firefox (pro Windows případně ještě ActiveX pro MSIE).

Když už se uživateli poštěstí toto rozběhat (a nebude řešit takové nepodstatné otázky, jako třeba: proč binárka obsluhující ten token musí používat curl?), může vyzkoušet úžasné možnosti, které nám tato autentizace skýtá. A hlavně se podívat na kód, který se o autentizaci stará, protože ten již k dispozici máme. Kromě phpMyAdmina, kde je jakási meziverze už v SVN, ještě existuje plugin pro SquirrelMail a prý i patch pro RoundCube, modul pro PAM atd.

Jak vlastně celá věc funguje?

1. Načte se ID z USB tokenu
2. Ze serveru se stáhne náhodný token (platný dvě minuty)
3. Náhodný token se nacpe do USB tokenu a ten vygeneruje OTP (jednorázové heslo)
4. ID tokenu, náhodný token a OTP se pošle na server a ten je ověří

No vypadá to celkem jednoduše, tož pojďme se podívat jak to soudruzi naimplementovali. Podotýkám, že v patchi pro phpMyAdmin, už pomaly níže popsané problémy mizí, ale za cenu víceméně kompletního přepsání kódu, jak se (ne)budou vyvíjet patche/pluginy pro ostatní programy netuším, nicméně autoři pořád někde preferují původní řešení.

Komunikace

První věc, která kohokoliv musela praštit do očí bylo použití nešifrovaného HTTP spojení při komunikaci se serverem. Což ve spojení s jednoduchým až triviální protokolem, znamená, že kdokoliv, kdo je schopný na jakýkoliv HTTP požadavek odeslat odpověď "HTTP/1.0 200 OK\n\nOK" se může stát autentizačním serverem, který autentizuje cokoliv komukoliv. Soudruzi sice v patchi pro phpMyAdmina přešli na HTTPS s ověřováním certifikátu, ale z výkonnostních důvodů jinde zůstane nadále HTTP. Vskutku inovativní řešení.

Umístění souborů

Mapování tokenů na uživatele mělo být umístěno v kořenovém adresáři phpMyAdmina a tedy přístupné přes web. Což ve spojení s předhozí zranitelností znamená, že jediná informace, kterou by případný útočník potřeboval - ID klíče, který mu dovolí přístu, může bez problémů získat napsáním správného URL.

Dočasné soubory

Protože náhodný token je platný dvě minuty, rozhodli se autoři ušetřit námahu jejich serveru s generováním a tento token cachovat. Bohužel ukládat pevně pojmenovaný soubor do adresáře /tmp není zrovna nejlepší nápad a už vůbec není dobrý nápad tento soubor vytvářet s právy 777 . Co by se asi stalo, kdyby náhodný uživatel na serveru do tohoto souboru uložil třeba nějaký film a ten se následně začal odesílat na jejich server jako náhodný token při autentizaci?

No nechtějte to

Většina zde zmíněných problémů existuje ve všech implementacích tohoto tokenu, do kterých jsem se koukal. Kromě toho každá implementace přidává spoustu unikátních programátorských chyb. Zájemcům o pobavení se doporučuji modul pro PAM, který je vlastně jen spouštěč skriptu v bashi, který volá curl a komunikuje se serverem.

Update

Při psaní tohoto článečku mě napadl ještě jeden problém, kterým to asi bude trpět, ale nechtěl jsem to psát dokud to neověřím, což se právě stalo. Přístup k tokenu z prohlížeče není pluginem nijak omezován, takže jakákoliv stránka může zjistit ID vašeho tokenu a vygenerovat si OTP heslo. No lepší podmínky pro krádež identity si už lze představit jen těžko :-).

Zase další krátký povzdech, po včerejším stěžování si na poštu :-). Včera jsem byl nucen poprvé od "reformy" navštívit lékaře. Kupodivu poplatek chtěli až na konci a ne jako první věc při vstupu do ordinace, jak jsem od mnoha známých slyšel :-).

Nicméně co mě neustále na mojí praktické doktorce překvapuje, je tradiční dotaz jestli jsem alergický na nějaká antibiotika. To už by sakra za tu dobu co tam chodím mohla vědět, ne? Obzvlášť, když v podstatě vždycky, kdy už mi je tak blbě, že tam zajdu, to těmi antibiotiky skončí...

I had to do it once and now the time came. Floating around hundredths of unread mails for Gammu is not a way to go. I'm just middle of processing it, but most of you will get just generic reply, asking you to either file bug report to bug tracker or to write to mailing list. There is simply no reason why so much communication should be private between me and you. I think this is generally valid for any open source project, it usually does not make sense contact main developer directly when there are more appropriate ways to communicate.

If you find a bug or something does not work, simply report it! If you can search for duplicates before it is even better and you might be able to include some additional information, but even if you skip this step, it is much easier to track problems in bug tracker than in mailbox. Also in bug tracker the issue will not disappear until it is not fixed, in mailbox, it gets quickly out of focus and I will forget it.

Once more: If you've found a bug, report it!

If you have some question, you have much better chance to receive answer on mailing list. Simply there are more people hanging around and somebody might have already seen the problem. What is another good thing on mailing list is that they have archives, so that you can look whether somebody did not solve similar problem before. Also others will be then able to find your solution.

Summary again: If you have a question, ask on mailing list!

Už jsem se České poště nechtěl nikdy věnovat, ale prostě to co jsem viděl dnes při odchodu z domu se nedá nekomentovat.

Víte jak vypadá doručování doporučených dopisů podle České pošty? Položí se na rozvaděč vedle vchodu :-).

I just commited to phpMyAdmin trunk (will be released once as 3.1) few small patches, but the change is quite important - phpMyAdmin will now default to cookie authentication method and it will not allow to login as root user without password (unless it is explicitly enabled in configuration).

Reasons for both changes are simple - most people change default authentication to cookie in production environment anyway, so why not to make it default and giving remote access to freshly installed MySQL server has been always considered a bit security issue. Well it was an user problem, but why not to prevent such issues?

Tak jsem si nějak povšimnul, že veškeré moje maily, odeslané na nejmenovaný největší český freemail, skončí jako spam. Kupodivu u jiných příjemců se tento problém nevyskytuje, tak to asi nebude úplně triviální problém a stojí za prozkoumání.

Posílám si tedy mail na jedno z nepoužívaných kont, které tam mám a v hlavičkách vidím X-Spam-Status: score=14.2 . No to je celkem slušné skóre, co za to asi může? Že by se tomu nelíbila moje adresa michal@cihar.com? Změna odesílatele na cosi@email.cz a hle, už mám jenom X-Spam-Status: score=8.2 . Bohužel pořád dost na to aby to skončilo ve spamu.

Jako první mě samozřejmě napadl nějaký obskurní blacklist, ale jakékoliv online nástroje pro kontrolu blacklistů mi potvrzují, že můj server na žádném není, tak v tom snad problém nebude. Zkouším ještě poslat mail přímo ze serveru a najednou to projde ... tak že by se kontrolovaly Received hlavičky oproti blacklistům?

Vložení Received s IP adresou přes kterou se připojuju (kabelovka, NAT pro nepočítaně lidí, takže nejspíš je na všech možných i nemožných blacklistech) opravdu způsobí onen závratný růst skóre. Proč má jediná hlavička takový vliv netuším, ale jediná moje možnost je přenastavit si mailserver aby tyto adresu maskoval.

Naštěstí nalezení návodu pro Exim je otázkou jednoho dotazu na pana Googla a změna je na světě:

 received_header_text = Received: \
  ${if def:sender_rcvhost {from ${if def:authenticated_id \
  {127.0.0.1 (helo=authenticated.user.fuck.seznam)} \
  {$sender_rcvhost}}\n\t}\
  {${if def:sender_ident \
  {from ${quote_local_part:$sender_ident} }}\
  ${if def:sender_helo_name {(helo=$sender_helo_name)\n\t}}}}\
  by $primary_hostname \
  ${if def:received_protocol {with $received_protocol}} \
  ${if def:tls_cipher {($tls_cipher)\n\t}}\
  (Exim $version_number)\n\t\
  ${if def:sender_address \
  {(envelope-from <$sender_address>)\n\t}}\
  id $message_exim_id\
  ${if def:received_for {\n\tfor $received_for}}

O tom nakolik je takovéto chování od mailserveru korektní spekulovat nebudu a názor si vytvořte sami.

I was today just too lazy to do much actual work, but I spend time on playing with something new - this time it was Google Chart API or better Python Google Chart module. I wanted to have some visualisation of growth of data in Gammu phone database for a long time and this module seemed to be good way to achieve good charts.

After a bit of playing I got following chart:

What we can see from it? Number of garbage grows very fast. Mostly it is caused by Wammu, which asks user for feedback after some time of active usage and this sometimes leads to duplicate records (but it also brings information which phones are really being used).

The bad thing which is visible here is that mostly half of reports is about unsupported phones! I think we should do something about this as the reality is not really that bad and from my POV, most of failure reports are caused by wrong configuration being used. I know it is sometimes tricky to find working one especially when you use Nokia phone with cable, where exists simply too much possibilities. It's time to tweak up autodetection so that it can handle most of such cases (and recent HAL features to export capabilities of modem devices might also help in this area).

Tak i Google bude mít vlastní prohlížeč. To už asi není žádná novinka a ví o tom skoro každý. Představení formou komiksu je poměrně zajímavý nápad a určitě zaujal dost lidí, které by jinak taková zpráva zanechala v klidu.

Chápu, že se jim nechtělo v Evropě kreslit všechny hranice, ale proč nejvíc míst, kde hranice chybí, je kolem německa? Že by nějaká připomínka na druhou světovou válku? Nebo že by si autor myslel, že v Evropě pořád ještě zuří? :-)

Release team Debianu (kromě nepodstatných věcí jako informací o zmražení a počtu kritických chyb Lennyho) dnes přišel se zásadní informací – následovník Lennyho se bude jmenovat Squeeze a tradice postaviček z Toy Story tak nebude narušena.

Pokud nevíte jakou roli si v Toy Story zahrál, Wikipedia napoví .

(Obrázek je dostupný pod CC na Flickru .)

Today I finally made something for phpMyAdmin :-). First I've updated Czech translation of 3.0, so it is not that behind as it used to be (only some PBXT strings are missing right now) and then I fixed some potential issues which Thijs has found (thanks to him for his great security work not only for Debian).

Later I focused a bit on demo server. As we already have new setup script from GSoC (made by Piotr Przybylski), links to setup script have been updated and I also reorganised links to all demo versions including direct login links for cookie based authentication. I hope it is now a bit easier to navigate and choose which demo version you want to test :-).