3. social engineering

Kurssisivu ja tehtävät: https://terokarvinen.com/2021/hakkerointi-kurssi-tunkeutumistestaus-ict4tn027-3005/

Vierailijaluento: Social Engineering – Riku Juurikko

“Social engineering is any act that influences a person to take an action that may or mat not be in his or her best interests.”
Christopher Hadnagy

Mikä on social engineering?
- Toisen henkilön vaikuttaminen tai manipuloiminen, ei välttämättä aina negaatiivisesti
- Tavallisin tapa saada pääsy organisaatioon, ihminen yleensä heikoin lenkki – phising
- Pieni riski – melko halpaa – valtava palkkio

Tiedustelu -> Tutkimus -> Hyväksikäyttö -> Levittäminen -> Jälkien siivoaminen

Päämäärä/motiivi – raha (#1), poliittinen vaikuttaminen, vakoilu, kilpailuetu, kauna/kosto, maine/huomion herättäminen
Tiedot – mitä me halutaan, mistä se löytyy, miten se validoidaan?
- Tunne kohteesi
  - organisaation rakenne
  - yhteistyökumppanit
  - palveluntarjoajat
  - avoimet tai menneet työhakemukset (tietoa järjestelmistä, yhteystietoja jne.)
  - kiinnostavia domaineja – ADFS login
  - avoimet palvelut – haavoittuvia palveluita
Intelligence Collection Plan (ICP) – mitä halutaan saavutta ja mitä siihen tarvitaan
- modernien armeijoiden ja tiedustelupalveluiden käyttämä suunnitelma/prosessi
- edistyksen seuraaminen ja tehtävien jako
- tehtävien käsittely, resurssointi
Basic data gathering toolkit
- osintframework.com
- Bellingcat’s online investigation toolkit
- fonecta.fi / finder.fi (yritystiedot)
- hakukoneet
Tiedon pakkauspretexting – esittäminen – mikä on päämäärä, perustuu tiedusteluun, mitä enemmän tiedät, sitä parempi tekosyy, ulkonäkö
- phising – ylivoimaisesti tavallisin, s-posti
- smshishing – lähettäjän numeron spoofaaminen
- vishing – haittapuhelu, väärennetty tuki tai myynti

Principles of persuasion – Robert Cialdini (https://en.wikipedia.org/wiki/Influence:_Science_and_Practice

Reciprocity – vastavuoroisuus
- “quid pro quo” – “something for something”
- markkinointi, myynti, politiikka
- lahjoja, palveluita – tee aloite, rakenna luottamusta
Scarcity – niukkuus
- “The way to love anything is to realize that it might be lost”
- markkinointi, myynti, huijaus
- kiirellisyys tai rajoitettu tarjonta
Authority – auktoriteetti
- “It is not wisdom but authority that makes a law”
- asiantuntijoiden ja vallanihmisten kunnioittamisen hyväksikäyttö
Commitment & Consistency – sitoutuminen ja johdonmukaisuus
- ”It is easier to resist at the beginning than at the end”
- tuttuihin asioihin luottaminen
- lähesty kohdetta pienellä helposti hyväksyttävällä pyynnöllä
- huono kielioppi phising-viesteissä helpon kohteen löytämiseksi?
Liking – pidettävyys
- ”If you like the stuff that I do, my chances of liking you go up.”
- luottamuksen kasvattaminen – vaikuttavat tekijät: huollettu ulkonäkö, samankaltaisuus, kohteliaisuus, yhteistyöhaluisuus, asioiden yhdistäminen
Social Proof – sosiaaliset todisteet
- ”When all think alike, no one thinks very much.”
- laumakäyttäytyminen, ihmisillä on taipumus seurata muiden käyttäytymistä
- hammaslääkärin suosittelema, suosituimmat tuotteet, ilmaiset tuotteet jne.
Unity – yhtenäisyys
- “All for one and one for all, united we stand divided we fall.”
- yhteenkuuluvuuden tunne samanlaisista uskomuksista, arvoista, rodusta, perheestä jne.
- tämän periaatteen käyttö ja hyödyntäminen tunkeutumistestauksessa tulisi välttää

OWASP OWASP 10 2017 (pdf)

A1 Injection
- yksi tavallisimmasta verkkohyökkäysistä
- hyökkääjä murtautuu tietokantaan ja voi muuttaa tai tuhota tietoja ja pahimmassa tapauksessa hyökkääjä voi adminina hallita koko tietokantaa
  - Käytännössä tämän tehdän sotkemalla ja manipuloimalla tietokannan pyyntöjä.
  - esim. kirjautumissivu, johon hyökkääjä syöttää kirjautumistiedon tilalla SQL kommennon. Kommennon avulla hyökkääjä voi hakea tietokannasta dataa tai tutkia tietokannan rakennetta, jonka avulla hyökkääjä voi tunnistaa haavoittuvuudet.
- käyttäjän syöttämä data ei validoida tai filtteröidä
- esimerkkisyöte: or 1=1 (lause on aina tosi)
- SQL Injectionia voi välttää validoimalla tietokannan pyynnöt, esimerkiksi syötettyjen merkkien perusteella. Tämän voi toteuttaa esimerkiski tietyillä parametreillä koodissa.
A2 Broken Authentication
- hyödynnetään todennuksen ja istunnonhallintaan liittyviä virheellisiä asetuksia
  - höykkääjä voi saada käsiinsä salasanoja, avaimia ja istuntomerkkejä tai esittää toisia käyttäjiä väliaikaisesti tai pysyvästi
- käytössä olevat salasanat ovat heikkoja tai defaulteja
- session IDt URLssä tai session IDt jäävät voimaan
- hyökkäyksiä voi olla salasanaan kohdistuvia esim. brute force tai sanakirjahyökkäyksiä. Vaihtoehtoisesti voi myös manipuloida tai saada haltuun session ID:ä tai avaimia.
- hyökkäystä on mahdollista välttää ottamalla käyttään multi-factor autentikaatiota, vaihtamalla default salasanat, salasanapolitiikalla, seuraamalla epäonnistuneet loginit, suojaamalla session IDt
A3 Sensitive Data Exposure
- monet sovellukset ja APIt eivät suojaa kunnolla arkaluonteisia tietoja, kuten talous-, terveys- ja henkilötietoja
  - heikkoa avainten luontia ja hallintaa
- heikkoa suojausta voi hyödyntää esim. luottokorttipetoksissa ja henkilöllisyysvarkauksissa
- arkaluonteiset tiedot voivat vaarantua tallennuksessa tai siirtymisessä, jos niissä ei ole ylimääräistä suojausta, esim. man-in-the-middle
- tietoja on mahdollista saada haltuunsa esim. SQL injectionilla tai packet snifferin avulla (esim. Wireshark)
- Haavoittuvuuksia voidaan välttää päivittämällä tietojen salausmenetelmiä, tallentamalla ainoastaan tarvittavaa tietoja ja salattuna
A7 Cross Site Scripting
- hyökkäys, jossa hyökkääjä tunkeutuu luotettavien sivustojen tietoihin.
- haavoittuvuuksia voi hyödyntää esimerkiksi kaappaamalla kirjautumisia varastamalla evästeiden tietoja tai muuttamalla sivuston näkyvyyttä ja käytettävyyttä.
  - Sivuston koodiin voi esimerkiksi piilottaa scriptejä jotka uudelleenohjaavat käyttäjän vahingollisiin sivustoihin tai varastavat käyttäjän tietoja.
    - hyökkääjän on mahdollista jopa saada täysi hallinta käyttäjän järjestelmästä
    - esimerkkisyöte:

<img src=“http://malicious.site.com/image.jpg/>
“>GoodYear recommends buying BridgeStone tires…

Cross-site scriptingille sopivia haavoittuvuuksia voi esiintyä esimerkiksi silloin, kun sivusto ei käsittele ja vastaa http-pyyntöihin turvallisella tavalla. Tällöin tätä pyyntöä ja sen vastausta on mahdollista muokata.
- Haavoittuvuuksia voidaan välttää esimerkiksi filtteröimällä ja validoimalla käyttäjän antamia tietoja, ja salata näitä.

Santos et al 2018: Hacking Web Applications The Art of Hacking Series LiveLessons (video): Security Penetration Testing for Today’s DevOps and Cloud Environments: Lesson 5: Authentication and Session Management Vulnerabilities

Authentication – verifying that an individual, entity or website is whoever they are claiming to be
- commonly performed by submitting a username or identifier and one or more items of private information, ex. password, key, token
Session management – how a server maintains a state of an entity that it’s actuallt interacting with, remember how to react with subsequent requests
- session id – passed back and forth between server and client when transmittinf or receiving requests
  - should be unique and difficult to predict
Web authentication scheme – method/process to pass credentials from a user authenticating to a system, vary in security and complexity
- SSL/TLS – typically used to ensure confidentiality, required for many authentication schemes
  - digital certificate / PKI – proves ownership of public key
    - trust chain: Certificate Authority CA -> root cert
    - browser has list of trusted CAs
  - simple vs mutual / one-way vs two-way authentication
    - simple: https connection from browser is established, client is verifying digital certificate of server
    - mutual: simple process + server requests the client to present certificate and check its owns collection of trusted certificates to determine to trust client
  - TLS-SRP – Secure Remote Password – password-based client authentication to server without need of certificate, not widely adopted
- HTTP Basic Auth – pop-up messages in browser, no cookies, no handshakes
  - dedicated HTTP header to communicate encoded username and password, requires to cache credentials, pairs with SSL/TLS
  - drawbacks: no standard way to logout, no way to customize the login, client prompts, client needs to secure transactions, insecure
- HTTP Form-based Auth – popular, simple, customizeable login
  - prompts username and password using HTML form
  - requires SSL/TLS
- Digest Access Authentication (DAA)
  - only sends MD5 hash to server
  - not secure – collisions, weak hashing algorithm
- Lightweight Third-party Authentication (LTPA) – IBM proprietary method
  - SingleSignOn – used in conjunction with another authentication technique
  - LTPA-token / cookie created when user logs in
- OAuth, OAuth 2 – authorization scheme, popular, requires TLS
  - application registration
  - redirect URI – used for redirecting user from provider back to consumer
    1. consumer makes resource request to provider
    2. provider informs user of request and prompts authentication (any authentication scheme)
    3. temporary access token in HTTP header
  - user credentials are never exposed to application
- OpenID (OID) / OpenID Connect – open standard for providing authentication
  - used by yahoo, google, wordpress
  - relying party RP – client outsourcing authentication to OID
  - attribute exchange extension – profile attributes to be provided from OID to RP
  - allows a user to maintain a single profile with OID provider of choice + authenticate with any third-party website/mobile app as RP
- Security Assertion Markup Language SAML –
  - XML based open standard, maintained by Oasis
  - used for both authentication and authorization
  - capable of exchanging user profile attributes
  - current leading standard for inter-domain SSO
Web session – sequence of HTTP requests and responses between web client and web server
- pre-authentication tasks – authentication process – session management -access control – session finalization
- many web applications keep track of information about users for duration of transactions
  - variables: access rights, localization settings etc.
  - provide session capabilities both before and after authentication
  - once an authenticated session has been established, session ID/token is temporarily equivalent to the strongest authentication method used by application
- Session ID / token (ID = “12345678abcdefg”)
  - provided users by applications to keep the authenticated state and track user’s progress
  - assigned at session creation, shared and exchanged by user and web application for duration of session
  - “name = value” pair
  - easily fingerprinted: PHPSESSID -> PHP framework
  - most be long 128 bits/16 bytes + unique and unpredictable = good PRNG (at least 64 bits of entropy)
- Session ID exhange mechanisms – mechanisms in HTTP to maintain session states within web applications
  - cookies (most widely used), URL parameters (RFC2396), URL arguments on GET requests, body arguments on POST requests: hidden form fields, HTLM forms, or prioprietary HTTP headers
  - session id should not be included in URL – can lead to manipulation or session fixation attacks (inject or manipulate session id on victim’s web browser)
- Session management
  - web frameworks provide session management features
  - encrypt entire web session, ensure that elements are only exchanges through an encrypted channel
  - session management based on cookies uses:
    - persistent – has “max age” or “expires” attribute, will be stored in browser until expiration
    - non-persistent (session cookies) – session info is deleted from client if browser instance closed
  - session id must be carefully validated and verified by application depending on session management mechanism used
    - session id will be received in GET or POST parameter or in URL or in HTTP header using cookies
  - if web applications do not validate or filter invalid session IDs they can be potentially exploited by other vulnerabilities
    - SQL injection if session id is stored in a database or persistent
    - Cross-site scripting if session is stored and reflected back afterwards by web application

Percival & Samancioglu 2020: The Complete Ethical Hacking Course (video): Chapter 21: Cross Site Scripting

What is XSS? – inject some JavaScript code in the web server – code won’t be run on server but on clients (victim) browser

Reflected XSS

manipulate any URL and send it to our victim, when a victim clicks on the URL, a JavaScript code will be run on their browser
submit code script instead of parameters in URL

Stored XSS

store code script on website

Real Hacking with XSS

BeEF Hooking JavaScript code in Cross-Site Scripting attack
- all users landing on webpage is hooked to BeEF Control Panel
- full control – run any command in their browser

How to Protect Yourself?

stay away from untrusted, unkown websites
disable JavaScript in browser (may distort view and functionality of trusted websites as well)

a) Social Engineering case study

2015 – 03 – 26: Security alert: Infamous DarkComet RAT Used in Spear Phising Campaigns https://heimdalsecurity.com/blog/darkcomet-rat-phishing-campaigns/

Kohteena useita arkkitehti-firmoja Tanskassa
- aikaisemmin sama cyber-rikollisryhmä oli hyökännyt samanlaisilla menetelmillä tanskalaisia kiropraktikkoja vastaan
Kohdennettuja ja räätälöityjä sähköposteja täydellisellä tanskan kielellä
Haitallinen koodi sisälsi DarkComet RATin

Spear Phising – Spear phishing is a type of phishing that is highly targeted against a single individual inside an organization. This type of phish is built using content that is personal and believable. It usually doesn’t stand out too much from the company’s normal email stream.
https://www.hoxhunt.com/blog/what-is-spear-phishing-and-how-do-you-recognize-it/

DarkComet RAT – a remote access trojan (RAT) developed by Jean-Pierre Lesueur (known as DarkCoderSc) … DarkComet allows a user to control the system with a graphical user interface. It has many features which allows a user to use it as administrative remote help tool; however, DarkComet has many features which can be used maliciously. DarkComet is commonly used to spy on the victims by taking screen captures, key-logging, or password stealing.
https://en.wikipedia.org/wiki/DarkComet

Tapahtumakulku

Haitallinen sähköposti, henkilökohtaisesti muotoiltu ja kohdennettu

2. Sähköposti sisältää tekaistun Dropboxin linkin -> lataa AutoCad-export.exe -tiedoston

3. Jos tiedoston suorittaa, se voi käynnistää seuraavat toimet:

keylogging
tietojen keruu
näytön sieppaaminen
aktivoida mikrofoonia ja webcamia
käynnistää RDP-yhteyden

4. Pääkomponentit tallentuu tähän: C:Users[brugerkonto]AppDataRoamingMicrosoftSecuritywinsec.exe

5. Haittaohjelma käynnistää tekaistun virheviestin uhrin hämäämiseksi

6. Seuraavat tiedostot kopioidaan tartunnan saaneeseen järjestelmään:

C:DOCUME~1[Brugerprofil]LOCALS~1TempAutoCad-export.INI
C:DOCUME~1[Brugerprofil]LOCALS~1TempAutoCad-export.exe.config
C:DOCUME~1[Brugerprofil]LOCALS~1TempAutoCad-export.exe
C:nzlvnwssfdllyuESBS.dll

Ja muutoksia tehdään rekisteriin:

HKEY_CLASSES_ROOTAppIDwinsec.exe
HKEY_CLASSES_ROOTAppIDAutoCad-export.exe

Pääasiallinen haitallinen koodi on suojattu antivirusohjelmalta Cryptorin avulla, payload WebMatcher3.exe . Cryptor voi tehdä seuraavat toimet:
- päivittää
- käynnistää etähallinnan
- lähettää liikennettä verkkosijaintiin
- käynnistää DDos hyökkäyksen
Tärkeimmät Command & Control palvelimet ovat Kanadassa

Olisiko ollut vaihtoehtoisia tai parempia tapoja toteuttaa hyökkäys? Millä keinoin hyökkäyksen olisi voinut estää, havaita tai rajoittaa sen vaikutusta?

Tyylikäs ja ammattimainen hyökkäys ja ei ollut täysin samanlainen kuin edellinen
Koska käytetty haittaohjelma DarkComet RAT oli varsin tunnettu, siihen olisi voinut varautua erityisellä suojauksella + pitämällä järjestelmät ja sovellukset päivitettynä
Varmuuskopioimalla järjestelmiä ja tietoja säännöllisesti on mahdollista palauttaa kaiken mahdollisen hyökkäyksen seurauksena

b) Rikun viitteet. Tiivistä tai poimi 3-5 avainoppia jostain (yhdestä) Rikun kalvoilla mainitusta lähteestä.

