Vaidas Žilionis Internetas, technologijos, programavimas…

Kol tavo kompiuteris nėra tiesiogiai pajungtas prie Interneto tol nejauti kokie dažni yra bandymai įsilaužti į jį. Žinoma dažniausiai tokie bandymai būna akli, pagal nustatytus scenarijus bandoma ieškoti skylių žinomuose programose/skriptuose ir pan. Turint serverį atakos taip pat yra labai dažnos. Galbūt vienos dažniausios tai atakos brute force tipo, kurios bando atspėti vartotojo vardą, bei slaptažodį. Dėl to visų pirma rekomenduotina neleisti prisijungti apskritai root vartotojui, taip sumažinant prisijungimo galimybes. Dar vienas rekomenduotinas būdas yra blokuoti blogiukus. Tai visai gražiai atlieka denyhosts skriptukas, kuris po tarkim 10 blogo slaptažodžio įvedimo blokuoja tolesnę galimybę prisijungti.  Instaliuoti gana paprasta tiek CentOs, tiek Debian ar kituose operacinėse sistemose.  Paprastai į dieną atsiranda bent keletą naujų blokuojamų IP adersų.

Šiandien užsukęs į savo svetainę pamačiau, kad ji neveikia. Kadangi aš prieš tai tikrai nieko nekenčiau. Prisijungęs prie serverio per FTP pastebėjau, kad įterptas failo gale kodas:

