Man jau liekas loģiski, ja ir divas iespējas (piemēram, sarkans un melns), tad diezgan ātri vajadzētu pienākt reizei kad varētu uzminēt sarkanu vai melnu

Nu ko domāts darīts, vajag izskaitļot cik tad ir iespējams reizes praktiski neuzminēt? (lai saprastu cik vajadzētu $, lai kaut ko vinētu).

Teorija saka, ka katrā reizē iespējams uzminēt 50/50, tas nozīmē, ja neesi uzminējis 10 reizi, tad iespēja uzminēt pareizi 11tajā reizē arī ir tikai 50/50 Bet loģika saka ko citu- cik tad reizes var nepaveikties?

Tāpēc izveidoju simulācijas modeli, kurš noteiks cik reizes ir iespējams pēc kārtas kļūdīties?

Un kādi rezultāti? Interesanti…

Līdz šim biju lasījis vairākus rakstus, kur bija teikts, ka šī metode nestrādā… un kāpēc?

• tāpēc, ka, lai pēc vairākām neveiksmes reizēm mēs riskējam ar daudz reiz lielāku summu (pēc dubultošanas), nekā varam iegūt (piemēram, ja sākam ar 5ls, tad pēc 10 neveiksmes reizēm mums jau ir nepieciešams 2560 uz gājienu uzlikt, lai beigās vinnētu tikai 5ls )
• jebkurā gājienā uzminēt iespēja ir tikai 50/50
• daudzās grāmatās ir rakstīts, ka šī metode strādā, bet tikai līdz vienai reizei, tas nozīmē, ka sākumā var gūt panākumus, bet vienmēr pienāks reize, kad zaudēsiet..

Protams te var runāt par riska apetīti un cik mēs esam gatavi riskēt, lai kaut ko iegūtu, bet ne par to ir stāsts.

Un tam seko rezultāti…

Lai tie maksimāli būtu ticami, eksperimentu atkārtoju z reizes un veicu i reizes..

Kādi rezultāti?

Lai neteiktu vairāk bēdīgi..

Izveidoto skriptu atkārtoju gan uz Linux, gan uz W7 un rezultāti ir gaužām atšķirīgi..

Uz linux pēc kārtas bija iespējams maksimāli neuzminēt 29 reizes..

Uz w7 pēc kārtas bija iespējams maksimāli neuzminēt 14 reizes..

Kāpēc varētu šie rādījumi atšķirties?

Nezinu, iespējams vaina ir rand funkcijā, kura uz win un lin izpildās dažādi.

Sākumā biju izmantojis rand funkciju starp 1 un 2 (rand(1,2)), tad win gadījumā rezultāts bija vēl cerīgāks (max 11 reizes pēc kārtas neuzminēt), bet kad izmainīju algoritmu, lai nosaka vērtību starp 100 un, ja ir zem 50, tad iegūt vērtību 1 un pretēji 2, tad ieguvu 14 reizes un visu laiku vienādu. Linux gadījumā katru reizi rezultāts tomēr mainījās, bet starpību starp rand (1,2) un rand(1,100) nejutu.

Kāpēc es visu šo iesāku? sākumā priekš sevis, lai saprastu, kāda tad ir faktiskā iespēja kļūdīties x reizes pēc kārtas un pēc tam uzskatīju par nepieciešamību parādīt citiem kas Jūs sagaida, ja nolemsiet dubultot..

Kādi tad ir mani secinājumi?

No eksperimenta sanāk, ja tev ir nauda un iespēja (kas rulletē nav, jo ir ierobežojums uz maksimālo likmi) dubultot vismaz vairāk kā 30 reizes sākotnējo likmi, tad karogs tev rokā (bet ņem vērā, ka var arī nepaveikties arī 30 reizē ).

Pretējā gadījumā Jums var paveikties arī vairākas reizes, bet kādreiz pienāks diena Z, kuru labāk nepiedzīvot.
Lūk mans testa modelis:


