Pārdomas par Neo nedarbiem

Neo atrasts, visi par to runā, laiks arī man uz papīra (ekrāna) uzlikt nedaudz pārdomas visā šajā sakarā.

Eksistē viedoklis, ka Neo neko vispār nav pārkāpis, jo ir piekļuvis tikai informācijai, kas “brīvi” pieejama internetā. Es tam īsti nevaru piekrist, jo:

  • ja adrese būtu http://eds/download?user=viesis&pass=viesis, nevienam nerastos šaubas, ka minot dažādas user un pass vērtības, mēs apejam autorizācijas sistēmu;
  • ja adrese būtu http://eds/download?id=A7F1CB37-BD2B-45F8-9006-5C4279ED62D9, tad id vērtības minēšanu (3,4 * 10^38 dažādas kombinācijas) viennozīmīgi var atzīt par laušanu;
  • ja adrese būtu http://eds/download?pass=100, ar ko īsti tas atšķiras no pirmā varianta – vienīgā atšķirība ir tas, ka parole ir muļķīgi vienkārša;
  • iepriekšējā piemērā lauku nosaucot par id, nevis pass mēs iegūstam reālo EDS situāciju – lejupielādes ir aizsargātas, taču ar ļoti muļķīgām parolēm – vienkāršiem skaitļiem no 1 līdz, piemēram, 2 000 000.

