Overblog
Suivre ce blog Administration + Créer mon blog
26 mars 2015 4 26 /03 /mars /2015 12:05

Vu il y a quelques minutes, dans un dérivé de Chrome avec le module KB SSL Enforcer :

La Fnac utilise un site (tiers) de paiement peu sécurisé

Voici le rapport de scan du site par SSLlabs :

https://www.ssllabs.com/ssltest/analyze.html?d=secure.ogone.com

 

Il y a quand même 2 ou 3 choses surprenantes pour un site de paiment en ligne :

- accepter TLS 1.0 alors qu'il est vulnérable (et aussi TLS 1.1)

- accepter des suites de chiffrement vulnérables comme TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA 

- être vulnérable à certaines attaques connues : 

Secure Client-Initiated Renegotiation Supported   DoS DANGER (more info)

 

Bref... cela ne donne pas vraiment envie de faire confiance, pourtant sans ça, on ne peut payer en ligne sur le site de la Fnac !

Prudence donc...

Partager cet article

Repost0
16 octobre 2014 4 16 /10 /octobre /2014 11:06

Comodo Dragon is somewhat a derived from Chromium, the open-source project behind Google Chromium, adding some features and "more security".

So far, I was quite happy with it.

 

Today, I saw this message while opening my GMail account:

 

Comodo Dragon and Gmail