//izpildes laika aprēķinam
$mtime = microtime();
$mtime = explode(" ",$mtime);
$mtime = $mtime[1] + $mtime[0];
$starttime = $mtime;
// beigas laika aprēķinam
echo "Parbaudam varbūtības praktisko pusi";

//ar šo ciklu atkārtosim mērījumus z reizes, lai iegūtu pēc iespējas ticamāku rezultātu
$max_max_katra_reize=0; //mainīgais, kurā glabāsies atkārtoto mērījumu gadījumā maksimālais neuzminētais skaits pēc kārtas
for ($z=1;$z<=1000;$z++)
{
$max_katra_reize=0; //mainīgais, kas saturēs maksimālo nesakritības reizi katrā piegājienā (i ciklā, nevis z ciklā)
$skaits=0; //cik reizes pec kārtas nesakritīs konkrētā mērījumā (i cikls)
$max_skaits=0; //maksimālais skaitlis cik reizes pēc kārtas ir nesakritis konkrētā mērījumā (i cikls)

for ($i=1;$i<=100000;$i++){ //cikls, kurš simulēs konkrēto mērījumu
$gad1=rand(1,100);
$gad2=rand(1,100);
if ($gad1<=50){$pimais=1;} else {$pirmais=2;}
if ($gad2<=50){$otrais=1;} else {$otrais=2;}
/*
$pirmais=rand(1,2); //iegūstam pirmo nejaušo vērtību
$otrais=rand(1,2); //iegūstam otro nejaušo vērtību
*/
//echo "$pirmais $otrais
";
if ($pirmais!=$otrais){ //ja abas vērtības nesakrīt, tad palielinam pēc kārtas nesakritušo vērtību
$skaits=$skaits+1;
}
if ($pirmais==$otrais){ //ja abas vērtības sakrīt, tad pēc kārtas nesakritušo vērtību nonullējam
$skaits=0;
}
if ($skaits>$max_skaits){ //iegūstam maksimālo nesakritušo vētību katrā mērījumā, lai nav jāizvada viss liekais
$max_skaits=$skaits;
$max_katra_reize=$max_skaits;
//echo "
Maksimālais nesakritušo reižu skaits3: $max_katra_reize
";
}
} //beidzas konkrētā mērījuma cikls (i cikls)
//pēc cikla beigām esam ieguvuši maksimālo skaitli $maz_katra_reize, kurā glabājas vērtība cik maksimāli pēc kārtas reizes nesakrita abi skaitļi

if ($max_katra_reize>$max_max_katra_reize){ // tagad izvadīsim cik tad bija maksimālais nesakrītības reizes pēc mērījuma un to atkārtojot z reizes pieņemamās pārliecības iegūšanai
$max_max_katra_reize=$max_katra_reize;
echo "Maksimālais nesakritušo reižu skaits: $max_max_katra_reize
";
}
} //beidzas atkārtoto mērījumu cikls (z cikls)

//laika aprēķinam
$mtime = microtime();
$mtime = explode(" ",$mtime);
$mtime = $mtime[1] + $mtime[0];
$endtime = $mtime;
$totaltime = ($endtime - $starttime);
echo "Lapa tika aprēķināta ".$totaltime." sekundēs";

?>

Kā šādu ievainojamību var izmantot tehniski biju atradis netā un pārpublicēju šeit.

Tā kā teorija un citu piemēri no prakses atšķiras, tad nodomāju patestēt.

Linux gadījumā tas varētu izskatīties šādā veidā:

for i in {1..7500000}; do
wget http://www2.vid.gov.lv/eds/Pages/GetDuf.aspx?id=$i;
done

Bet tā kā mājās stāv W7, un no LiveCD ielādēties ir slinkums izvēlējos garāko ceļu.

wget komandai ir arī windows alternatīva, kuru var atrast GNU lapā.

Pēc instalēšanas un notūnēšanas, lai to varētu palaist no jebkuras vietas var ķerties pie nākamā soļa- atrast mājaslapu, kurā ir līdzīga ievainojamība.

