Overblog
Suivre ce blog Administration + Créer mon blog
19 septembre 2009 6 19 /09 /septembre /2009 01:20
Noticing the fact that APT upgrades were becoming slower for a while, I started to investigate further.

After checking all the configuration files of APT and its logs, it became clear that the problem was not on the hosts that used the APT-proxy running on the server.

It looked like a Dos, or time out, or an APT resource. But it was not.

Unfortunately, the APT-proxy logs are not so verbose, but... considering the fact that a service has a special procedure to be stoped and started, the old reflex to reload the service and its configuration was helpful.


In fact, APT-proxy was just yelling during its start.
Here is what I got:

Starting apt-proxy:/usr/lib/python2.5/site-packages/twisted/manhole/telnet.py:8: DeprecationWarning: As of Twisted 2.1, twisted.protocols.telnet is deprecated.  See twisted.conch.telnet for the current, supported API.
  from twisted.protocols import telnet
None
/usr/lib/python2.5/site-packages/twisted/manhole/telnet.py:8: DeprecationWarning: As of Twisted 2.1, twisted.protocols.telnet is deprecated.  See twisted.conch.telnet for the current, supported API.
  from twisted.protocols import telnet
None

.

Thus, it appears that the real problem comes from Python, and more especially from one of its library: twisted.protocols.telnet

Obvisously, it was not possible to uninstall and reinstall Python, because of its numerus dependances.

I tried Google...
http://www.google.fr/search?rlz=1C1CHNU_enFR333FR333&sourceid=chrome&ie=UTF-8&q=/usr/lib/python2.5/site-packages/twisted/manhole/telnet.py:8:+DeprecationWarning:+As+of+Twisted+2.1,+twisted.protocols.telnet+is+deprecated.

The bug was confirmed, but no real solution provided:
https://bugs.launchpad.net/ubuntu/+source/apt-proxy/+bug/308376

The guys over there should also say that Debian stable Lenny is affected to.

Anyway, I dared to look deep into Apt-proxy source code. Guess what, it's written down in python ;)

Here is the solution I found : comment the line
from twisted.manhole.telnet import ShellFactory
at the top of the binary file of APT-proxy (something like /usr/sbin/apt-proxy).

And viola, it works!

I love /etc/init.d/apt-proxy start
Starting apt-proxy:None
None
.
I'll keep an eye on it to see what happens during the next upgrade of apt-proxy through... apt :)

Hope this helps.

Partager cet article

Repost0
18 septembre 2009 5 18 /09 /septembre /2009 21:17

This started when I wanted to try to run a BSD system inside a MS Virtual machine (Virtual PC 2007). Just to know for example, if the same problems as for Ubuntu occur (special command line options for the kernel needed to start the VM).

But... the only problem is I needed obviously a BSD iso, and the thing is PC-BSD is almost impossible to download from the official website: http://www.pcbsd.fr/content/view/2/3/#CD1 
I tried all their mirrors, none of them worked ("page not found", "error while trying to connect do database", and so on).

Guys... showing maybe 20 mirrors is indeed a good thing, and prove you care about quality of service (meaning download). But, if not even 1 out of 20 repositories work, that's even worse...


Furthermore, if those repositories do not respect the basics of HTTP servers security:
- no information disclosure in default error pages
- no obsolete components being left without security updates
Am I really supposed to trust that mirror?

Here is what I got:


Do I really have to install yTorrent to download an ISO of PC-BST x86 ? ...

Partager cet article

Repost0
15 septembre 2009 2 15 /09 /septembre /2009 23:16
Hey as people say: never say never, or never say "it'll never happen to them".

Nonetheless, even an AV vendor may not apply the basics of web server security: non-disclosure of versions information.


This URL comes from the virus sginatures added and listed in a daily update description. Therefore, anybody could access it, I did not have to try anything of hack in any way the ESET HTTP server.

I told my contacts at ESET about that. 72h later, it was fixed.

Though, I would point out a few details:
- apache 2.2.9 is obsolete (cf. http.apache.org)
- PHP 5.2.6 is also obsolete...

Well, the guys at ESET still some work to get done before they can affirm their server is really secured... 

