Auditointi yleisesti

Salaustoteutusten etsiminen

Sovelluksia auditoitaessa salauksen käytöstä pitäisi saada tieto tuotteiden ja järjestelmän dokumentaatiosta, mitä voidaan täydentää haastattelemalla toimittajia. On hyvä kuitenkin aina tarkistaa tietojen paikkaansapitävyys etsimällä merkkejä dokumentoimasta salauskirjastojen käytöstä tai salausavaimista. Se on helppoa muutamalla yksinkertaisella komennolla.

OpenSSL-kirjasto

OpenSSL on todennäköisesti, puutteistaan huolimatta, kaikkein käytetyin salauskirjasto. *NIX-alustoilla voidaan etsiä kaikki C/C++ -sovellukset, jotka ovat dynaamisesti linkitetty OpenSSL-kirjastoa vastaan. Esimerkkikomentoon on lisätty libcrypto ja libtls, jotta se löytäisi myös LibreSSL:n (OpenBSD-kehittäjien edelleenkehittämä versio).

find / -xdev -type f -perm /a+x  -print0 |
while read -d $'\0' FILE; do
 ldd "$FILE" | grep -q -E 'libssl|libcrypto|libtls' && echo "$FILE"
done

Vastaava tekniikka toimii myös staattisesti linkitettyjen sovelluksien kanssa, jos niistä ei ole poistettu aivan kaikkia symboleja. Tämä perustuu siihen, että funktioiden nimet säilyvät sovelluksen linkitystaulukossa. Useat OpenSSL:n alustusfunktiot alkavat nimeltään sanalla OPENSSL. Lisäksi esimerkkikomentoon on lisätty LibreSSL:n funktioiden yleisimpiä nimiä.

find / -xdev -type f -perm /a+x  -print0 |
while read -d $'\0' FILE; do
 objdump -x "$FILE"| grep -q -E 'tls_init|ssl_init|CRYPTO|OPENSSL' && echo "$FILE"
done

Java

Käännetyissä Java-luokissa on tallennettuna tieto kirjastoista käytetyistä luokista. Jos luokkaa ei ole käytetty tiedostossa, siitä ei ole tietoa vaikka import-komentoa olisikin käytetty. Suurin osa Java-sovelluksista käyttää vakiona mukana tulevia kirjastoja, mutta myös Bouncy Castlea käytetään jossain määrin.

JRE:n mukana tulee jdeps-työkalu, joka osaa purkaa Jar-tiedostot ja selvittää niiden tarvitsemat kirjastot rekursiivisesti.

find /opt -xdev -type f -name *.jar -print0 |
while read -d $'\0' FILE; do
 jdeps "$FILE"| grep -q -E 'java.security|javax.crypto|bouncycastle' && echo "$FILE"
done

Varmenteet ja avaimet

Salauskirjastojen käytön lisäksi kannattaa etsiä merkkejä salausavaimista ja varmenteista. Hyvin käyttäytyvät sovellukset käyttävät käyttöjärjestelmän vakiona tarjoamia sijainteja (esim. /etc/ssl/), joiden käyttöoikeuksia on kovennettu (ACL:t, SELinux-tyypit). Moni sovellus kuitenkin tekee omia säilöjä, joista on hyvä olla vähintäänkin tietoinen.

find -L / -xdev -type f -print0 |
while read -d $'\0' FILE; do
 file "$FILE"| grep -q -i -E 'certificate|(public|private|symmetric|secret|GPG)-?.?key|key(chain|ring|store|tab|.?pair)|LUKS|x509|mcrypt|RSA|DSA|ECDSA|ElGamal|Diffie-Hellman|Elliptic' && file "$FILE"
done

Esimerkkikomento tuottaa paljon vääriä hälytyksiä, koska sen hakutermeissä ovat mukana sanat RSA ja DSA. Merkkiyhdistelmät toistuvat yllättävän usein tiedostojen nimissä, mistä syystä kannattaa harkita niiden sisällyttämistä hakuun.

Edellinen komento löytää yleisimmin käytetyt varmennesäilöt, kuten Java Key Store (*.jks). Jotkin valmistajat ovat kuitenkin (jatko-)kehittäneet omia varmennesäilöjä, joiden löytäminen vaatii käytännössä ennakkotietoa niiden olemassa olosta. Esimerkiksi IBM on kehittänyt RFC-3852 (Cryptographic Message Syntax) pohjalta omia tiedostomuotojaan.

Windows-alustat

Windows-alustalla hyvin käyttäytyvät sovellukset hyödyntävät Microsoftin Certificate Store -järjestelmää. Sovelluskehittäjien on jälleen mahdollista käyttää 3. osapuolten kirjastoja ja tallentaa varmenteita ympäri järjestelmää.

certutil

https://stackoverflow.com/questions/1993673/what-is-the-equivalent-of-linuxs-ldd-on-windows

Screenshotit

CVE:t

Avainten hallinta

CA-politiikan audit

Default-storet

https://www-01.ibm.com/software/webservers/httpservers/doc/v1312/ibm/9atikeyu.htm#HDRKMUOKDG