[in English: This version of Chrome browser is no longer compatible"

Gasp... what? Chromium not compatible anymore with GMail? sounds like a paradox...!

Then I double checked: Chromium versions available, Comodo installed version, and bingo:

Comodo Dragon and Gmail

It seems that guys at Comodo are late to publish newer versions of Comodo Dragon: Chromium is now v40, while Dragon sticks with version 33...

Guys... we need you!

Otherwise, as for every obsolete product, I would have to switch to another browser, and recommend everyone that reads my blog to do the same.... :(

Partager cet article

Repost0
9 octobre 2014 4 09 /10 /octobre /2014 15:32

Note here, this is the paid version of MalwareBytes, yes full/genuine license, therefore realtime protection can be enabled.

While trying to download a Linux distrib, Austrumi, here is the warning that appeared:

AV False positives, part 2 - MalwareBytes

Interesting... "malicious website blocked", for non-French speaking guys.

Okay, let's check!

VirusTotal says 0 engine, as of today, detect it as malicious!

https://www.virustotal.com/en/url/c3e6125fff7e0861083c470fefb46013b0934659843164bfbb484fe8c8d68a81/analysis/1412861752/

Sucuri did not report anything malicious either:

http://sitecheck.sucuri.net/results/austrumi.ru.lv

Linux distro being considered as malicious stuff, poor guys at Austrumi!

HTH...

Partager cet article

Repost0
28 juillet 2014 1 28 /07 /juillet /2014 22:40

Voici un commentaire récent, reçu sur un de mes articles :

Le spam via les commentaires d'article de blog

Et je ne suis visiblement pas le seul à être concerné...

Le spam via les commentaires d'article de blog

Pourtant le site nyt30ud0.com n'existe même pas...incroyable !

Les polluposteurs ne sont même plus un minimum compétents de nos jours :(

A bon entendeur... à vos listes noires !

Partager cet article

Repost0
27 juillet 2014 7 27 /07 /juillet /2014 21:57

According to Webroot SecureAnywhere, cloud-based antimalware, Easy Drive Data Recovery is malicious:

 

AV False positives, part 1 - SecureAnywhere

According to VirusTotal, this file is not malware:

https://www.virustotal.com/en/file/74ab0b9068ef46db6f3acb04c17963fa8e99f23ee0d603559faca4fd720c1c8f/analysis/1406491025/

If you scan whole disk drives without confirming action for every file that gets detected, you may get in trouble... at least, I would recommend to choose "quarantine" as default action.

AV False positives, part 1 - SecureAnywhere

-----------------------------------------------------------------------------------------------------

Now, according to SecureAnywhere, Portable LibreOffice (Framakey version) also contains malware:

AV False positives, part 1 - SecureAnywhere

Well, according to VirusTotal, those files are not really malicious...

  • passwordcontainer.uno.dll is in fact packed, 2 detections out of 53

https://www.virustotal.com/en/file/4ae9daed6ef23e760df5fa9624671311be148c3c9c3fc46d0950180e090385dc/analysis/1406491597/

AV False positives, part 1 - SecureAnywhere
AV False positives, part 1 - SecureAnywhere
AV False positives, part 1 - SecureAnywhere
AV False positives, part 1 - SecureAnywhere

All of those results were with a (quite) old version of Portable LibreOffice, pas per the file properties:

AV False positives, part 1 - SecureAnywhere

Now, here is what SecureAnywhere says regarding the latest available version of Portable LibreOffice (from here: http://framakey.org/Portables/LibreOfficePortable): still 2 detections!

AV False positives, part 1 - SecureAnywhere

According to VT,

  • wininst-6.0.exe: 5 detections

File is UPX packed...

AV False positives, part 1 - SecureAnywhere
  • python.exe: same as before, 3 detections on VT.

File is UPX packed..

Partager cet article

Repost0
11 avril 2014 5 11 /04 /avril /2014 12:30

Cela pourra certainement être utile à d'autres, soit au niveau administration soit au niveau recherche inforensique... :)

Besoin :

  • extraire depuis un fichier journal de sécurité (format EVT ou EVTX), les événements ayant un numéro particulier (ici, un numéro d'événement lié à un refus d'ouverture de session, sous 2003 : le 675)
  • trier sur un champ dans la zone de message de l'évènement (Ici : adresse IP de la machine cliente ayant déclenché l'événement, donc la ligne commençant par "Client Address")
  • sortir un top 10 des plus mauvais élèves.

 

2 étapes :

  1. convertir au format XML pour pouvoir travailler dessus
  2. faire l'extraction sur le numéro d'évènement, puis le tri par IP et comptage 

 

Voici donc les commandes :

  • D'abord, vers du XML :

Get-WinEvent -Path C:\temp\security.evt -Oldest |Export-Clixml seclog

avec security.evt étant le fichier journal extrait de la machine qui fait l'objet de la vérification... (ou investigation).

  • Puis on charge le XML en mémoire, avec une variable:

$seclog = Import-Clixml c:\temp\seclog.xml

 

  • Et on fait le travail d'extraction et de tri, sur l'événement numéro 675 (mais qui est donc modifiable à volonté) :

PS C:\temp> $seclog | ? { $_.id -match '675' } | fl Message | findstr /i /c:"Client Address" | gro up |Sort-Object -Descending count |Select-Object -first 10

 

Et viola :

Count  Name         Group

-----      ----               -----

5496    Client ... {    Client Address: 10.X.Y.Z, 3406 Client ... { Client Address: 10.X.Y.Z,

2858    Client ... {    Client Address: 10.X.Y.Z, 2016 Client ... { Client Address: 10.X.Y.Z,

2003    Client ... {    Client Address: 10.X.Y.Z, 1677 Client ... { Client Address: 10.X.Y.Z,

1572    Client ... {    Client Address: 10.X.Y.Z, 1541 Client ... { Client Address: 10.XY.Z,

1512    Client ... {    Client Address: 10.X.Y.Z, 1307 Client ... { Client Address: 10.X.Y.Z,

(les X.Y.Z étant bien sûr des remplacements des valeurs réelles des IP dans la vraie vie :) )

Plus de 700 Mo de fichier XML traités en moins de 2min... cela me semble acceptable.

 

Je tiens à remercier mon collègue Cyrille pour son aide sur la partie formatage de sortie avec fl.

 

 

 

 

 

Partager cet article

Repost0
18 mars 2014 2 18 /03 /mars /2014 00:29

Tout commence avec un outil assez connu : Advanced Task Manager. La plateforme est un Android 4, Galaxy SII.

Etant "gratuit mais financé par la pub", il affiche des bannières publicitaires en bas de l'écran lors de l'utilisation.

Et un jour, la bannière suivante apparâit :

WP_20140310_026.jpg

 

Alors, évidemment, un utilisateur non averti peut appuyer sur la bannière. Et voici alors ce qu'il se passe : Le navigateur s'ouvre et...

WP_20140310_008-copie-1.jpg

 

(Le téléphone est protégé par 1 antivirus temps réel, plus 1 autre à la demande, et des mises à jour régulières...)

L'avertissement ressemble de plus en plus au coup classique du faux antivirus sous Windows (ou Mac !!), qui crie partout "attention vous êtes o=infecté", cliquez ici pour réparer !".

On aura noté la traduction hasardeuse... encore une fois certains ne savent toujours pas parler Français :(

A date, aucun logiciel de sécurité pour mobile ne bloquait l'URL droid-safety.com (d'après mes tests).

Cliquons donc sur OK.

WP_20140310_013.jpg

Hmmm un scan antivirus ?

WP_20140310_014.jpg

 

Et bam, le résultat... (NB : il s'agit d'une rediction "forcée" dans le navigateur, qu'on ne peut pas annuler malgré mes tentatives).

WP_20140310_020.jpg

 

Haha de plus en plus conforme aux "rogue" antivirus, comme dit l'anglicisme.

Mais l'écran suivant est encore mieux :

WP_20140310_023.jpg

Ca y est ! je suis infecté !! :)

WP_20140310_006.jpg

 

Et si je veux suivre les conseils et désinfecter ?

WP_20140310_002.jpg

Zoom sur l'URL de la bannière de l'"antivirus" :

WP_20140310_005.jpg

 

(wap.fumblo.com)


Le tout pointe en fait sur un système de facturation mensuelle, qui s'ajoute à la facture mobile (ici SFR). 

L'URL est sur le domaine : im-echopass.hcnx.eu.

D'après mes tests, aucun logiciel de sécurité pour mobile ne bloque cette URL en date du 11/03.

WP_20140310_024.jpg

 

Moralité : non, l'antivirus sur mobile n'est pas de la science fiction, mais un réel besoin !

Partager cet article

Repost0
18 janvier 2014 6 18 /01 /janvier /2014 15:36

La lutte contre la fuite d'information n'est pas quelque chose de simple. De nombreuses solutions existent, certaines gratuites et bien connues.

L'idée ici est de faciliter le travail des admins ou ingénieurs sécurité dans leur surveillance du traffic réseau, dans le cadre de cette lutte contre la fuite d'info. Pour le cas présent, il sera question de DropBox.

Il faudra bien évidemment ensuite déterminer si l'usage de l'outil est légitime ou non.

Voici donc des requêtes caractéritisques de la connexion à un espace Dropbox, que vous verrez par exemple sur un proxy type Squid3 :

en HTTPS :

CONNECT client51.dropbox.com:443 

CONNECT client88.dropbox.com:443

Apparemment le nombre après "client" change dans le temps, sans que ce soit itératif, et varierait entre 10 et 99.

Mais aussi :

CONNECT d.dropbox.com:443

CONNECT client-lb.dropbox.com:443

CONNECT www.dropbox.com:443

CONNECT dl-client977.dropbox.com:443

CONNECT dl-debug18.dropbox.com:443

 

- en HTTP :

Nombreuses requêtes de type  GET http://notify7.dropbox.com/subscribe? 

 

Comme tout outil de ce type, rappelons que Dropbox peut faire le pont entre machine pro (à l'intérieur de l'entreprise), machine perso (à la maison), machine presta (en vadrouille), etc.

Bonne surveillance :)

Partager cet article

Repost0
10 janvier 2014 5 10 /01 /janvier /2014 01:46

Oui, le titre peut faire hausser les sourcils, c'est un peu le but.

Cherchant des articles que le fameux Ivanlef0u avait écrit, je suis passé sur ce qui avait été un de ses sites officiels : http://ivanlef0u.fr/

Le lien ivanlef0u.fr venant du site tuxfamily :

ivanlef0u.tuxfamily.org_100114.JPG

 

Sauf que dès l'accès à la page d'accueil, hop, surcouche forcée qui apparaît et me dit "qu'il faut Flash pour pouvoir visualiser la page". Hmmm cela sent un peu le VX heu roussi.

ivanlef0u_Flash_avertissement_100114-copie-1.PNG

 

La passion me pique. Je clique !

Bon alors déjà, mes protections AV ne disent rien (sic, je taira la liste...). Essayons plus fort : VT. Bilan : 0 pointé !!

https://www.virustotal.com/en/file/52ceb98a4f035fba3163a7e5d96fd7d095bd374ceaecb7cc60ae707ed0179f0b/analysis/1389314203/

VT_flashplayer_100114.PNG

 

En gros, seuls ClamAV remonte une "PUA" et Symantec un "Suspicious.Insight". Pas brillant.

 

Etape suivante : analyse dynamique. Allez, prenons malwr.com avec du Cuckoobox. Là, c'est déjà mieux !

https://malwr.com/analysis/NTI4M2E3ZjczMzUyNGNkNWI2OWVmOWE0ZTZmMDU3Nzk/

 

Vieux réflexe, je passe assez vite à la partie comportement réseau. Intéressant !

malwr.com_flahsplayer_domaines_100114.PNG

- accès à 

http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootseq.txt

waou, le code malin télécharge la mise à jour du magasin des autorités racines et intermédiaires, de la PKI Windows... alors que bon nombre d'entités ne le font pas ! (bonjour les impacts sur toutes les fonctions de crypto, mais c'est un autre chapitre).

Soit. On a bien vu des codes télécharger des Service Packs...

- accès à

 http://skydrive.live.com/download.aspx?cid=a688a826ff19b912&resid=A688A826FF19B912%21114  

qui en fait redirige sur w9kz0w.bn1303.livefilestore.com

(NB : petit bogue pour malwr.com : ce domaine apparaît bien dans la liste des domaines, mais pas dans les détails des requêtes HTTP...)

malwr.com_flahsplayer_HTTP_100114.JPG

Bingo ! (et une détection par mes propres outils, ouf :) )

Le test VT montre que l'échantillon n'a jamais été envoyé encore... très frais potentiellement. https://www.virustotal.com/en/file/9eb462a7d77437969d5b26172e00ea87005169337146014b189b63878a3aae81/analysis/ 

4 moteurs détectent (+ Clam PUA, et Symantec Reputation) :

VT_flashplayer2_100114-copie-1.PNG

 

Ohhhh du AutoIT ! cela faisait un bail, et encore plus, appliqué au monde VX !

 

Maintenant, pour revenir au site lui-même, le code source de la page est assez parlant :

ivanlef0u.fr_source_.JPG100114.JPG

 

En jouant un peu avec la logique de script pour l'URL qui propose le fichier, il ne semble pas qu'il y ait un certain dynamisme.

Voici l'URL d'où vient le fichier EXE :

https://w9norw.bn1303.livefilestore. com/y2muoADUmAic2ch-kWgo6AGHtYhSLMe0sq_gwBirHjXqoGrdQSIgx2li2ulOliNBuhd9wqV-QDaDqkJZO1ecTue3-I8tkma6wzsPW5myco_JCU/flashplayer.exe?download&psid=1

Et donc oui, c'est du HTTPS... en d'autres termes, sans décontamination au niveau du proxy périmétrique (même le NIDS ne devrait pas voir grand chose ici), le niveau de sécurité sera celui du poste/serveur au bout de la ligne...

 

Autre chose, la façon dont est codé l'ensemble JavaScript ici semble aussi avoir pour but de complexifier les analyses statiques de code (ie: sans interpréter le JavaScript, qui reconstruit ici l'URL en dynamique), ceci pouvant se faire avec par ex un Lynx ou un wget, et un proxy (squid).

Voici donc l'erreur qui apparaît dans un Squid3, quand on tente d'accéder à une des URL de "téléchargement", depuis un Lynx:

squid_showofftravelbags.com_error_100114.JPG

 

Je crois bien qu'il y a eu un souci quelque part... mais le "flashplayer" reste pour moi un cas d'école intéressant (je ne publierai pas tout ici, pour diverses raisons).

Un petit coup d'oeil aux requêtes HTTP du coup ?

trafic_showofftravelbags.com_headers_100114.JPG

 

Une configuration apparemment bien sécurisée sur c.statcounter.com avec Apache 2.2.3 (obolète ?) / PHP 5.2.17 (obsolète/vulnérable), pourrait être un des points clés de l'histoire.

Au passage et dernier point, c'est le site http://www.showoffstravelbags.com/images/imgfiles/b.html qui (héberge) est la page HTML "DOWNLOAD NOW" en surcouche, y est hébergée...

D'après webinspector, tout va bien... :(

webinspector_showofftravelbags.com_100114.JPG

MàJ 1 : correction de faute de frappe, merci Estelle :)

Partager cet article

Repost0
19 octobre 2013 6 19 /10 /octobre /2013 16:16

J'ai eu récemment un réel souci sur une machine perso : les navigateurs n'arrivaient plus à accéder au contenu Internet... alors que le ping marchait. Détails ci-dessous.

Machine (contexte perso) : Windows 7 SP1, tous correctifs, KAV 2014. Rappelons que que Windows Vista et ultérieurs, en 64 bits, ont des vérifications renforcées des pilotes (validité des certificats de signature).

NB : je n'avais pas installé l'outil EMET (durcissement sécurité)

 

Tout commence par un problème simple : ni Internet Explorer, ni Chrome n'arrivent à accéder à Internet ! subitement, sans prévenir...

HTTP_HS_KAV_181013.PNG

 

Pareil en HTTPS :

HTTPS_HS_KAV_181013.PNG

 

Pourtant, le ping (ICMP), marche, et comme j'ai demandé un FQDN, la résolution DNS aussi !

ping_OK_181013.PNG

Strange,  non ?

Il pourrait donc y avoir un souci dans la couche HTTP, notamment WinHTTP...

Il se trouve également que KAV a injecté dans chaque navigateur (IE/Chrome) des modules additionnels de contrôle de la navigation... A garder en tête pour la suite.

Le problème est tel que même la mise à jour de Chrome ne marche plus !

Chrome_MaJ_HS_181013.PNG

NB: oui la machine est connectée sur un routeur ADSL... et ICMP marche :(

 

KAV montre de son côté des symptômes de fatigue... l'ouverture de l'interface graphique via l'icône en barre de notification Windows, pédale dans la semoule...

 

gel_KAV_181013.PNG

La barre verte ne s'arrête jamais... Cela met la puce à l'oreille !

 

En cherchant bien, une fenêtre Windows (qui n'avait pas gardé le focus) indique un message d'alerte sécurité pour KAV :

confiance_kav_181013.PNG

 

Là, clairement, il y a un loup. Un tel message ne devrait pas apparaître !

Ici, impossible de s'en sortir sans redémarrer la machine : KAV ne s'ouvre pas, et même en "acceptant de faire confiance à l'éditeur" plusieurs fois, rien ne se débloque.

Redémarrons donc... :|

 

Au redémarrage, certains points s'éclaircissent :

KAV_obsolete_reboot_181013.PNG

 

Hmmm donc effectivement, il y a bien eu un dysfonctionnement car KAV devrait être parfaitement à jour vu que la machine était restée connectée à Internet pendant plusieurs heures, avant l'incident en question !

Je suspecte que l'alerte "faites-vous confiance à cet éditeur" ait bloqué des composants Internet à KAV, notamment la mise à jour et la surveillance du traffic HTTP des navigateurs, ceci donc impactant ma navigation par effet de bord !

 

Voici maintenant une petite vérification via l'utilitaire SigCheck de SysInternals (téléchargeable depuis la TechNet) :

sigcheck_sgantures_files_KAV_181013.PNG

 

Certains champs des certificats semblent vides...

J'espère que ce problème n'impactera pas une trop grande population. Je répète la solution : redémarrer et vous assurer que vous avez validé le message "faites-vous confiance à cet éditeur ?".

 

Mise à jour 1 :

Vérification supplémentaire avec SignTool, outil disponible dans le SDK de Windows :

signtool_kav_KO_19013.PNG

Bingo...

 

A bon entendeur...

PS : un article de KB à lire, pour tout admin ou personne impliquée dans la sécurité : http://technet.microsoft.com/en-us/library/cc733026.aspx#BKMK_Code_Local 

Attention à ce type de paramètres assez méconnus de la PKI standard de Windows (indépendante de la PKI propre à l'entité !)

 

Mise à jour 2 :

Ca continue !

kav_maj_err_151113.PNG

Les impacts sont assez pénibles : accès réseau totalement gelé, lenteurs système, et Windows donc qui alerte régulièrement sur KAV qui n'est pas à jour... 

Et au passage, quand je regarde de plus près le certificat, je vois qu'il utilise SHA1...!

kav_sha1_151113.PNG

 

Or SHA1 n'est plus un algo de condensat encore considéré comme fiable... Surprenant de le voir ici (sauf peut-être, pour des contraintes de perfs ?)

 

En fait, le problème n'est pas là, mais quelques crans plus haut !!

Voici le certificat de l'autorité racine de confiance :

KAV_TrustCA_md5_181113.PNG

 

Il apparaît que l'algo de hachage est ici le MD5.

Or Microsoft a publié récemment une mise à jour (2862966) qui, dans le cadre de la défense en profondeur, fait que la CryptoAPI refuse maintenant le MD5 pour les certificats !

Et évidemment, la mise à jour en question est bien installée sur la machine...

http://blogs.technet.com/b/askds/archive/2013/08/14/md5-signature-hash-deprecation-and-your-infrastructure.aspx

Il serait donc temps que GTE CyberTrust Global Root mette à jour ses certificats ! Ou que Kaspersky, d'ici là, se fasse signer ses fichiers par une autre autorité racine de confiance.

CQFD...?

 

Partager cet article

Repost0