Partager cet article

Repost0
18 juillet 2009 6 18 /07 /juillet /2009 23:55
As my blog title says, I'm a security watcher. And obviously, I keep an eye on one of the very last full disclosure list: Bugtraq.

Recently, a post drew my attention. It was about AV scanning evasion, using PDF files. And one of the engines that was said to be vulnerable was: Kaspersky... 

But, what was surprising to me was both the tone of the author and the word "forced disclosure" at the top of the advisory.

I understood immediately that again, an independent security searcher had to fight against a vendor, to allow his discovery to be counter analysed (at least!), published if necessary, and then, lead to a patch or update release.

But Kaspersky did not seem to listen to him, and they did not even reply to his numerous emails.

Even when F-Secure sent the PoC to K Labs, and asked them to reply, still no answer.


So Thierry Zoller had to use one of the extreme sides of full disclosure: "forced disclosure". Thus, the vendor could not ignore anymore that alert, since it was publicly announced thnaks to Bugtraq (after they had been notified in due schedule).

And indeed, the day after the Bugtraq publication (to me, a kindda security information broadcast), K Labs promised him a reply with updates...!



Here is the whole story:
http://blog.zoller.lu/2009/05/advisory-kaspersky-generic-pdf-evasion.html


This is one of the reasons why I sincerely uphold the full disclosure idea.
Among other risks (e.g. 0days publications leading to exploitations), this is sometimes the only mean to get a reply from vendors, and then, hope to see a patch/update being created.

There is already another world of information security disclosure, which is silent and filtered. It leads to an underground economy (cf. Symantec report), where you can buy 0days and malwares (not detected by the AV you choose)...

This is again a reason why we need security search and full disclosure, to find and announce security holes, and then try counter-measures before there is a vendor solution (or during the deployment delay).

What if tomorrow, there is no more full disclosure at all? a remote 0day exploit being discovered in a virtualization solution could bring the chaos to a lot of infrastructures (sounds familiar hmmm?). With no information, no remediation (at first)... What if the vendor does not react quite quickly, and does not offer technical support needed?

In that world, we would all have to pay for the information security, else we could only watch what's going on, incident after incident, and see the victims count increasing...

Partager cet article

Repost0
28 juin 2009 7 28 /06 /juin /2009 15:54
Ancien adapte de Winamp (surtout 2.x), j'ai quelque peu laissé ce lecteur multimédia aux oubliettes avec l'arrivée des versions 3, puis très rapidement 5, notamment pour des problèmes de performances (et aussi de sécurité).

Récemment, travaillant sur la problématique d'offre de lecteur multimédia sur poste de travail, sécurisé, Winamp est revenu sur la table.

Qu'à cela ne tienne, j'ai donc couru installer la bête sur ma machine personnelle.

Passons brièvement sur l'installation, longue et surtout peu claire pour un néophyte puisqu'il est proposé :
- un téléchargement de MP3 (gratuits ?)
- l'installation d'un serveur multimédia pour rediriger la lecture de la bibliothèque sur un mobile, ou tout autre PC
- des barres d'outils...

Comme indiqué plus haut, j'avais abandonné Winamp pour des raisons de consommation excessive de ressources.
Je crains que cela ne soit encore le cas, et voici pourquoi.

Constatant des accès disques nombreux, un Firefox ultra-gourmand en mémoire (déjà qu'en temps normal, ce n'est pas la gloire...), j'ai donc lancé l'outil SysInternals ProcMon.
Le résultat est assez éloquent :



On se rend tout de suite compte que Firefox lance de nombreuses requêtes vers le registre, plus particulièrement sur les clés associées à la barre d'outils de Winamp 5 !

Ne comprenant pas la justification d'une telle activité système pour la barre d'outil, et n'ayant pas trouvé de moyen de régler ce problème dans les paramétrages, j'ai donc supprimé cette fameuse barre...
Et je n'ai même pas regardé les flux réseaux... !

Au passage, signalons tout de même que la barre d'outil change de nombreux réglages du navigateur, notamment les pages de recherche, les "accélérateurs", les pages s'affichant lorsque l'on fait une faute de frappe sur une URL, etc...
Bref, j'appelle ça de l'intrusif !!!