Tutustuin tarkemmin DNSTwist työkaluun, https://github.com/elceef/dnstwist

DNSTwist – mitä tapahtuu, jos käyttäjä kirjoittaa domainin väärin?

Etsii samankaltaisia domaineja, joita on mahdollista käyttää höykkäyksessä
Havaitsee typosquattereita, phising-hyökkäyksiä, petoksia ja tuotemerkin esiintymiset
Kohdennettu uhkatiedustelu

Typosquatting, also called URL hijacking, a sting site, or a fake URL, is a form of cybersquatting, and possibly brandjacking which relies on mistakes such as typos made by Internet users when inputting a website address into a web browser. Should a user accidentally enter an incorrect website address, they may be led to any URL (including an alternative website owned by a cybersquatter).
https://en.wikipedia.org/wiki/Typosquatting

DNS fuzzing

luo domainin perusteella luettelon variaatioista ja tarkistaa onko mikään niistä käytössä
luo verkkosivuista fuzzy hashes ja tarkistaa ovatko ne osa aktiivista hyökkäystä, kuten phising tai tuotemerkin esiintymistä

Fuzzing or fuzz testing is an automated software testing technique that involves providing invalid, unexpected, or random data as inputs to a computer program. The program is then monitored for exceptions such as crashes, failing built-in code assertions, or potential memory leaks.
https://en.wikipedia.org/wiki/Fuzzing#Browser_security

