Juste des hashs

kevin@slackware:~$ vi doc.txt
reading doc.txt

wrote doc.txt, 190 lines, 8175 chars
kevin@slackware:~$ md5sum doc.txt
7c57b61f9f99c541ea8c17f1f4b8ded4  doc.txt
kevin@slackware:~$ sha1sum doc.txt
2035d6d4e944f8716e85d688057dde5e7cc7c32f  doc.txt
kevin@slackware:~$

Browserquest de mozilla, c'est quand meme plus simple que le SSTIC

Afin de promouvoir la norme HTML5, mozilla a publié un jeu n'utilisant que cette technologie : browserquest.
Le jeu ressemble à Zelda, et plusieurs références très geeks émaillent le jeu (Nyan cat, Portal, Star wars, Le seigneur des anneaux, Mario bros, Rickroll, etc..).

Le principe du jeu est simple, vous démarrez simple joueur avec une petite épée et au fur et à mesure de la progression, des armes plus puissantes peuvent être utilisées. Un mécanisme d'"achievement" est présent, vous récompensant de différentes réussites (se faire rickroller, tuer 50 ennemis, etc..). Je n'ai pas joué fort longtemps, mais la carte à l'air assez grande. Le problème dans ce genre de jeu, c'est que l'on commence assez faible et que le moindre ennemi vous achève en un tour de jeu ce qui est vite assez frustrant.

Dans le temps, les joueurs tentaient souvent de modifier les sauvegardes pour s'arroger des vies supplémentaires. Nous avons lu que le jeu autosauve les caractéristiques du joueur (HTML5 et Localstorage).
Créons un joueur appelé Palladin (oui, je fais original):

Fermons l'onglet du navigateur. Si je rouvre le navigateur on me propose bien de nouveau ce personnage:

Il est donc enregistré quelque part.

$ grep -rl Palladin .mozilla/firefox/
.mozilla/firefox/70willuz.default/webappsstore.sqlite

Les données semblent être enregistrées dans cette base sqlite3.

$ sqlite3 webappsstore.sqlite
SQLite version 3.7.5
Enter ".help" for instructions
Enter SQL statements terminated with a ";"
sqlite> .table
webappsstore2
sqlite> .schema webappsstore2
CREATE TABLE webappsstore2 (scope TEXT, key TEXT, value TEXT, secure INTEGER, owner TEXT);
CREATE UNIQUE INDEX scope_key_index ON webappsstore2(scope, key);
sqlite> select scope from webappsstore2;
 (...)
gro.allizom.tseuqresworb.:http:80
sqlite> 

L'utilisateur averti comprend vite que le domaine se lit à l'envers, on lit bien browserquest.mozilla.org

sqlite> select value from webappsstore2 where scope='gro.allizom.tseuqresworb.:http:80';
{"hasAlreadyPlayed":true,"player":{"name":"Palladin","weapon":"sword1","armor":"clotharmor","image":"data:image/png;base64,iVBO (...) gg=="},"achievements":{"unlocked":[4],"ratCount":1,"skeletonCount":0,"totalKills":1,"totalDmg":24,"totalRevives":0}}

Rien n'est obfusqué (j'ai juste réduite le base64 de l'image png), il est donc temps d'aller chercher le code source du jeu pour connaitre la liste des armes disponibles. On se doute bien que weapon et armor sont à modifier, et que le "unlocked" d'achievements est une simple liste.

Le fichier shared/js/gametype.js donne toutes les infos nécessaires.

Types.rankedWeapons = [
    Types.Entities.SWORD1,
    Types.Entities.SWORD2,
    Types.Entities.AXE,
    Types.Entities.MORNINGSTAR,
    Types.Entities.BLUESWORD,
    Types.Entities.REDSWORD,
    Types.Entities.GOLDENSWORD
];

Types.rankedArmors = [
    Types.Entities.CLOTHARMOR,
    Types.Entities.LEATHERARMOR,
    Types.Entities.MAILARMOR,
    Types.Entities.PLATEARMOR,
    Types.Entities.REDARMOR,
    Types.Entities.GOLDENARMOR
];

Donc goldensword et goldenarmor semblent être des options intéressantes :-)

La deuxième variable concerne les achievments, et l'on va tous se les arroger. Une requête sqlite unique permet de modifier tout cela:

$ sqlite3 webappsstore.sqlite
sqlite> update webappsstore2 set value='{"hasAlreadyPlayed":true,"player":{"name":"Palladin","weapon":"goldensword","armor":"goldenarmor","image":"data:image/png;base64,iVB (...) gg=="},"achievements":{"unlocked":[4,1,2,3,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20],"ratCount":0,"skeletonCount":0,"totalKills":0,"totalDmg":0,"totalRevives":0}}' where scope='gro.allizom.tseuqresworb.:http:80';

Et on relance le jeu. Le palladin a changé d'apparence et de puissance:

Tout de suite, ça fait sérieux.

Et pour les achievements:

Win \o/ 

Vous pouvez courir plein nord pour aller défaire le boss.

C'est d'une simplicité désarmante au contraire du SSTIC où je semble être coincé sur une webcam USB qui ne veut rien me dire :-/

EDIT (06avril) : Sous Google Chrome, le fichier sqlite est enregistré sous:
~/.config/google-chrome/Default/Local Storage. Le fichier n'est pas suffixé en sqlite, et se nomme http_browserquest.mozilla.org_0.localstorage.
La table ne contient qu'une seule ligne et vous pouvez l'updater de la même manière:
update ItemTable set value='{"hasAlreadyPlayed (...) ' where value like 'has';

Il y a un an, RSA était victime d'un APT. Etat des lieux.