Je préfère de loin AIMP et VLC, que je recommande à ceux qui ne les ont pas déjà.


A bon entendeur....  

Partager cet article

Repost0
23 juin 2009 2 23 /06 /juin /2009 00:37
Quand on est veilleur, on se doit de surveiller même les offres "grand public", car c'est justement elles qui pourraient tenter l'utilisateur, bien qu'il soit dans un contexte professionnel...

Cette fois-ci, j'ai donc jeté un nouveau coup d'oeil au Google Pack.

Quelques changements ont eu lieu dans le choix des logiciels faisant "partie" du "pack Google", bref.

J'ai donc téléchargé (presque) la totale, mais je n'ai pas osé l'outil Norton de peur d'un réel conflit avec mon AV déjà installé, et aussi suite à de nombreuses mauvaises expériences de problèmes sans fin pour la désinstallation des produits Norton...

Revenons à nos moutons, je lance le système Google Pack. L'intertace s'ouvre, on apprécie le mode tout automatique.

Un certain "spyware doctor" (de PC-Tools) va s'installer. De quoi challenger mon ESET.

Hé bien surprise, durant l'installation, ESET a du avoir tellement peur qu'il a lui-même
bloqué le pilote déployé par Spyware Doctor... et m'annonce un "PCAgent".

Le pire, c'est que l'installation s'est soit-disant bien passée...  Preuve que le système de contrôle d'intégrité après installation de PC Tools n'est peut être pas si au point que ça...

Presque inquiétant, le résultat complètement incohérent des scans antiviraux multimoteur sur : 
www.virustotal.com :
http://www.virustotal.com/fr/analisis/ea25afa088e47cb1bfa985f110927e88326f75b060d0c58405c211d5416b4dff-1245710329

Spyware Doctor est-il :
- un voleur d'identifiants bancaires ? (Win32.Banker)
- un élément de Win32/Monitor.PCAgent ?
- une variante (encore une !) de Trojan/Agent ?
- ou encore mieux : un "Unclassified Malware" ?  (c'est quoi donc ? )

J'avoue ne pas m'y retrouver moi-même.


Question finale :
Mais comment voulez-vous qu'un utilisateur lambda s'y retrouve si son antivirus sonne l'alarme quand il est en train d'installer un logiciel "made in google"...?

Parce que c'est bien connu : tout ce qui vient de Google est à la mode, sécurisé, et indispensable...
Non ? pourtant c'est ce qu'on entend souvent...



================ Eng summary ===================

After I had installed the Google Pack, my ESET AV warned me about a sys file being copied to System32, during the installation of Spyware Doctor (component of the Google Pack...).
You can see it on the screenshot above.
My question is: how a lambda user could make the difference between that kind of security alarm, and a real one?
What or who should he trust:: Google Inc or ESET?
Sometimes I don't understand AV policy detection choices!

Partager cet article

Repost0
1 juin 2009 1 01 /06 /juin /2009 22:56
Une fois n'est pas coutume, je vais jouer l'internaute lambda :)

On m'a parlé du site http://www.geoscopie.com/  qui soit-disant est bien classé au niveau Intelligence Économique.

En allant dessus, j'ai eu quelques difficultés à comprendre de quoi il était question, et pour cause : je ne suis pas bilingue en japonais...!

Voici une pseudo-traduction (merci aux gens de Mountain View) :
http://translate.google.com/translate?prev=hp&hl=fr&js=n&u=http%3A%2F%2Fwww.geoscopie.com&sl=ja&tl=fr&history_state0=

Et le plus fort, c'est que même avec la traduction, j'ai du mal à voir le rapport.
Entre l'achat de maison en bois, les caméras de sécurité, la robe de mariée, etc... j'avoue y perdre le fil.

Et pire, quand on regarde le WhoIs de ce domaine : http://www.domaincrawler.com/domains/view/http://www.geoscopie.com/ :
- le "networksolutionsprivateregistration.com" en technical contact ne saute pas aux yeux mais presque...
- les serveurs NS "WEBSITEWELCOME.COM"  classés rouge par Netcraft... (lien pour info)