Otrs un pareizākais variants būtu radīt šādu ievainojamību kādā savā lapā un tad testēt, bet šoreiz atzīšos, esmu par slinku.

Pēc dažām minūtēm tika atrasta diezgan lielas iestādes lapa, kurā ir līdzīgs gadījums. Pēc http://……lv/file.php?id=, id lauka vērtībā mainot vērtības tiek piedāvāts nolādēt dažādus failus.

Lielākā daļa no testā atklātiem dokumentiem (daži bija php faili, kurus diez vai admins vēlējās, lai varētu nolādēt) ir arī brīvi pieejami no mājaslapas, tā kā uzskatu, ka tā ir funkcionalitāte, nevis trūkums

Mājaslapas adrese ir izmainīt, lai kārtējais tīnis neapciemo šo lapu un …..

Nu tad pie testa un rezultātiem.

Lai wget un for cikls strādātu uz win, tas ir jāmodificē- man sanāca šāds brīnums:

for /l %%i in (1,1,1000) do (wget -r “http://……..file.php?id=%%i”)

Izskatās easy, bet..

visi iegūtie faili ir nevis nosaukums.paplašinājums, bet:

.file.php?id=1

.file.php?id=2

.file.php?id=3, utt

Ja zinātu, ka visi nolādētie faili ir viena tipa, piemēram, *.doc, tad varētu vienkārši visus pārsaukt par *.doc un lietot laimīgs.

Bet problēma ir tajā, ka starp šiem failiem ir gan pdf, php, doc un sazin vēl kas.

Meklēju risinājumu šai problēmai iekš googles, bet neko prātīgu neatradu. Daudzi ir uzdevuši šādu jautājumu, bet nevienam nebija atbilde.

Vienīgais, ko atradu ir izmantojot -o mainīgo noteikt uzreiz faila nosaukumu, bet šāds piegājiens der tikai, ja tiek nolādēts viens fails un jau ar zināmu paplašinājumu. For ciklā tas nestrādā.

Kāds ir secinājums?

Nolādēt failus ir gaužām vienkārši arī praksē, tikai pēc tam var nākties izlabot failu paplašinājumu.

Manuprāt, problēma slēpjas tajā, ka šādā veidā notiek redirekts uz no file?id uz konkrētu failu, kuru wget programa nespēj korekti paņemt pretī.

for i in {1..7500000}; do
wget http://www2.vid.gov.lv/eds/Pages/GetDuf.aspx?id=$i;
done

Šis piemērs parāda veidu kādā šādas ievainojamības izmantot un attiecīgi modificējot piedzīt arī citiem nedarbiem.

Tas sastāvēja no 5 soļiem:

• Uztaisām lapas pilnu rezerves kopiju (mysql un failu),
• Nolādējam jauno wordpress un to atarhivējam,
• Izdzēšam wp-includes un wp-admin direktoijas,
• kopējam pa virsu jaunos failus (izņemot wp-content direktoriju!!! tai jāsaglabājas vecajai),
• Pirmo reizi logojoties administrēšanas panelī piedāvā izmainīt datubāzes struktūru, to izdarām.

Atjaunināšanas process ir beidzies veiksmīgi.

Ērtāk noteikti būtu izmantot automātisko atjaunināšanas fīču- tiem, kas nav nogriezuši apache lietotājam tiesības rakstīt/dzēst.

Uz ātro nekādas lielas izmaiņas neredzu, ja nu vienīgi administrēšanas panelī background no tumši pelēka ir pārvērties gaiši pelēkā un apziņa- lietoju jaunāko

Papildinājums- aiz intereses sameklēju, kas tad ir īsti jauns 3.0 versijā un kā izrādās ļoti daudz un būtiskas izmaiņas, no kurām man šķita svarīgākās:

• izvēlēties lietotājvārdu instalācijas laikā- jo pēc tam nav jāveido jauns lietotājs un jādzēš ārā admin,
• plašākas pielāgošanas iespējas, kas samazina nepieciešamību labot wordpress failus manuāli (kas man ļoti kaitināja salīdzinot wordpress ar joomlu, kur gandrīz visu varēja izdarīt nelienot pašā kodā).

Tēma likās interesanta un izdomāju to mazliet papētīt…

Kas tad bija it kā izdarīts?

1. Hackers it kā piekļuva viņas kontam un publicēja “privātu” foto.

2. Viņa pēc 8 min. to pamanīja un bildi izdzēsa.

Kas šajā stāstā neiet kopā?

1. Pasākums notika pa nakti un diez vai cilvēks var dažu minūšu laikā pamanīt nesankcionēti publicētu info (kaut gan visādi var būt).

2. Apskatot foto Efix izrādās, ka foto ir uzņemts dažas minūtes pirms pirms tā publicēšanas ar BlackBerry 9000.

3. Apskatot bildi var izdarīt secinājumu, ka pati sevi arī ir bildējusi.

Exif properties apskatīju pats- varat pārliecināties par to, apskatot bildes oriģinālu.

Šo pasākumu neatklāju es, bet par to izlasīju te un vēlējos to pārbaudīt.

Kas ir Exif var palasīt te.

Protams saglabājas iespēja, ka hackers pirms bildes publicēšanas ir izmainījis Exif datus, bet tas jau izklausās baigi sarežģīti.

Nelielu ieskatu BlackBerry pasaulē var iegūt Aivara apskatā te.

Gala secinājums.

Šis gadījums vairāk izskatās pēc mārketinga trika, neveiksmīgas kļūdas pievienojot attēlu vai netīšām nosūtot nepareizam adresātam un cenšoties sevi attaisnot piesauca hacker vārdu.

Biju jau piemirsis cik daudz interesantas un noderīgas informācija var sniegt foto

Par twiter hakošanu-

Googlē lielākā pieejamā informācija ir par lietotājvārda un paroles Brute force.

Otrā iespēja ir izmantojot kaut kādu exploitu, kuru man neizdevās atrast vai arī “twiter DNS ievainojamību“, lai publicētu nepatiesu informāciju.

Kāds liela uzņēmuma direktors, kas vienlaikus bija arī vietējā orķestra patrons, laika trūkuma dēļ piedāvāja sava uzņēmuma efektīvas pārvaldības vadītajam noklausīties Šuberta Nepabeigto Simfoniju.
Pēc koncerta uzņēmuma direktors lūdza pārvaldes darbinieku dalīties iespaidos par izpildījumu. Efektīvās pārvaldības speciālists bija sagatavojis aptuveni šādu ziņojumu:
Es, zemāk parakstījies, iesniedzu šādus vērojumus un ieteikumus saistība ar Šuberta Nepabeigtas simfonijas atskaņojumu, kuru faktiskajos darba apstākļos izpildīja pilsētas orķestris:

• Būtisku laika periodu četriem obojas spēlētajiem nebija, ko darīt, tāpēc ierosinu obojas spēlētāju skaitu samazināt, bet darba pienākumus pārdalīt pārējiem orķestra dalībniekiem, lai izlīdzinātu darba intensitātes līmeni.
• Visas 12 vijoles spēlēja vienas un tas pašas notis vienādā ātrumā un veidā, tādejādi veidojot dramatisku funkciju izpildes dublēšanos un pārklāšanos.
• Vijolnieku skaits ir būtiski jāsamazina. Tomēr, ja ir nepieciešamas sasniegt lielāku skaņas stiprumu un kvalitāti, ierosinu izmantot modernas skanu tehnoloģijas un iepirkt pastiprinātājus.
• Loti daudz pūļu tika patērētas, lai atskaņotu sešpadsmitdaļnotis, kas izvirza liekas prasības izpildītajām, jo lielākā daļa klausītāju nespēj uztvert tik strauju spēlēšanu. Ierosinu samazināt prasības līdz astotdaļnotīm. Līdz ar to varētu izmantot mazāk pieredzējušus muzikantus, nezaudējot kvalitāti.
• Nelietderīgi ir tas, ka mežragi un vijoles atkārtoti izpilda vienu un to pašu motīvu. Ja nevajadzīgi atkārtoto motīvu skaits tiktu samazināts, Simfonijas izpildījumu 2 stundu vieta būtu iespējams nodrošināt 20 minūtēs un iespējams, ka Šuberts būtu pabeidzis savu simfoniju.

Problēma tika novērsta klasiski- atinstalējot pēdējo Windows update.

Šodien tika piedāvāts uzinstalēt kritisku jauninājumu:

Update apraksts ir gana izmeļošs, lai neviens esot skaidrā prātā un pie saprātā to nedarītu.

Microsoftam gan ieteiktu:

• šādus apdeitus nomaskēt
• to darbību aktivizēt pēc ilgāka laika, lai nevarētu noteikt, kurš labojums to izdarīja
• update funkcionalitāti neatļaut atinstalēt vai arī lai pēc atinstalēšanas windows rādītos kā nelegāls

• Atjaunināt uzreiz;
• Atjaunināt izejot no programmas.

Vēl arī saglabājas iespēja ar labās puses X aizvērt formu

Bet tomēr šāda pieeja man šķita gana labs risinājums, jo lielākoties programmas piedāvā:

• Atjaunināt uzreiz;
• Atjaunināt vēlāk.

Manuprāt izmantojot šādu pieeju var panākt ātrāku sistēmas atjaunināšanu, jo atverot programmu lielākoties nav laika to atjaunināt un steidzami ir jāizdara kāpēc to atvēru. Bet atjaunināt vēlāk- parasti ievelkas pāris mēnešus, tāpēc “atjaunināt aizverot programmu” ir labs kompromiss.

Viss sākās ar to, ka atnākot 5dien mājās atvēru pārlūkā savu blogu un tur man priekšā sagaidīja šāda bilde:

No sākuma cerēju, ka tas ir kaut kāds gļuks (naivi ne?) un atvēru administrēšanas paneli, bet tur tiešām kā pēdējais raksts rādījās “Hacked by n2n”.

Jocīgi bija arī tas, ka visi raksti kopš 2009. gada bija ievietoti “Trash”.

Pieņemu, ka nedarbs pastrādāts un brīnumdaris licis mani mierā, lēnā garā mēģinu saprast kas un kā.

Bet, kas tev deva- pēc aptuveni 1. minūtes pienāk epasts no wordpress- admin lietotājam nomainīts epasts un pieprasīta jauna parole.

Skaidrs tagad džekiņš jau mēģina tikt pie wordpress admin konsoles. Neko darīt- jābloķē viņam pieeja

No teorijas- ja vari kontrolēt ko tieši brīnumdaris (hacker) dara tavā lapā, serverī, utt, tas neapdraud draudu konfidencialitāti, integritāti, pieejamību, un ja tas palīdzēs viņu noķert, tad pieeju var riskēt saglabāt.

Ātri ielogojos hostera config panelī un aizliedzu piekļūt visam saturam (izņemot no manas IP).

Darīts- jāsāk skatīties kapēc tas varēja notikt-

Sāku tāpat, kā iepriekšējā rakstā par testa vides problēmām ar webalizer un awstat analīzi.

Skatos references:

pēdējā un svaigākā no pods.lv

Atveru pods.lv- tiešām pie pēdējiem komentāriem “Hacked by n2n”:

Cik sapratu, tas ir plugins, kas attēlo saistītos rakstus un tiklīdz manam rakstam nomainījās nosaukums, tas attēlojās iekš pods.lv.

Viltus trauksme ejam tālāk.

Kas mums ir ar apmeklējumu?

1 apmeklētās apskatījis- 408 lapas un uztaisījis 1507 hitus- uztaisītu noteikti vairāk, ja nepiegrieztu pieeju

Skatāmies, ko viņš ir vēris vaļā:

Tātad ievainojamība bija šajā failā.

Skatāmies vai varam sazīmēt ļauno IP adresi- varam 41.99.45.23. Google piedāvā izsmalcināti info par to.

Atveru wordpres.org un skatos vai nav konstatēta kļūda šinī failā un 2.9.2(pēdējā aktuālā uz to brīdi)- viss kārtībā, kļūda ir bet par to publika vēl nezin

Vairākos forumos (piemēram šinī) ir arī konstatēta šāda problēma, bet pagaidām bez atrisinājuma.

Atveru googli un mēģinu kaut ko sagooglēt.

Martā vienā lapā ir publicēts skaners, kas mēģina exploitēt arī šo failu.

Iespējams, ka pret mani tika pielietots tieši šis Vēlāk biju domājis paeksperimentēt ko viņš tieši dara, kā strādā un kādus rezultātus var iegūt, bet kaut kā vēl līdz šai dienai nav sanācis laiks.

Atšķirībā no iepriekšējā raksta “Hackeri uzbrūk“- šoreiz ir pieejami apache access logs.

Sākumā ar lielu entuziasmu, bet pēc tam ar apnicību gāju tam cauri. Tomēr neko sakarīgu atrast neizdevās.

Visu laiku viens un tas pats-

1) admin-ajax.php failam tiek veikts POST pieprasījums- ļoti žēļ, ka apacis nelogo POST pieprasījumus, tas uzreiz atviegloto manu darbu un dotu skaidru atbildi- ko īsti brīnumdaris tur darīja.