Asennus ja vaatimukset

# Python PIP
$ pip install dnstwist

# Kali Linux:
$ apt install dnstwist

# Docker
$ docker run elceef/dnstwist

standard Python3 kirjasto + muutama kolmannen osapuolen pakettia
esim. Debianilla:

$ sudo apt install python3-dnspython python3-tld python3-geoip python3-whois \
python3-requests python3-ssdeep

Käyttö

ajaa annetun domainin fuzzing algoritmiensa läpi ja luo listan potentiaalisista phising domaineista
fuzzy hashing – argument: –ssdeep
- dnstwist hakee jokaisen luodun domainin kohdalla vastaavasta HTTP-palvelimesta ja vertaa sen fuzzy hashia alkuperäiseen, samankaltaisuus ilmaistaan prosentteina
suorittaa yksinkertainen testi kullekin sähköpostipalvelimelle (mainostettu DNS MX -tietueella) tarkistaakseen voidaanko palvelua käyttää vihamielisena sähköpostin honey potina
tulostus CSV- ja JSON-tiedostoihin

$ dnstwist --format csv domain.name | column -t -s,
$ dnstwist --format json domain.name | jq
$ dnstwist --format list domain.name

c) WebGoat

A2 Broken authentication:
- Authentication bypasses: 2 2FA Password Reset