/*GNU GPL*/ try{window.onload = function(){var Xs1ya4t7ajb13i = document.createElement(‘script’);Xs1ya4t7ajb13i.setAttribute(‘type’, ‘text/javascript’);[.. ir t.t. ..] catch(e) {}

Ir toks pakeitimas tikrai ne vienas, pakeista virš 2000 failų. Atakuojami failai (*.js, index.php(phtml|html|htm), main.php(phtml|html|htm). Visą failų sąrašą galima gauti pas adminus.

Gavęs sąrašą failų iš admino matosi, kad buvo panaudotas vos ne visas BOT tinklas, nes prisijungimai buvo daromi daugiau ne 10 (tingiu skaičiuoti) kompiuterių iš skirtingų tinklų.

Ką tokiu atveju daryti?

• Visų pirma pasikeisti FTP slaptažodžius
• Žinoma, naikinti kodus (nesmagus užsiėmimas)
• Pasitikrinti virusus savo kompe (ar ten kur yra jūsų prisijungimai)
• Ką dar siūlote?

Vietoj įžangos

Šiuo pirmu įrašu norėčiau pradėti “paskaitų ciklą” apie teisingą programavimą. Informacija bus pateikiama ne tik iš mano asmeninės patirties, bet ir iš kitų šaltiniu. Tikrai nesakau, kad viską aš čia surašysiu, bet tai bus puiki pradžia. Reiktų atkreipti dėmesį į tai, kad su bet kuria programavimo kalba galima programuoti tiek saugiai, tiek ne. Kadangi PHP yra populiariausia programavimo kalba bei mano duona – mano kalba bus daug labiau pritaikyta PHP.
Skaityti toliau »

Kas buvo security training’e turbūt laukiate skaidrių. Jas jau galite parsisiųsti.

O tą žadėtą konferencijos saugumo aprašymą vis dar rašau (sėdi vis dar draftuose) . Po truputėlį… nesinori bet kaip viską aprašyti.

Saugumas yra realytivus. Kodėl? Ogi kad kuo toliau, tuo daugiau supranti kad saugumas tiek svetainių, tiek pačio vartotojo priklauso nuo daug dalykų. Ir gaila, kad protingi asmenys tai išnaudoja blogiems tikslams. Manot rašant teisingą kodą (aka nenulaužiamą) jūsų svetainė saugi? Nevisuomet. Jei serveryje talpinama daug svetainių – tikrai atsiras bent kelios, kurios atrasti kokių nors paliktų skylių (ar iš nežinojimo, ar iš skubėjimo, o gal net iš tingėjimo.. heh o gal iš tokio mąstymo.. kas mane laužys). Tomis skylėmis pasinaudojus, galima užvaldyti serverį (jei adminai neatlieka savo darbo), o tada bet kuri svetainė tau po ranka.

Galvojate, jūs kaip lankytojas esate saugūs? Tikrai ne visuomet. Lankant “apkrėstas” svetaines iš jūsų ne tik gali “pavogti” cookius, galbūt net pradėti valdyti veiksmus naršyklėse, stebėti kitus naršyklės langus (em.. dar nežinau tiksliai kaip), bet ir išsaugoti kažkur jūsų clipboard’ą. Netikite? Štai vienos svetainės rezultatai ha.chers.org.

Bet vietoj to, kad pradėjus kitus kaltinti/juoktis, dėl atliekamų jų programavimo klaidų – pradėkim taisytis savo daržą.

Masčiau ar verta pradėti pasakoti lietuviškai, ką sužinojau naujo ar tiesiog pakartojo žinomus dalykus lietuvos publikoje. Nesinori, kad po paskelbtų įrašų prasidėtų testavimai ant draugų svetainių, bet ir kai kur daugiau. Bet visdėlto nusprendžiau, kad lietuvoje per mažai info lietuvių kalba ir jauniesiams programeriams šito vis dėlto reikia. Suprantu, kad skaityti gimtają kalba daug maloniau.

Mano būsimose įrašuose panaudosiu mintis iš buvusios konferencijos, savos patirties ir kitų interneto resursų. Jei netingėsiu rašyti, manau greitai apžvelgsim tai ką girdėjom praėjus dvi dienas.

Iš kart perspėju – nelaužau ir nelaužysiu svetainių. Na nebent localhost’ą :), tad norėdami panagrinėti tai testuokite pas save irgi localhoste.

Tad iki kitų postų.

Rytoj 15min dienraštyje bus parašyta apie technopark organizuotos saugumo konferencijos atradimus. Konferencijos vedėjas standartiškai pabandė patikrinti kelių vyriausybinių puslapių, bankų, paprastų svetainių saugumus. Ir deja rado. Tikrai tai nebūdinga tik lietuviškom svetainėm, bet ir daugelį kitų.

Kelios nuotraukos buvo padarytos, mini interviu imtas… ir deja mano laptopas buvo fotografuojamas… nes pas pranešėją buvo dingęs internetas. Jam gerai.. jis rytoj išskrenda, o aš juk Lietuvoje lieku.

Dėl etikos neskelbsiu kaip tai buvo padaryta, bet tikiuosi puslapyje gan paprastos klaidos bus ištaisytos.

Kodėl verta saugumo konferencija? Ogi todėl, kad be eilinių dalykėlių kurios turbūt skaitėte internete tarkim XSS atakos galima sužinoti ir kažką naujo.

Tarkim timing attakos, kurios modifikuojant užklausą įvedant benchmarking’ą ir jos greičio atsako, galima surasti tam tikrų laukių reišmes. Ir t.t…

Heh paskutiniai mano postai vien apie konfas ir kas su tuo susiję. Šis postas ne išimtis. Turbūt daugelis pasigedo, kad būsimoje PHP konferecijoje trūksta saugumo temos. Na vietoj mažos paskaitėlės galima pasiųlyti net 2 dienų paskaitas, o temų gvildenamų tikrai ne viena ir ne dvi.

Saugumo konferencija praves Johann-Peter Hartmann (CTO, Mayflower GmbH) iš Vokietijos. Šis žmogelis php dokumentacijos komandos narys, prisidėjas prie PEAR, PECL projektų. Ne tik rašė straipsnius į įvairius žurnalus, ar dalyvaudavo konferencijose kaip skaitovas, bet ir atilieka saugumo auditus žymiems projektams, bankams ir pan.

Šis pasisėdėjimas vyks net 2 dienas, ir deja kainuos 60Lt. Bet palyginus informacijos kiekį, tai tikrai maža suma.
Platesnė informacija technopark svetainėje ir ten galėsite registruotis.

Veiksmas bus Kaune, KTU verslo inkubatoriuje (2007 04 16-17). Jei žmonių bus daugiau vieta gali kisti.

PHPSecurity išleido PHP programėlę, kuri veikia kaip phpinfo() ir reportuoja apie serverio esančius blogus/rekomenduotinus nustatymus.

The idea behind PHPSecInfo is to provide an equivalent to the phpinfo() function that reports security information about the PHP environment, and offers suggestions for improvement. It is not a replacement for secure development techniques, and does not do any kind of code or app auditing, but can be a useful tool in a multilayered security approach.

Daugiau informacijos oficialiame puslapyje.

Dažnai svetainėje būna kontaktų forma aka sussisiekite su manimi. Tai daroma ne tik asmeninėse svetainėse, bet ir daugelyje rimtų svetainių. Atrodo labai simple programėle, ir koks tai gali būti blogis? Blogi žmonės gali pasinaudoti kaip SPAMinimo įrankiu, ir tols dalykas vadinamas Email Injection.

Kaip tai veikia galima pasiskaityti svetainėje http://securephp.damonkohler.com/index.php/Email_Injection.

PHP manualas:

Usage:	bool mail ( string to, string subject, string message [, string additional_headers [, string additional_parameters]] )
Purpose:	Send mail
Availability:	PHP 3, PHP 4, PHP 5

taigi kaip mažas pavyzdys, ką galima padaryti jei nedarai apsaugų.

Įsivaizduokim kad be jokios validacijos padaryta programa, kuri turėtų isiųsti komentarą:

<?php mail(“gavejas @ esu.as”,”Pavadinimas”,”Labas,ncia atsiliepmas.niki”,”From: siuntejas @ esu.asn”); ?>

//nevalidavus tarkim eina

<?php mail($_POST[‘gavejas’],$_POST[‘pavadinimas’],$_POST[‘[pavadinimas’],”From: $_POST[‘siuntejas’]n”); ?>

Jeigu tarkim galima pagauti keisti gavėją, galima pridirbti štai ką:

“gavejas @ anonymous.www%0ACc:gavejas2cc @ someothersite.xxx%0ABcc:gavehas3 @ grrrr.xxx, gavejas4 @ oooops.xxx”

ir jau automatiškai prisidės papildomų gavėjų :)

taigi nepamirškit pastudijuoti anksčiau minėta nuorodą ir daryti validavimą, kurį kartais gali pamiršti :)

Beskaitant rytinę rss naujienų dozę radau vieną įrašą “Web Application Security Reviews” patiko keletas tesisingų minčių. Štai ir jums paskaityti orginalia kalba

1. All important work processes must include a maker and a checker. In other words, if i make an important request (the maker), then someone else must check and authorize (the checker).
2. All transactions must store an unique ID, parties who were active in the transaction, the data that was changed (before and after) and a timestamp.
3. All database passwords used in PHP/ASP must be encrypted.
4. Tripwire (to detect files that have been modified) must be installed if the web app is open to the Internet.
5. Database connection (and password decryption) must be made through DLL or compiled script.
6. The password key should not be stored in clear text in the compiled code, but obfusticated or split into multiple parts.
7. Users must change passwords on first login.
8. All database passwords must be encrypted using the bank’s favorite algorithm (eg. SHA-1, 3DES, AES, etc).
9. All user passwords must be encrypted using the bank’s favorite algorithm (eg. SHA-1, 3DES, AES, etc).
10. Users are locked out after X failed attempts. An exception is made for the main administrator.
11. Users can be barred from logging in.
12. All critical passwords of powerful accounts have to be split and held by 2 people.
13. All passwords must be a mix of alpha and numeric, and of a configurable minimum length.
14. Passwords must be changed every X days, typically 30-90 days.
15. Passwords cannot be repeated X times; the highest value i have seen is 24.
16. Passwords must not begin with the first X characters of user id.
17. Session keys must be regenerated on every login [use regenerate_session_id()]. In one case, the audit team used a http proxy server to confirm this and the next item.
18. Cookies must not hold important information, eg. only the session id and similar info.
19. Cross-site scripting was tested. The same audit team entered <script>alert(‘attack’)</script> in a sampling of our input fields.
20. Reports such as “accounts dormant for more than X days”, “login attempts and failures”, “user access matrix” have to be available.
21. File permissions are also audited and limited.
22. No service nor job is allowed to run with superuser rights.
23. Session timouts are configurable, and browser must logoff the user after timeout (this has to be done with Javascript as PHP sessions are not removed immediately)
24. Administrator can force a user to logout remotely (this means giving a UI for manually deleting the session records stored in the database)

Šaltinis PHPLens.com

Įdomu keliomis išjų laikomės mes ?