Pats nepārbaudīju, bet uz ātro atradu pamācību, kā iemācīt apacim logot POST datus. Daudzi cepjās- logs augs nejēgā un to visu saglabāt nebūs iespējams, protams, bet ir jau alternatīvas- glabājam īsāku laiku, kopējam uz citurieni, utt. Viss ir atkarīgs vai no šādas info ir jēga- uzlaušanas gadījumā ir.

2) atgriezts rezultāts, pēc tam tiek veikts mistisks GET- cik sapratu atkarībā no POST pieprasījuma rezultāta.

Kas tad beigās tika izdarīts?

• Veidojot mistiskos pieprasījumus http://dll.lv/wp-admin/admin-ajax.php failam brīnumdaris bija izdevies pārvietot lielu daļu rakstu uz trash.
• Viņa posts “Hacked by n2n”, nebija izveidots no jauna, bet vienam rakstam no 2009, gada tika nomainīts saturs un virsraksts.
• Tika izdzēsti visi tagi
• Beigās izdevās nomainīt admin lietotāja epastu un tādā veidā iegūstot admina paroli.

!!!AAA tiko ienāca prātā- vai tikai nebija ievietojis kādā no rakstiem javascript, kas nostrādāja, kad biju ielogojis admin sadaļā un tādā veidā nomainīja admin epasta adresi?