Viens no argumentiem, kāpēc šī darbība ir attaisnojama, ir tas, ka visi dati esot bijuši brīvi pieejami internetā. Atkal tas ir kas tāds, kam nevar piekrist. Piemēram:

  • zaglis, kurš iekļūst mājā, izmantojot labi paslēptu, bet neaizslēgtu logu, ir tikpat vainīgs kā tas, kurš atlauž durvis;
  • ja, piemēram, delfi.lv būtu administrācijas sadaļa, kura nav aizsargāta nekā savādāk, kā vien ar slepenu adresi (piemēram, http://delfi.lv/admin/) – jebkurš, kurš piekļūst šai sadaļai, vienkārši uzminot šo adresi, ir savā veidā uzlauzis sistēmu (tiesa, apejot ļoti vienkāršu security by obscurity risinājumu).

“Brīvi pieejams internetā” varētu tikt attaisnots ar to, ka eksistētu lapa X (piemēram, kāds blogs), kurā būtu publicētas šīs adreses. Šajā gadījumā vainot varētu informācijas publicētāju, nevis izmantotāju, līdzīgi kā gadījumā, kad con artist pārdod personai māju, kas viņam nepieder, vainīga nav šī persona, kas tagad ieiet svešā mājā, bet gan con artist-s, kas šo māju pārdeva.

Turpinot šo domu, varētu pieņemt, ka Neo kaut kur interneta plašumos uzgāja vienu šādu adresi, piemēram, kāda uzņēmuma grāmatvedis bija nokopējis linku no sistēmas un kaut kur pieglabājis vēlākai lietošanai. Šādā situācijā, ja vien kopā ar adresi nebija publicēti tās lietošanas ierobežojumi, neko nevar pārmest ziņkārīgam cilvēkam, kas to atvēra un apskatījās.

Atverot šādu adresi var ieraudzīt vienkāršu XML dokumentu ar vārdiem, nosaukumiem, skaitļiem – taču neko, kas pateiktu, kas tie par datiem un kādiem mērķiem tā ir izmantojama (piemēram, teksta dokumentos šāda informācija ir vai nu sākumā, vai dokumenta “kājenē”). Un atkal ar ziņkārību var attaisnot to, ka ieraudzījis adresē ciparus, šī persona izdomā pamainīt tos un paskatīties, kas notiek.

Te parādās viena liela problēma ar mūsdienu sistēmu datiem – ja reālos, parakstītos dokumentos tiek iekļauti to izmantošanas nosacījumi, konfidencialitātes prasības, dokumenta auditorija un tas viss tiek uztverts par vienu veselumu, tad dažādiem apstrādātiem datiem dažādās strukturētās formās gandrīz nekad nav pievienoti šādi meta dati. Kas ļauj, iegūstot šādu dokumentu ārpus konteksta, neapzināties sekas šīs informācijas izmantošanai.

Ja turpinam par ziņkārību – manuprāt, ar šo argumentu varētu Neo diezgan veiksmīgi aizstāvēties (galu galā, neviens taču nepārmetīs, ja http://tvnet.lv/news/123 tiks aizstāts ar http://tvnet.lv/news/666, tomēr šeit ir viena nopietna problēma. Nav iespējams apgalvot, ka Neo neapzinājās, ka piekļūst informācijai neatļautā veidā, jo viņš slēpa savas pēdas, maskējoties aiz [visdrīzāk] dažādiem proxy vai līdzīgiem risinājumiem. Kā arī pēc pirmās informācijas publicēšanas viņš nenāca klajā ar paziņojumu, ka “atvainojiet, es tiešām nezināju, ka šī informācija ir konfidenciāla – tā taču bija tik brīvi pieejama”.

Rezumējot, mans viedoklis ir, ka Neo būtu pelnījis kādu no simboliskajiem sodiem – brīdinājumu vai, piemēram, publisko darbu (ko varētu veikt, auditējot citas valsts IT sistēmas), kas pamatojams ar to, ka viņš ļoti apzinīgi rīkojās, izplatot tālāk iegūto informāciju – necieta privātie uzņēmumi vai individuāli cilvēki (ja vien tie nebija attiecīgo uzņēmumu vadībā). Paralēli tam vajadzētu nopietni piestrādāt, lai sakārtotu likumdošanu saistībā ar to, ko drīkst un ko nedrīkst šādas ziņkārības vadīti personāži darīt – skaidri noteikt, piemēram, ka jebkura informācija “.gov.lv” domēnos ir konfidenciāla, ja vien nav noteikts savādāk.

Remote Desktop drošība ar SSL sertifikātu

Remote Desktop (jeb Terminal Services) protokols ar katru Windows versiju lēnām attīstās. Pēdējās versijās (sākot ar Windows Vista) krietni uzlabota ir arī protokola drošība – pirms savienojuma izveides tiek pārbaudīta servera (ar serveri domāts dators, pie kura slēdzas klāt, tam nav obligāti jābūt ar servera operētājsistēmu) identitāte. Aktīvajā direktorijā problēmu ir maz – identitāti pārbauda, izmantojot domēna līdzekļus (Kerberos autentifikāciju).

Šo identitātes pārbaudi gan var atslēgt sistēmas uzstādījumu attiecīgajā sadaļā. Tas ļauj pie datora pieslēgties izmantojot vecākas Remote Desktop klienta versijas, piemēram, tās, kas iekļautas Windows XP.Drošības līmeņa uzstādījumi

Ja servera identitātes pārbaude ir atslēgta (vai serveris to neuztur), tad jaunās klienta versijas attēlos brīdinājumu, pirms vēl tiek prasīts ievadīt lietotāja vārdu un paroli.
Brīdinājums, ja atslēgta identitātes pārbaude 

More...

IIS7 FTP SSL konfigurēšana

Nokonfigurēt IIS7 piedāvāto FTP protokola šifrēšanu, izmantojot SSL, nebija gluži tik elementāri, kā būtu gribējies. Ja neizmantotu FTP virtuālos hostus, tad viss būtu bijis vienkāršāk, bet diemžēl šoreiz tā nebija.

Viss it kā diezgan vienkārši - atveram FTP saitu un izvēlamies SSL sertifikātu. Nekā, piedzīvoju kļūdu: "534 Local policy on server does not allow TLS secure connections". Izrādās, SSL sertifikāts jānorāda nevis konkrētam saitam, bet gan visam serverim. Principā jau loģiski, jo enkriptēšana ir nepieciešama vēl pirms tiek ievadīts lietotāja vārds.

Bet, norādot sertifikātu serverim, dabūju kļūdu "431 Failed to setup secure session." kā atbildi uz "PROT P" komandu. Te nu izrādījās, ka konkrētam saitam SSL sertifikāts tomēr ir vajadzīgs, lai nodrošinātu datu konekcijas enkriptēšanu.

Nobeigumā varbūt noderīgs links par FTP SSL konfigurēšanu ar visām bildītēm, kā arī pamācību, kā konfigurēt Windows iebūvēto ugunsmūri: Configuring FTP Firewall Settings.

miga.lv atjaunots SSL sertifikāts

Šodien tika atjaunots SSL sertifikāts miga.lv servisiem (FTPS, HTTPS, IIS7 remote management). Iepriekšējā sertifikāta derīguma termiņš izbeidzās pirms pāris dienām tāpēc iespējams, ka kāds redzēja atbilstošos brīdinājumus.

Neliela piebilde - kad sertifikāta pieprasījums tiek izpildīts, nevajag jauno sertifikātu kaut kādu iemeslu dēļ dzēst ārā. Otru reizi izpildīt sertifikāta pieprasījumu nav iespējams. Kļūda, kura man izleca otrajā mēģinājumā, bija "certEnroll::CX509Enrollment::p_InstallResponse: ASN1 bad tag value met. 0x8009310b (ASN: 267)". Paglāba informācija šajā rakstā: The Way I See It. Pievienoju sertifikātu ar roku un izpildīju rakstā minēto pēdējo komandu, lai sertifikātam atjaunotu privāto atslēgu.

Veids, kā var mēģināt lauzt hostinga serverus

Pienācis laiks aprakstīt kādu drošības caurumu, kas bija viens no galvenajiem iemesliem, kāpēc atteicos no vecā miga.lv servera un Apache web servera. Šis raksts netika rakstīts ar domu, ka kāds šo caurumu nu sāks izmantot (ceru, ka lielajos hostinga serveros tas nav iespējams), bet, lai serveru administratoros raisītu pārdomas par to, kā, apvienojot dažas nekaitīgas funkcijas, var panākt sliktas lietas.

Problēma sastāvēja no vairākām, atsevišķi nekaitīgām, detaļām:

  • uz servera bija atļauts .htaccess failā definēt MIME tipus;
  • PHP moduli web serveris palaiž atkarībā no faila MIME tipa;
  • uz servera bija iespējams veidot un lietot simboliskos linkus.

Katrs no šiem punktiem ir nepieciešams noteiktos scenārijos un pats par sevi neko sliktu nevar izdarīt.

Par caurumu tie pārvērtās sekojošā situācijā:

  • servera ļaunais lietotājs izveido simbolisko linku uz kāda cita klienta direktoriju;
  • ļaunais lietotājs direktorijā, kurā atrodas šis links, izveido .htaccess failu;
  • .htaccess failā ļaunais lietotājs norāda, ka .php failiem MIME tips ir text/plain, papildus vēl ieslēdz arī direktoriju pārlūkošanu;
  • ļaunais lietotājs caur pārlūkprogrammu piekļūst šim linkam, iegūstot pieeju visiem otra klienta .php failiem kā tekstam.

Tā kā .php failos parasti ir tīrā tekstā saglabātas datubāzes paroles, ļaunais lietotājs var piekļūt svešām datubāzēm. Papildus ļaunais klients iegūst pieeju cita lietotāja intelektuālajam īpašumam (lapas kodam).

Vienīgā aizsardzība, kas tika izveidota uz miga.lv vecā servera, bija regulāra pārbaude, vai kāds lietotājs neveido simboliskos linkus uz svešām direktorijām. Diemžēl, nesamazinot piedāvāto funkcionalitāti, ar izmantoto programmatūru šo caurumu izlabot nevarēja.