Alors vengeance ? je le croirais presque...

Moralité :ne jamais considérer que parce qu'une URL est à priori connue, on peut l'ouvrir dans son navigateur sans crainte : l'antivirus + filtrage sur URL sont indispensables !


PS : le VRAI site, lui, est toujours là, mais l'URL est : geoscopies.net   ....

Partager cet article

Repost0
13 mai 2009 3 13 /05 /mai /2009 01:59
Voici (encore) un petit exemple de ce qui pollue quotidiennement nos B.A.L... avec en prime une charge virale.
Il s'agit bien évidemment d'une contrefaçon d'une communication WesternUnion sur un transfert d'argent qui n'aurait pas abouti !

Commençons par ce qu'un utilisateur "standard" voit :
"Western Union Transfer MTCN: 3251452526"
On pourra noter que, bien qu'il soit rédigé en anglais ce qui va déjà exclure des victimes potentielles toute une population non anglophone, ce courriel est plutôt bien rédigé, sobre, sans faute qui saute aux yeux...

Bref, on dirait presque un vrai (malheureusement).
Les mauvaises langues diront que les traducteurs automatiques ont fait des progrès, peut être...


Puis, voici les entêtes de ce courriel :
(ce qu'un utilisateur non averti ne voit donc pas)


On se rend toute de suite compte que la vraie adresse émettrice n'est pas sur la zone DNS westernunion.fr (ou.com). C'est pourtant la vraie zone DNS pour le service de transfert d'argent international qu'est Western Union !

On pourrait donc parler d'une sorte d'usurpation d'identité, pourquoi pas.
Il s'agit en fait techniquement d'une utilisation détournée (et contraire aux bonnes pratiques) du champ "Data From", qui est en fait à valeur informative (et  dont le contenu est par conséquent arbitraire !).

En fait, la vraie adresse d'émission SMTP est la suivante : help@clickability.com

Cette adresse apparaît dans le champ "Envelope-From", que le MTA Exim a pris soin de conserver dans les entêtes du courriel. Ce champ est tronqué dans la capture que j'ai réalisé, car la ligne est trop longue :.
from [122.164.212.138] (helo=abts-tn-dynamic-138.212.164.122.airtelbroadband.in)    by smtp.%serveur%.%TLD% with esmtp (Exim 4.69)    (envelope-from <help@clickability.com>)    id 1M3qrQ-0005Ca-So; Tue, 12 May 2009 14:15:06 +0200


Petit rappel, ces 2 champs FROM sont spécifiés dans les RFC 2822 et 2821.
Seul le champ "Envelope From" est obligatoire dans la transaction SMTP permettant le transit du courriel entre serveurs SMTP.
Ce champ est fourni lorsque l'on initie une session SMTP, dont je vous donne un petit mémento basé sur une démo pratique : https://helpdesk.islandnet.com/pep/smtp.php


Revenons aux entêtes du courriel, afin d'un peu mieux cerner son transit.
Le serveur SMTP émetteur initial a pour adresse IP : 122.164.212.138
Une simple recherche Google montre immédiatement que cette adresse est en liste noire chez :
Lashback.com (www.unsubscore.com/blacklist.txt)

En poussant un cran plus loin, sur dnsbl.info par exemple, on s'aperçoit que d'autres listes "DSNBL" signalent cette adresse Ip (voir http://www.dnsbl.info/dnsbl-database-check.php). Dans le lot, on reconnait SpamCop (qui n'est pas des moindres) et Barracuda.

Concernant le nom FQDN du serveur SMTP de départ, on le retrouve sur divers sites Internet, notamment ici : http://rss.uribl.com/reports/14d/dns_mx.html
Rank      dns_mx                                    Total          Not Listed        Black
#168    server500.appriver.com:10    19              14    73.7%        2 10.5%

Et là où cela devient tout de suite très concret, c'est qu'on se rend compte que
ce serveur est utilisé en pointeur MX de la zone DNS scoot.co.uk !
Information confirmée ici : http://www.domaincrawler.com/domains/view/scoot.co.uk/

Mais ce n'est pas tout... s'agissant d'un pointeur vers une zone tierce, on pourrait supposer qu'il s'agit d'un service de messagerie (externalisée certainement...) utilisé aussi par d'autres sites Internet.
Et là bingo, merci Google (ou malheureusement, selon le point de vue) : une requête de ce type permet de trouver plus d'une centaine de domaines Internet dont l'un des pointeurs MX est le server500.appriver.com !
http://www.google.fr/search?q=site%3Adomaincrawler.com+server500.appriver.com&ie=utf-8&oe=utf-8&aq=t&rls=com.ubuntu:fr:unofficial&client=firefox-a

Il est certainement superflu de rappeler que les éléments détaillés dans cet article tendent à démontrer que ce service de messagerie appriver.com a été compromis au niveau sécurité !


Au sujet de la charge virale :

Le courriel contient une archive au format ZIP.
Voici une analyse virale multi-moteur du fichier EXE (nommé "MTCN_INVOICE.exe") que contient cette archive :
lien sur jotti.org.
On a donc affaire à un Zlob ! qui n'est d'ailleurs pas nouveau dans le monde VX.

Dommage d'ailleurs pour Barracuda qui implémente normalement ClamScan comme couche antivirale, le test sur Jotti.org révèle que Clam ne voit rien pour cette variante de Zlob.


Bref, il ne fait pas forcément bon faire du business avec scoot.co.uk, ni passer par le service de messagerie de Appriver.com !

Partager cet article

Repost0
27 janvier 2009 2 27 /01 /janvier /2009 23:47
Comme dit le dicton "ce sont les cordonniers qui sont souvent les plus mal chaussés"...
Et là, je trouve qu'on n'est pas loin !

Comme beaucoup dans le métier, je connais et utilise très souvent les outils SysInternals (au passage, chapeau bas pour la maîtrise technique des systèmes Windows, de leurs API et de leurs couches basses...).

Mais récemment, en voyant Process Explorer planter allègrement, j'ai commencé à me poser des questions.
Le fameux ProceXP ne voulait même plus être relancé, soit disant pour un problème d'allocation de ressources.

Voyons voir la config du poste:
- portable avec un T5500
- 4 Go de RAM
- disque SATA
- Process Explorer dernière version (fourni avec la dernière version de la suite SysInternals, en date du 15/01/09)
et ... aucune application graphique, jeu, ou autre glouton en ressources, de lancé !


Pourtant, j'ai régulièrement des avertissements du type :

N'y croyant pas réellement, je fais donc "annuler". Pourquoi Process Explorer pourrait-il occasionner une perte de données sur mon ordinateur, alors que je l'utilise justement pour surveiller ce qu'il se passe sur la machine, et ainsi... éviter tout ennui...

Et fatalement, on en vient à :(le comble !) :



Mais quand on regarde les ressources prises par Process Explorer, il se passe visiblement quelque chose (image en meilleure définition) :


Presque 550 Mo de mémoire système "virtuelle" ? C'est totalement anormal et aberrant !

Je crains donc qu'il s'agisse d'une fuite de mémoire sur l'outil Process Explorer (Microsoft ayant englouti SysInternals...), outil qui justement était connu pour déceler les fuites de mémoire...  c'est même indiqué sur leur site.

Affaire à suivre...
Je n'avais pas constaté tous ces plantages avec la version précédente de ProceXP...

Partager cet article

Repost0
16 décembre 2008 2 16 /12 /décembre /2008 23:12
Comme indiqué dans le titre, et contrairement à ce semblent croire nombre d'internautes, un "faux moteur de recherche", ça existe...

Je prépare d'ailleurs un article à ce sujet, il sera publié sur une plateforme spéciale, et je mettrai certainement quelques éléments ici, en complément.

Je peux cependant déjà indiquer que le site signalé est une contrefaçon d'un des moteurs de recherche les plus connus au monde, puisqu'il indique le nom de ce fameux moteur en "arrière plan" de sa page d'accueil, et ce bien qu'il n'y soit pas affilié / autorisé.

Alerté sur le sujet, le fameux moteur de recherche (le vrai) va probablement lancer une procédure en justice, pour utilisation abusive de sa marque...

A suivre donc !

Partager cet article

Repost0