Par labu šai teorijai ir fakts, ka epastu nomainīja apmēram 2. minūtes pēc tam, kad mājās biju ielogojies administrēšanas sadaļā, kaut gan uzbrukums jau bija sācies 1h atpakaļ.

Varbūt sakritība. Bet pārbaudīt man to vairs neizdosies, jo visu iepriekšējo saturu jau esmu izdzēsis.

Secinājumi:

Kārtējo reizi apstiprinās- uzstādod pēdējo “drošo” versiju, neviens nav pasargāts tik un tā.

Uzhakos ne tikai Windows, bet arī ar wordpress..

Backup- tas ir spēks

Manas darbības pēc tam?

Viss kā pēc grāmatas-

Lādējam no wordpres.org wordpress un pluginus no jauna (jo pastāv iespēja, ka esošajā struktūrā ir izveidoti backdoor),

Izveidojam jaunu datubāzi

No rezerves kopijas paceļam pēdējo “drošo” DB versiju (izvēlējos nedēļu pirms uzbrukuma, jo man tā pat pa vidu bija tikai 1 posts.)

Šoreiz nevis vienkārši admin lietotājam uzstādam sarežģītu paroli, bet to izdzēšam.

Uzstādam jaunas paroles.

Meklējam rakstus par wordpress drošību (izrādās viņu ir pa pilno, piemēram šāds) un izpildām to norādījumus