Lähetän ensin tyhjän lomakkeen, ja tarkastelen mitä tapahtuu. Eli se lähettää verify.account POST kyselyn. Koitan muokata sitä, eli valitsen “Edit and resend”.

Tässä jouduin pohtimaan millä tavalla sitä voisi muuttaa, jotta se toimisi haluamallani tavalla. Tähän auttoi vihje: “Have you tried renaming the secQuestion0 and secQuestion1 parameters?” Eli nimeän parametrit uudelleen.

secQuestion0=&secQuestion1=&jsEnabled=1&verifyMethod=SEQ_QUESTIONS&userId=12309746
->
secQuestion2=&secQuestion3=&jsEnabled=1&verifyMethod=SEQ_QUESTIONS&userId=12309746

Vaihdan ne myös lomakkeen HTML koodissa:

Ja painan uudelleen submit, ja nyt turvakysymykset on ohitettu!

Secure Passwords: 4 How long could it take to brute force your password?

Tämä oli varsin helppo tehtävä. Hyvä salasana on tarpeeksi pitkä, sisältää erilaisia kirjaimia ja numeroita mutta ei kuitenkaan koostuu vain yhdestä sanasta. Salasanalauseita on helppo muistaa ja niistä saa helposti tarpeeksi monimuotoisia.

