Weby sa už pred časom stali súčasťou nášho bežného života. Dnes už nevidíte, že by moderátor alebo politik povedal: “Viac informácií nájdete na našom webe www@…” (toto som zažil niekedy v 2002). Drvivá väčšina webov, hlavne tých osobných, alebo menších je umiestnených na tzv. webhostingoch.
Bezpečný a spoľahlivý webhosting na www.WebSupport.sk reklama
Myslím si, že väčšina čitateľov už dobre vie, čo je to webhosting. Na Slovensku nájdete niekoľko desiatok poskytovateľov webhostingových služieb, v zahraničí sú ich státisíce. Stačí si len vybrať.
Technická časť
Medzi veľkých by sme mohli zaradiť aj spoločnosť Slovak Telekom (ďalej už len T-com), ktorá dnes spravuje okolo 7000 slovenských domén a medzi registrátormi sa zaraďuje na šieste miesto. Ako každá správna webhostingová spoločnosť, T-com poskytuje niekoľko typov balíčkov, aby si mohol každý vybrať.
- WEB Basic – statický web, bez vlastnej domény
- WEB Standard – statický web s vlastnou doménou
- WEB Standard Plus – dynamický web s vlastnou doménou
- WEB Advance – dynamický web s vlastnou doménou
Pozadie
Samotnej ponuke ako aj cenám sa budem venovať neskôr. Teraz je dôležité, že T-Com ponúka dve zásadné služby. Statickú, teda len HTML stránky a dynamickú, ktorá je v tomto prípade PHP (a možno aj ASP). Táto znalosť je úplne kľúčová pre pochopenie zraniteľnosti a jej dôsledkov. T-Com ešte rozdeľuje služby dynamických webov podľa majoritnej verzie php na PHP 4, ktorá beží na serveri wep.t-com.sk a PHP 5, ktorá beží na serveri wep5.t-com.sk. HTML distribuuje web.t-com.sk. Dynamická služba však beží na dvoch typoch serverov a to Linux a Windows. Windows server opäť ponúka PHP, pravdepodobne však aj ASP, ale na žiadny taký web som nenarazil. Windows server wew.t-com.sk. Všimnite si hrubo označené časti adries, ktoré jasne určujú typ servera.
Zraniteľnosť a dôsledky
Každá doména má pevnú IP adresu v DNS záznamoch, ktorá vedie ku konkrétnemu serveru. Doteraz sme neprišli na to prečo, ale je to tak. T-Com vrámci balíčkov poskytuje aj automatizovanú správu domény, vrátane zmeny servera, na ktorom je doména distribuovaná. Toto celé je možné urobiť na jedno kliknutie (viď screenshot) bez toho, aby ste potrebovali kontaktovať support. A to nás privádza k tej najdôležitejšej časti. Všetky servery zdieľajú dáta všetkých domén! To znamená, že ak násilne presmerujete doménu na ďalší server, tento server spracuje vašu požiadavku a vráti vám odpoveď. To znamená, že ak požiadam čiste webový server distribujúci statické stránky, aby mi vrátil dáta domény, ktorá používa dynamický jazyk PHP, čo sa stane? Uhádli ste. Vráti mi zdrojové stránky celého webu.
V tomto mieste sa hodí predošlá znalosť serverov, ktoré distribuujú obsah. Vyberieme si jednu z dynamických domén, napríklad changecomputer.sk, ktorej dáta štandardne distribuuje server wep5.t-com.sk, IP adresa 213.81.152.62.
changecomputer.sk ns2.telecom.sk ns.telecom.sk 213.81.152.62Ak chceme, aby túto doménu spracoval iný server, musíme mu túto požiadavku poslať. Na OS Windows to urobíte tak, že v súbore hosts “C:\WINDOWS\system32\drivers\etc\hosts” doplníte riadok
213.81.152.54 www.changecomputer.skPod touto IP adresou sa schováva server web.t-com.sk.
Takže výsledkom celého postupu je možnosť získať prístup ku zdrojovým kódom všetkých dynamických webových stránok, ktoré sú hostované na týchto serveroch. Domén, ktoré využívajú dynamický jazyk, je niečo okolo 3000. Takže takmer z polovice všetkých domén je možné získať zdrojové kódy. 98% týchto webov pravdepodobne využíva aj databázy. Takže keď získate prístup k týmto informáciám, máte relatívne veľkú šancu dostať sa aj do konta samotného zákazníka v T-Com paneli.
Ako sa hovorí, lepšie je raz vidieť ako tisíckrát čítať a tak tu je ako už štandardne POC video. Ospravedlňte zvláštne správanie sa systému vo videu, nahrával som to až cez dva vzdialené počítače, takže je tam vidieť značne predĺženú odozvu systému na akúkoľvek požiadavku. Video v originálnej kvalite (1024×768) si môžete stiahnuť na stránkach Vimeo.
Zoznam domén, ktoré sú spravované cez DNS T-Comu.
Čo na to T-Com
Táto časť je z toho celého asi najsmutnejšia. Ak sa sami pýtate, ako je možné, že spoločnosť “zabudne” na takúto zraniteľnosť, ktorá bola bežne využívaná na prelome storočí, tak nie ste sami. Ešte horšie však je, že po prvý krát bola zraniteľnosť ohlásená už 16. Októbra 2008. Celá komunikácia trvala niekoľko dní, no k žiadnemu výsledku nedošlo. Následne som ja reportoval túto zraniteľnosť 4. Apríla 2009, kedy ma požiadali o predĺženie lehoty na zverejnenie článku, čomu som vyhovel. Zraniteľnosť bola odstránená tento pondelok, teda 6. Apríla 2009 večer. To znamená, že viac ako 5 mesiacov spoločnosť T-Com o tomto probléme vedela a nič s nim neurobila! Dôvodom môže byť aj to, že pracovníci technickej podpory T-comu majú už dopredu pripravené odpovede formulované znalými technickými pracovníkmi, pričom oni samotní nemajú hlbšie znalosti daného systému.
Teoretická časť
V dôsledku tejto zraniteľnosti som sa začal zaoberať hlbšie celou ponukou T-Com hostingu. Veľmi ma zarazilo, že dnes ešte niekto ponúka platený webhosting statických stránok. S niečim takým som sa už roky nestretol. O to zaujímavejšie je, koľko klientov T-Comu využíva balíček pre statické weby. Ešte zaujímavejšia je cena samotných služieb. Cenník vo formáte PDF (netuším prečo nie je priamo na webe) nájdete tu. Z neho sa dozviete, že:
- WEB Standard – mesačný poplatok s DPH 5,89 Eur
- WEB Standard Plus – mesačný poplatok s DPH 6,68 Eur
- WEB Advance – mesačný poplatok s DPH 11,80 Eur
Pre porovnanie, spoločnosť Websupport poskytuje hosting, ktorý by mohol tvoriť piatu kategóriu v ponuke T-Comu za mesačný poplatok 7.85 Eur s DPH. Spoločnosť Yegon ponúka ekvivalent za mesačný poplatok 13.15 Eur s DPH. To sú z môjho pohľadu dosť drastické rozdiely, nielen v službách ale aj samotnej cene. Obe spoločnosti ponúkajú vlastný webhostingový panel, cez ktorý je možné rýchlo a automatizovane spravovať svoju doménu bez potreby kontaktovať support. Ani jedna zo spoločností neponúka webhosting pre statické stránky.
Zvláštny T-Com
Vecí, ktoré by sa dali T-Comu vytknúť je však viacej. Jednou z nich je aj napríklad spomínaný webhostingový panel. T-Com na ponukovej stránke uvádza linku, cez ktorú sa k nemu môžete dostať. Tou je wh.t-com.sk. Keď sa však pozriete, kam linka smeruje, zistíte, že v skutočnosti nesmeruje na doménu 
t-com.sk, ale na doménu stonline.sk (viď screenshot). Nič, čo by stalo za povšimnutie, poviete si. Spoločnosti patria obe domény, nech to smeruje kam chce. To je samozrejme pravda, až na to, že si páni z T-Comu neuvedomili tieto dôsledky pri využívaní SSL certifikátu. Ak sa teda pokúsite otvoriť skutočnú linku ku webpanelu whps.stonline.sk/wh/login, objaví sa vám chybová hláška (v IE 6 vás prehliadač ani len neupozorní a zobrazí proste chybu o nedostupnom serveri), že certifikát pre túto doménu nie je platný (viď screenshot). Dôsledok je jasný. Ak sa pokúsi bežný klient prihlásiť do panelu, zostane značne zmätený a bude kontaktovať technickú podporu (alebo to riešiť inak). Každopádne sa jedná o veľmi nepríjemnú chybu, ktorá umelo vytvára zbytočné problémy.
A aby toho nebolo málo, samotný Webpanel je neuveriteľne deravý. Pôvodne som chcel spraviť aj POC video pre to, ako jednoduchým skriptom získať prístup do ktoréhokoľvek konta užívateľa, ale nateraz to celé stačí.
Záver
T-Com webhosting je z môjho pohľadu veľmi zle vytvorená služba. Drahá, so slabými možnosťami a k tomu s veľkými bezpečnostnými chybami, ktoré musia odradiť ktoréhokoľvek klienta. Jediné pozitívum z mojej strany je, že sa mi na môj email ozval pracovník technickej podpory relatívne rýchlo, no bohužiaľ s odstránením chyby čakali až do pondelka, pritom sa jednalo o veľmi závažnú chybu. Nič to však nemení na viac ako päťmesačnej lehote, po ktorú boli pracovníci oboznámení s touto zraniteľnosťou a nič pre jej odstránenie neurobili (aspoň to nemalo žiadny efekt).
No a konečne by som sa chcel poďakovať čitateľovi mafovi, ktorý ma na celú záležitosť upozornil už pred niekoľkými mesiacmi. Ďalej chalanom z niekoľkých IRC kanálov, ktorí sa počas celého večera snažili nájsť správne pomenovanie pre túto konšteláciu serverov (vrátane otisa) a ďalších, ktorí na článku spolupracovali svojimi pripomienkami.
Stare, ale dobre. Super clanok!
Sorry, ale reklama na WebSupport mi dosla velmi komicka. Nic osobne, ludi, co za tym stoja si vazim, ale pri spomienke ako im onehda odniesli servery priamo zo strojovne mi je jasne, ze “bezpecne” to nie je nikde.
Hm, toto nie je jediny problem zda sa, pred casom som odisiel od ich webhostingu kvoli castym a nezlepsujusim sa vypadkom, dostupnost bola v porovnani s konkurenciou o nicom. A ano, ponuka sluzieb za tie peniaze neadekvatna.
No to, že se můžete dostat na zdrojáky sice není pěkné, ale nemělo by to být fatální. To by vám mělo vadit pouze si zdroják ceníte jako své duševní vlastnicví apod. K heslům byste se takto v žádném případě neměl dostat, pokud jsou hesla do db či jinam uložená přímo ve zdrojáku, tak je to prasárna největší a chyba programátora a nikoliv web hostera.
Příklad. pokud máte kód v /www/domena.cz/www/*.php, kde /www/domena.cz/www/ je documentroot serveru domena.cz, tak konfiguráky s hesly mají být v /www/domena.cz, takže vi je ve skriptech můžete inkludovat, ale uživatel se k nim nedostane ani pokud se soubory v documentrootu posilaji jako plain text.
#4 Miroslav Suchý: podla mojich znalosti ma kazdy open-source projekt, vratane napriklad tohoto wordpressu co mam tu configuracny subor, ktory sa neda presunut na ine miesto, pretoze by si musel priamo zasahovat do kodu, co vacsina uzivatelov skutocne nevie. dalsia vec je, nastavenie samotneho servera. od neho zalezi ci sa niekam dostanes, alebo nie.
Ano, na toto sa asi casto zabuda. Tiez na par projektoch pouzivam pre staticke subory (vela obrazkov alebo flv streamy) druhy webserver (lighttpd) a kvoli jednoduchosti je nasmerovany na ten isty documentroot (pripadne jeho podadresar). Ale v konfiguracii mam priamo zakazane pripony suborov .php a podobne.
Novy lighttpd dokonca ma zoznam pripon, ktore nemoze spracovat ako staticky subor, ale ak sa naloaduje interpreter ako modul (php, cgi), tak ten ho spracovat moze. Takto je mozne krasne ochranit server uz aj v default konfiguracii bez nutneho nastavovania uzivatelom.
btw, cheche, velmi ma pobavil ten vtip v uvode clanku: “Sú 2 typy ľudí. Tí, ktorí sa boja o svoje weby, a tí, ktorí už sú naši klienti. WebSupport” :-)) ten je fakt dobryy
Rano som precital. Vyborny clanok :-). Jeden nas klient mal web na telecome ale kedze nevedeli nic pre nas urobit tak som ho presunul inam. Pamatam casy ked som sa tam musel prihlasovat LEN cez dialup lebo sa na tie servery nedalo dostat z inej siete, len z telekomackych IP.. nuz.. ukazuje sa stara pravda ze nemozes robit vsetko naraz a poriadne.. treba sa specializovat. V podstate nepoznam velku firmu ktora ma hosting ako jednu z aktivit ktora by bola ochotna a schopna reagovat na individualne a specificke poziadavky. Preto to vzdy vacsinou konci presunom inam.
Výborný článoček,
Tá reklama, súhlasím s Kozom
#2 Kozo: #7 jano: #9 CoolYOU: vsetko lepsie ako ked viac ako 5 mesiacov niekto kasle na zasadnu bezp. chybu a umoznuje inym stahovat tvoj source kod, etc.
Neskutočné..
Rasťo, klobúk dolu, u T-Comu nehostujem a ani nebudem, h1234i pytaju peniaze aj za vytvorenie subdomeny (aspon cca pred dvoma rokmi to tak bolo, ale nevidim dovod preco by oni chceli zmenit sposob ryzovania na ukor zakaznikov). Takato chyba neni v prvom rade chyba toho klienta ako tu padlo v komentaroch, dokonca aj BB ako PHPBB3 ma svoj config, vacsina CMS tiez, pravdupovediac neviem si predstavit ako by sa riesil access do DB bez nejakeho config file ktory neni nahrany na serveri (ak nepocitame cross site riesenia).
co sa tyka reklamy, u mna OK, nebije to do oci, neni to flash (aj ked flash mam rad ale niekedy co vyvadzaju s tym je nenormalne) a neni to popup cez cely site.
este raz dik za clanok :)
A zase ten istý holding alebo v akom zväzku sú… Čokoľvek čo má nálepku t-com, zoznam.sk a všetkých príbuzných odpadkov vo mne vzbudzuje veľmi silné nutkanie na zvracanie… Btw. pridal sa niekto k môjmu spamovaniu zoznam.sk? :) http://blog.synopsi.com/2009-03-03/stedra-nadielka-mailov-od-zoznamsk#comment-4039
#13 Ja.: toto nutkanie má viacero ľudí, vrátane mňa
Ta reklama na SK hosting je bieda … ale uznavam, ze aj ty musis z niecoho zit :-)
My sme odisli od Slovenskych hostingovych firiem uz davno.
Jednoducho ani jedina firma nedokaze pracovat trvalo v urcitom standarde. Zvacsa su ochotne spolupracovat pokial si k nim nesies server, ale akonahle nieco potrebujes neskor, mas smolu.
O supporte ani nehovorim … viete niekto napr. o tom, ze by mala nejaka hostingova firma na Slovensku SLA time 30 minut ako napr. Liquidweb (365 dni v roku)?
Rovnako je problem, ze u nas na supporte robia casto ludia, co odpovedaju len podla prirucky a casto ani netusia o com hovoria.
Rovnako to bolo asi aj ked si kontaktoval T-Com … asi preto im to trvalo 5 mesiacov, lebo to nevedeli najst v prirucke co si im napisal :-)
Co sa tyka toho konfigu.. mnohe hostingy uz maju verejny adresar.. napriklad “public_html” .. a neverejne adresare.. ako napr “data” takze sa da dat konfigurak aj mimo adresarovej struktury pristupnej z “www”
maly kopanec, ze ma t-com neplatny certifikat na nejakej stranke na konfigurovanie…
to taky sk-nic sa s tym vobec nesere.Urcite su chudaci hlboko v cervenych cislach ze nemozu mat podpisany certifikat na webu od verisignu alebo thawte atd.
ja zo slovenskych mozem odporucit yegon pre housing, tam je aj support pomerne rychly. na beznych programoch to az take ruzove nebolo.
#16 Roman: nechcem byt zly, ale stiahni si niektory z tychto open-source projektov, napr drupal, joomla, wordpress, phpbb, atd. a daj si configurak inam, ze ake to bude jednoduche pre teba. potom mozes samozrejme urobit aj navod pre kazdeho, pretoze si myslim, ze nad tym stravis niekolko noci ;)
#17 ddc: ano a nielen sk-nio, ale aj csob a par dalsich. uz som o tom kedysi pisal na trende, tak si mozes precitat tu krasnu diskusiu ;)
Klient mal maily u T-Comu a potreboval vytvorit aj web. Ked mi poslal cennik za hosting, ktory dostal od nich tak som sa nestacil cudovat. Hodili sme jeho web ku mne s tym, ze DNS spravuje stale T-Com. Asi mesiac im trvalo kym sa postarali o to aby spravne presmerovalo aj adresu s www na zaciatku (bez www to ficalo) po asi 2 mesiacoch sa mi ozval klient, ze stranky nefunguju. V T-Come nieco nastavovali a opat http://www…. smerovalo na ich server. Vtedy uz asi vedeli ako sa to ma nastavit, tak to opravili “iba” za 3 dni :)
oooo: ;-) dohodnime sa ze ti budem verit, predsa len mas tu wordpress, mas v merku bezpecnost, keby to slo jednoducho asi by si to uz davno spravil ;-)
Co sa tyka toho certifikatu akurat nieco podobne vyskocilo dnes aj u nas v diskusii.. uzivatel pise.. ked som tam klikol vyhodilo mi “neplatny certifikat”.. existuju firmy ktore si to mozu dovolit a existuju firmy ktore si to dovolit nemozu.. hlavne tie u ktorych je dovera klienta jednym z klucovych faktorov biznisu.
Zmena pozicie konfigu v Joomle je jednoducha: staci prepisat csetu v define( ‘JPATH_CONFIGURATION’, JPATH_ROOT ); v troch suboroch.
Wordpress umoznuje hodit wp-config.php o adresar vyssie ako root bez zasahu do kodu.
phpBB je na tom najhorsie: 9 vyskytov retazca ‘config.’ v 5 roznych suboroch.
Predpokladam, ze ostatne open source projekty budu podobne. Problemom zvycajne nie je ‘hack’ systemu, ako jeho opatovne kontrolovanie pri kazdej aktualizacii.
#21 Roman: Asi im moc nejde o dôveru zákazníkov. Im stačia priemerní IT negatívni zákazníci, z nich kľudne vyžijú.
#22 Palino: taze aby si zmenil umiestnenie configu, potrebujes zmenit az tri subory. pri prvom upgrade to musis urobit znova. teraz si vezmi kazdeho bezneho usera, ktory si joomlu nainstaluje. este lepsie si predstav spolocnost, ktora to robi pre svojich klientov a ma ich napriklad 400 a kazdy ma iny hosting, teda aj inu strukturu.
mne by napriklad pri wp nijakym sposobom nepomohlo dat config o poziciu vyssie, pretoze tam sa bezproblemov z webu dostanes, dokonca aj o dve pozicie, musel by som ist az o tri.
stale to je o tom istom. systemy s tymto nepocitaju a tak to nie je nijak jednoduche.
#21 Roman: skor je to o tom, ze uzivatelia si nevedia “dupnut”. ak by klient csob povedal, ze odide ak nezmenia dodavatela cert a spravilo to par uzivatelov, hned by sa nieco pohlo. to sa ale nikdy nestane, takze to ostane tak, ako to je
Uvod: @oooo: vdaka za clanok :)
Jadro: Trosku odhalim tajomstvo objavenia chyby, bolo to ako to uz byva, velmi podobne s panom Pasteurom a jeho penicilinom.
Klientovi sme robili aplikaciu, ktora vyzadovala prepnutie z web na wep5, vsade to fungovalo len u klienta nie. Asi mesiac sme sa pinpongovali emailami s t-com techgroup (support) pricom chyba bola, ako to uz byva, vzdy u nas. A mali pravdu! Kedze klient mal na lokalnom firewalle vlastny DNS, kde mal natvrdo svoje domeny. Od toho to uz bol len kusok k suboru hosts. To sa nam uz reportovat tcomu nechcelo (dovod nizsie), preto sme tento problem postupili kompetentnejsim osobam (synopsi).
A zaverom: Preco bola snaha to cele medializovat? Pretoze ked supportu poslete email so screenshotmi browsera ktory sype zdrojaky na poziadanie a ten odpise ze to bude chyba u nas pretoze u nich sa to neprejavuje (to by ste se museli vohnout ze?) tak nech zvysok (pomerne pocetnej) klientely vie u akejzeto spolocnosti hostuje. O cenach sa radsej ani nebavme…
Do skakavenia priatelia..
“Pretoze ked supportu poslete email so screenshotmi browsera ktory sype zdrojaky na poziadanie a ten odpise ze to bude chyba u nas pretoze…”
komédia.
#24 oooo: preco by som nemohol jednoducho v lubovolnom cms dat konfiguracny subor do lubovolneho priecinku mimo web_root daneho virtualhostu a nasledne v subore kde predtym boli udaje dat jediny riadok
require (‘cesta k presunutemu suboru’);
aktualizacie cms sa vacsinou konfiguraku nedotykaju, a keby sa tykali, musel by si ho menit tak ci tak.
to ked uz sa bavime o tom, ake narocne by bolo upravit lubovolny cms. samozrejme, ze je to blbost a nemyslim si, ze mat udaje k db vo webroote je nieco nestandardne.
#27 thomm: hehe, tiez mi to povodne napadlo a potom som prisiel na celkom srandovnu vec. config sa nacitava z roznych urovni, napriklad z admina. tam je ale uz vsetko o uroven jedna dole, cize vlastne vysledny efekt je, ze dostanes chybu, lebo system nevie uvedeny subor najst, kedze je o uroven vyssie (../). mozno sa to da nejak obist, nespekuloval som nad tym nejak, kazdopadne toto by bezny user nezvladol a tych je drviva vacsina. ostatne cms budu na tom asi obdobne
Obist sa to ta pomerne jednoducho. Viazat poziciu noveho konfiguraku na poziciu stareho: require dirname(__FILE__).DIRECTORY_SEPARATOR.’..’.DIRECTORY_SEPARATOR.’…etc.php’;
Alebo zadat absolutnu cestu.
ALE: Treba brat do uvahy, ze vacsina CMS zapisuje do konfigu priamo. Napriklad uz len taka trivialna operacia ako odstavenie stranky v Joomle vam ho prepise do povodneho stavu.
Môjmu ‘hostingu’ sa doteraz pri každom update Apacha odmazala CGI konfigurácia, a tým pádom boli všetky php skripty dodávané ako plaintext. Našťastie neprevádzkujem žiadnu závažnú službu, ale ajtak som investoval trośku času na oboznámenie sa s krásou .htaccess súborov a Deny pravidiel. Predsalen, keď ti webserver začne zverejňovať obsah konfiguráku s heslami do databázy plnej citlivých osobných údajov, tak máš problém…