Uzstādam wordpress plugin (http://wordpress.org/extend/plugins/wp-secure-by-sitesecuritymonitorcom/), kas palielina drošību.

Uzstādam plugin (http://wordpress.org/extend/plugins/threat-scan-plugin/) , kas pārbauda vai sistēmā nav kaut kas ieperinājies.

Esam nemitīgā stresā

Tā kā esmu jau aizmirsi, kas man tikai nestāv atveru FTP klientu, lai paskatītos direktoriju saturu.

Identificēju trīs izstrādes lapas, kuras jau ir nodotas un tātad tās var dzēst ārā. Tā kā miglaini atceros, kuras tās bija, tad ar lielu interesi ievadu pirmo:

http://dll.lv/test

Un mani sagaida brīnums

Neliels pārsteigums…

Pārējās lapās izmaiņas nav konstatētas un tās tiek izdzēstas

Gribu saprasta kas un kā.

Skatos failu struktūra vietā, bet ir parādījies jauns fails index.html (faila izveidošanas datums 17.03.2010- tāda vairāk kā mēnesi atpakaļ ), lai tas netraucētu gaisu pārsaucu par index.html1.

Skatāmies, kas notiek ar pašu joomla: Izskatās, ka arī datubāzi izdzēsis- atveru phpmyadmin un tiešām:

Paskatos joomla config failu:

Tas atbild uz jautājumu, kāpēc nav izdzēst viss pārējais- katrai testa sistēmai veidoju vienu  datubāzi un vienu lietotāju, kuram pieeja ir tikai konkrētai datubāzei. Izskatās, ka tas mani ir arī paglābis un brīnumdaris nenonesa pilnīgi visu.

Nav miera un gribu paskatīties dziļāk:

• Joomla logs izdzēsts ar visu datubāzi
• Skatos Apache access log-  ieraksti ir pieejami tikai par pēdējo mēnesi, un līdz 17. maijam vairs nesniedzas. Izmainu konfigurāciju, lai turpmāk visus vecos log failus saarhivē un saglabā (iespējams noderēs, bet ceru ka nē ).
• Skatos error_log- arī nekā.

Hosters piedāvā webalizer un awstat:

• No webalizer kādu sakarīgu info izdabūt neizdodas.
• Awstat-

1. no sākuma intresē, kā viņš ir mani uzgājis- pārbaudu meklētājos izmantotos keywords un keyphrases, par februāri un martu, bet nekā aizdomīga neatradu. Sagaidīju atrast kaut ko līdzīgu “joomla include “”", vai ko tamlīdzīgu.
2. Skatos, ko mēs varam sazīmēt saistībā ar IP adresēm- iegūstu IP adrešu sarakstu par martu un februāri, tomēr šis saraksts neuzrāda apmeklējuma dienu, līdz ar to nav īpaši noderīgs, ja vien netaisos pārbaudīt katru IP atsevišķi- ko es noteikti nedarīšu, jo tas ir pārāk laikietilpīgi (bet ja būtu noticis kas nozīmīgs, iespējams, arī būtu sācis pārbaudi).
3. Skatos apmeklētās lapas par februāri un martu- ir apmeklēta tikai http://dll.lv/test/, bet http://dll.lv/test/administrator nav apmeklēta. Dīvaini- jo biju izvirzījis hipotēzi, ka uzlaušana notika, jo administratora parole testa videi bija triviāla, bet ja administrēšanas lapa netika apmeklēta šis pieņēmums neapstiprinās.
4. Meklētās lapas, kuras netika atrastas vai atgrieza kļūdas paziņojumu- nekas interesants saistībā ar testa vidi, bet skatoties atklājās, ka kāds ir meklējis arī ievainojamības pašā blogā. Uz to norāda, piemēram šādi ieraksti:

///administrator/components/com_virtuemart/export.php
/wp-content%20%C2%BB%3Ca%20href=
/guestbook/public/paypal.fr/webscrcmd=_login-run/cgi-bin/login/Confirm.php
/_vti_bin/owssvr.dll
//path/authentication/phpbb3/phpbb3.functions.php
utt.

5. Skatos ārējos refferers un starp tiem aizdomīga ir tikai http://www.sa-hacker.com/vb/showthread.php.

Izskatās, ka esmu kaut ko uzķēris un droši veru lapu vaļā, bet ir aplauziens- viss ir arābu valodā un lai arī kaut ko redzētu ir nepieciešams reģistrēties. Reģistrācijai palīdz google tulkotājs, jo no tiem ķeburiem neko saprast nevar (ja kādam ir intrese par turieni paložņāt- user: zumzum, pass:zumzumzum, email:zumzum@spam.la). Izmeklējos par forumu, bet tomēr neko sakarīgu neatradu.

Kāds tad ir sausais atlikums?

Pēc analīzes secinu, ka ir izdzēsta datubāze, izveidots viens jauns fails, bet pārējā failu struktūra nav mainīta vai dzēsta.

Diemžēl nesanāca atklāt kādā veidā šis brīnums tika pastrādāts un līdz ar to neko prātīgu ieteikt neizdodas (iespējams bija novecojusi un bug -aina joomla vai tās komponente (tas gan mazticams, jo webalizer neuzrādīja apmeklētas kādas lapas, piemēram: dll.lv/test/component/crack.php?upload…) versija).

No šiem meistariem neesam pasargāti, bet, lai mazinātu to ietekmi:

• taisām backup
• katrai sistēmai izdalām savu DB un atsevišķu lietotāju, kuram nav piekļuve citām datubāzēm.
• saglabājam auditācijas pierakstus ilgāk..
• vienmēr uzstādam pēdējos drošības ielāpus
• ja ir iespēja uzstādīt papildus perimetra aizsardzību, piemēram, revers proxy
• ja gadījies kāds incidents, tad to iespēju robežās izmeklējam un izdarām secinājumus, nevis ignorējam un ceram, ka tas neatkārtosies.

PS.
Tagad laikam ir īstais brīdis pateikt ko es domāju par šiem brīnumdariem- neko labu.

Manās acīs tie ir visādi mūdži, kuri nodarbojas tikai ar savu ģenitāliju staipīšanu.
Cita lieta ir drošības speciālisti, kuri atklāj, konsultē un palīdz novērst (par naudu- protams) drošības ievainojamības vai ari hackeri, kuri iegūto informāciju izmanto ekonomisku labumu gūšanai, piemēram, izpirkuma maksas pieprasīšanai vai citas informācijas iegūšanai, ar kuru pēc tam operējot var uztaisīt skanošo- piemēram, kā ukraiņu hakers.

Bet vienkārši atrast lapu ar konkrētu ievainojamību, to izdzēst, nemaz neiedziļinoties kam tā pieder un kam tā kalpo?? Tas, manuprāt, ir zem jebkāda goda, kaut palasot pievienotās rindiņas index failam- šim cilvēkam no Palestīnas tāda nemaz nav bijis kopš dzimšanas:

I aM: A FrEe PaLeStIn!aN’s HaCK3eR

I DoN’t ApPeAr InTelLeGaNcE, BuT I AiM To DeStRoY InTeLlEgAnT

DoN’t ChAlLeNg A PeRsOn WhO HaS N0N To LoSe

PlAyInG WiTh Ch!LdReN DoSeN’t EnTeRtA!N Me

AdM!n DoN’t CrY….. CrY!Ng Is N0T A MaN’s ShArM