A3 Sensitive data exposure
- Insecure Login: 2 Let’s try

Kokeilin tätä ensin Firefoxin Developer Toolseilla, ja tunnukset löytyivät näin varsin helposti.

Sen jälkeen oli helppoa syöttää tunnukset sopiviin kenttiin.

A7 Cross Site Scripting (XSS): Cross site scripting
- 2 What is XSS?

Kuten tehtävässä käskettiin, avasin uuden tabin samalle WebGoat-sivulle, ja syötin URLiin javascript:alert(document.cookie);

Vertailin molempien sivujen sessionIDt, ja ne olivat samat.

7 Try It! Reflected XSS

Vihje: Quantity inputs are probably processed as integer values. Not the best option for inputting text right? sulki heti pois suurin osa kentistä.

Myös seuraavista vihjeistä oli apua, What information send to the application gets reflected back after being submitted? ja Just try purchasing something. You want your script to be included in the purchase-confirmation.

Testaan mitä tietoja lomake antaa kun painaa purchase:

Tästä nähdään, että sopiva kenttä XSS:lle on luottokorttinumeron kenttä. Samalla saadaan tietoa, että halutaan vastaukseksi saada jotain JavaScript koodia kyseiseen kenttään. Tehtävänannossa ehdotetaan alert() tai console.log() metodeja.

Tehtävä onnistui, mutta en tiedä oliko tähän tarkoitus syöttää jotain monimutkaisempaa koodia… Myös console.log() antaa samanlaisen vastauksen.

10 Identify potential for DOM-Based XSS

Tutkin sivun JavaScript koodia ja löydän lupaavan GoatRouter.js tiedoston.

Teen haun tiedoston sisällössä:

Tästä voisi päätellä, että jos nykyisen sivun URL on http://localhost:8080/WebGoat/start.mvc#lesson/CrossSiteScripting.lesson/9 olisi mahdollista vaihtaa sana lesson sanaksi test.