Il y a un an, la compagnie RSA annonçait qu'une partie de son infrastructure était sous le contrôle d'attaquants via une attaque de type APT (Advanced Persistent Threat). Le post de blog très technique de RSA (voir la 2e partie du message "anatomy of an attack") indiquait un spear phishing  associé à un 0day, puis un RAT qui a permis à un attaquant de se déplacer latéralement dans le réseau extrêmement rapidement avant d'exfiltrer les données. L'attaque a été rapide car RSA avait détecté la brèche, mais n'a malgré tout pas pu éviter le vol de données.

La compagnie command five a produit un rapport sur les canaux de communication utilisés par des APT d'un groupe de pirate qui utilise les mêmes systèmes et serveurs de commandes et contrôles. Parmi les compagnies citées nous retrouvons RSA. Le rapport confirme effectivement le post de blog à quelques détails près (apparemment le RAT pour RSA n'était pas poison ivy, mais murcy). Ce rapport permet d'éclairer certains points très intéressants sur le mode de fonctionnement et sur la détection des APT.

1/ L'installation du RAT
Rien de bien nouveau, nous retrouvons dans les cas exposés un RAT qui s'installe via du spear phishing et éventuellement un certificat valide volé dans certain cas. Les RAT n'ont rien de spécialement avancé puisque ce sont des outils que l'on trouve sur internet, certains d'entre eux existant en version commerciale (!) : X-shell par exemple ou Poison Ivy.

2/ Le contrôle des machines
Pour contrôler les machines, les ports et protocoles classiques sont utilisés: DNS puis du HTTP ou HTTPs. Les machines se connectent régulièrement sur les serveurs C&C et envoient de l'information.
Rien de très avancé non plus, depuis les réseaux RFC1918 il est plus simple à une machine d'un LAN de se connecter sur une machine à IP publique que l'inverse.

Certains noms de domaine sont choisis pour ressembler à des domaines connus, comme
*.windowupdate.com (il manque le 's' à windows) ou *.alyac.org (alyac est un outil de sécurité) afin de leurrer l'oeil non exercé d'un administrateur vérifiant ses logs.

Les protocoles sont basés sur du HTTP, c'est du GET ou du POST normal avec des données, ce qui signifie qu'un firewall ou un proxy applicatif laissera passer ces données.

3/ Comportement et détection de ces RAT
Commençons par le mauvais côté, celui ou il est difficile de se défendre.

• Révocation de certificats: Comme l'indique le rapport, certains certificats n'ont pas été révoqués pour ne pas pénaliser l'usage d'outils légitimes étant signés par celui-ci (!)
• Analyse antivirale: Bien qu'utilisant un nombre réduit de RAT, les attaquants n'hésitent pas à les recompiler, cela ayant comme effet de bord de rendre toute détection antivirale basée sur un hash du binaire inefficace (l'auteur du rapport conseille de faire un hash de certaines parties, le .rdata .text etc.. car elles sont souvent identiques).

Le bon côté c'est qu'il existe des moyens de détecter ces APT en raison de leur comportement. Ils existe deux types de défense à ces APT, tout d'abord celles qui existent déjà et dont les entreprises sont coupables de ne pas les avoir mises en oeuvre, et les défenses qui n'existent pas encore mais qui devraient être développées.

Défenses possibles:

• Les RAT appellent fréquemment leur serveur de C&C. Dans certains cas, le RAT appelle son C&C toutes les 8 seconds, ce qui représente +10000 appels par jour. Ce volume de connexions devrait être immédiatement détecté comme suspect et analysé.
• Certains RAT n'utilisent pas les DNS locaux, mais au contraire des serveurs DNS sur internet. Une politique de sécurité sur le firewall devrait empêcher ces résolutions d'être faites et alerter l'administrateur.
• Les auteurs de l'attaque continuent à utiliser des noms de domaines pour leurs C&C, même une fois que ces domaines sont blacklistés dans diverses listes. Bloquer ces listes apparaît donc comme un premier pas essentiel, mais surveiller les machines tentant de s'y connecter permet d'augmenter les chances de détection de malware.

 Défenses à créer:

• Les RAT appellent leur serveur de C&C à fréquence fixe, c'est à dire à intervalle régulier. Existe-t'il au monde une sonde IDPS qui sait indiquer les connexions régulières? Ce serait un des meilleurs moyens je pense de trouver des flux malveillants[1].
• Pour contourner les systèmes de blacklist DNS, certains RAT utilisent directement les IP pour joindre leur C&C. Existe t'il un mécanisme de suivi de connexion qui soit capable d'indiquer si une connexion vers une IP a été précédée d'une requête DNS? Cela serait également un mécanisme de surveillance efficace.

4/ Conclusion
EDIT: Pour résumer, nous pouvons considérer que l'entrée d'un attaquant dans un réseau est difficile à bloquer: spear phishing évolué, 0day (et inefficacité des certificats). Par contre, l'auteur de l'APT va chercher par la suite à se déplacer latéralement dans le réseau visé. C'est sans doute là qu'il est le plus vulnérable, du fait de ses fréquents allers-retours entre le C&C et les machins vulnérables.
Nous verrons peut-être un jour des malwares se déplacer à la manière de drone absolu sans aucun contact avec l'extérieur si ce n'est l'exfiltration des données finale. Ceux-là seront particulièrement difficile à bloquer. Mais un malware pourra t'il embarquer suffisamment d'intelligence?

[1] C'est d'ailleurs un problème mathématique amusant: Soit une distribution de noms associés à leur heure de résolution ['nom',heure]. Comment détecter dans cette distribution des évènements répétitifs?