mercredi 14 janvier 2015

Le cas de la backdoor incluse dans Lotus Notes

TL/DR : Si vous avez Lotus Notes 8.5 ou 9 sur vos postes de travail, désactivez le service "IBM Notes Diagnostics" (process : nsd.exe) dès que possible. Il permet à un utilisateur lambda d'élever trivialement ses privilèges jusqu'à SYSTEM.


J'ai déjà eu l'occasion d'émettre de sérieuse réserves sur les logiciels IBM. Mais je ne pensais pas qu'il iraient jusqu'à inclure une backdoor donnant les droits SYSTEM dans un logiciel de messagerie !

Depuis la version 8.5, l'installation du client Lotus Notes provoque l'installation d'un service "Diagnostics IBM Notes" ("IBM Notes Diagnostics" en VO). Sa description est "Effectue des diagnostics pour le compte de IBM Notes". Vous l'avez peut-être déjà rencontré si vos utilisateurs vous remontaient ce bug.

Lors de nos audits de sécurité "Poste de travail" de ce début d'année, nos auditeurs (Cogiceo, merci les gars) se sont intéressés à ce service. Quelle ne fut pas notre surprise de constater que ce "débuggeur" gracieusement fourni par IBM aurait pu s'intituler "Rootkit Deluxe" sans problème. Il inclut en effet un mode interpréteur CLI (nsd.exe -monitor) qui permet de dialoguer avec ce service SYSTEM.

L'une des commandes disponible dans ce mode est LOAD <prog> <args>. Qui permet tout simplement de lancer (en interactif !) un programme avec les droits du service NSD, donc SYSTEM par défaut.

De là l'exploitation est triviale (LOAD mmc, LOAD cmd...). Il suffit de cliquer sur la petite icône demandant de passer sur "le bureau sécurisé" ou le programme demandé "requiert notre attention"...







Trivial non ?

Bien que cela soit déjà amplement suffisant, les autres commandes CLI fournies par NSD.EXE semblent tout aussi prometteuses : attachement à d'autres process, kill et autres dump de mémoire ("sauf lsass.exe qui est exclu par défaut car il présente un comportement anormal quand on lui demande ses handle système" précise sans rire la documentation)

Bien qu'IBM recommande chaudement (peut-être sous la houlette de la NSA ?) de laisser ce service NSD démarré en permanence, si vous voulez éviter que n'importe quel utilisateur se retrouve avec les droits SYSTEM sur leur machine, je pense qu'il vaut mieux le désactiver (ou désinstaller Lotus Notes partout...)

mercredi 14 mai 2014

Le cas de l'imaging lent sous WinPE d'un poste RAID


Quand on crée un "master" pour postes Windows, de nos jours c'est sous WinPE, l'environnement Windows minimal d'installation gracieusement mis à disposition par Microsoft.

Pour faciliter le travail des installateurs d'OS, WinPE inclut un grand nombre de drivers réseau et disque, ce qui évite d'avoir à les injecter soi-même (avec DISM) ou via la suite d'installation (MDT...)

Par contre il y a un piège à ça : dans le cas de postes avec du RAID Intel. Si on n'injecte pas les drivers Intel SATA/AHCI/MatrixRaid etc. dans WinPE, au moment de l'imaging (avec imagex /apply) les perfs risquent fort d'être désastreuses. Car le driver Microsoft par défaut, qui faisait vaillamment son travail pour les postes non-RAID, va avoir beaucoup de mal à écrire sur le volume RAID. Et en plus il y aura de grandes chances pour qu'il n'ait écrit que sur un disque (dans le cas d'un RAID1), cassant ainsi la synchro raid (et votre OS :-))


Récupérer les drivers peut parfois être un parcours du combattant sur le site du constructeur (d'autant qu'il vaut mieux avoir la même version de driver pour chaque composant SATA / AHCI / etc) mais une fois récupéré et injecté avec DISM ou votre outil d'intégration, vous devriez voir tout de suite la différence !


lundi 21 octobre 2013

Les cas des perfs disque pourries sous AIX

Dans le cadre de la refonte de notre système applicatif, nous passons d'une techno système IBM (System i, alias iSeries alias AS/400) à une autre (AIX, alias sans doute "AIX Is not quite UNIX").

Comparé à ce vénérable ancêtre qu'est l'AS/400, l'AIX est un système POSIX qui a le bon gout de supporter, lorsqu'il est virtualisé sous la plateforme PowerVM d'IBM (leur vSphere à eux pour processeurs Power), la virtualisation de son stockage par une solution comme Datacore SANSymphony-V.

Attention : ne pas confondre.

Datacore pour une infra VMWare c'est que du bonheur : énorme boost de perf (grâce au caching en RAM des accès disques), grosse flexibilité pour le stockage (snapshoter, copier, redimensionner ou déplacer des LUNs d'une baie à une autre sans que les serveurs ne se rendent compte de rien) et bien sûr PRA/PCA facile avec un mirroring intégré entre deux (ou plus) serveurs Datacore. Le seul truc bizarre c'est que ça tourne sur du Windows (2008 R2 ou 2012) que l'intégrateur recommande de ne pas patcher, mais bon x)

Côté perf donc, si on parle en I/O par secondes comme aime IBM, disons qu'en branchant une baie entrée de gamme type IBM DS3524 qui plafonne à 8000 IOPS sur un serveur Datacore avec 42 Go de RAM on en tire illico 25-30 000 IOPS. Hé oui.

Côté débit d'écriture on peut tabler facile sur du 500-800 Mo/s ce qui n'est pas mal du tout pour écrire in fine sur des disques physiques en SAS (et en Raid5).

Quelle ne fut donc pas la surprise de notre intégrateur AIX en voyant les débits d'écriture, sur nos nouvelles partitions virtuelles fraîchement installées, tapant via notre Datacore sur une baie encore vierge de toute production, plafonner péniblement à du 100-250 MBps.
Moins bien nous dit-il que sur sa maquette perso à base de matos bricolé. Un peu vexant non ?

Je vous la fait courte : après avoir fait des tests de perfs dans tous les sens, pas de HBA défectueux, de disques chinois USB 1.0 cachés dans un boitier SAS, de saturation sur les switchs FC ou d'options de pilotes manquantes.

Juste une case à cocher. Dans les options de la "machine virtuelle" AIX dans la console HMC.

Celle-là : 

Comme l'a dit l'intégrateur "lol lol lol" !
Il suffisait d'y penser, IBM l'a fait. Une case à cocher, décochée par défaut, pour ne pas diviser ses perfs par 3.

Simple et de bon goût non ?

mercredi 18 septembre 2013

Le cas de la restauration du vCenter via TSM

Il y a des après-midi où rien ne va : la connexion WAN en fibre optique double sa latence subitement (le fournisseur a une fibre endommagée entre Paris et Marseille et bascule tous ses clients sur la même), une VM coeur de métier utilisée par 50 personnes se met à cracher des erreurs disques (bien qu'elle soit sous VMware et sur un SAN Datacore...) et pour couronner le tout, au même moment le vCenter décide de lâcher.

Ce vCenter est lui-même une VM, la vCenter Virtual Appliance 5.1 fournie par VMWare. Je me rappelle qu'à l'origine je n'étais pas très chaud pour avoir une VM pour gérer toutes nos VMs... mais après tout même VMware le recommande maintenant.



La virtual appliance tout-en-un semblait aussi bien pratique plutôt que de monter une VM Windows Server 2008 R2 pour le vcenter, plus une VM 2008 R2 avec SQL Server pour sa base, plus une autre pour le SSO... overkill pour une centaine de VMs sur une demi-douzaine  d'ESXi. En plus elle tourne sous Linux (SuSE), ce qui résout le problème d'oeuf et de poule d'avoir une VM Windows membre du domaine (pour les mises à jour, la sécurité, le SSO...) qui doit pouvoir fonctionner quand tous les DCs (qui sont des VMs) sont éteints / hs pour une raison ou pour une autre (crash/sauvegarde...).

Sauf que sa stabilité a souvent laissé à désirer. Comme ce lundi où elle commence à bagoter, un reboot résout le problème, jusqu'à ce mardi après-midi où elle cesse de répondre aux requêtes VMWare API et tous nos vClients se ferment sans vouloir se reconnecter. Cette fois le reboot ne résout rien, et une tentative de forcer la mise à jour vers l'appliance 5.1b (via l'interface Web) aggrave les choses : impossible de se loguer sur le serveur, il rejette les connexions SSH comme console !

Le remède semble clair : restaurer le vCenter, en revenant au backup VM du week-end obligeamment effectué par notre serveur TSM équipé du module TSM for Virtual Environments !

Sauf que quand l'exploitation lance la commande, paf !

ANS9365E tcp_connect() protocol error between client and server

Hmm une erreur de connexion entre le serveur TSM et client TSM for VE ? C'est bizarre, vu qu'ils sont installés sur le même serveur  (physique lui !). Mais soit, des mises à jour Microsoft sont en attente, un petit reboot et ça repart (comme je dis toujours :  "dans le doute, reboot !"). Ou pas. Même message.

Bon, vu le freeze de 30 sec de l'interface graphique Java (beurk) quand on lance le restore VM, ça sent le timeout réseau (visiblement IBM n'a pas trouvé la classe Thread dans la doc Java). Un petit netstat -an| find "SYN" et hop :

tsmsrv -> vcentersrv:443 SYN_SENT

Visiblement il essaie de contacter le vCenter. Justement celui qui est tout mort et que je veux restaurer. Ah ben oui c'est bête mais pour restaurer le vCenter via TSM for VE, il me faut un vCenter actif. Owned.


Bon ça se comprend vu qu'il doit l'enregistrer tout ça tout ça. Mais bon il doit bien y avoir un moyen de restaurer directement sur un ESX(i) sans passer par un vCenter, hmm ? Sinon c'est tout notre PRA/PCA qui devient un peu naze...

En fouillant les arcanes de la doc en ligne IBM, on trouve quelques KB intéressantes, parlant d'options bien sûr non documentées dans l'aide de la commande "restore VM" (ce serait trop simple) :

So, to restore a VM guest to a standalone ESX server where there is no vCenter server in the environment, the following command should be used:

dsmc restore VM <source VM name> -vmname=<target VM name> -host=<target ESX host> -datacenter=ha-datacenter -datastore=<target datastore> -vmchost=<target ESX host> -vmcuser=<user> -vmcpw=<password>



Donc on peut visiblement overrider les variables vmc* du dsm.opt (fichier d'options du client TSM) pour ne pas le faire pointer sur le vCenter mais sur un esxi directement. Sauvés !

On lance la commande, et hop !

Ça marche pas.


09/17/2013 23:25:28 ANS5250E An unexpected error was encountered.
   TSM function name : vmCreateNewVmMachine
   TSM function      : ANS4165E Creating a Virtual Machine, but the hostname 'monesx.mondomaine' was not found.

   TSM return code   : 4391
   TSM file          : ..\..\common\vm\vmcommonrestvddk.cpp (753) 

09/17/2013 23:25:28 ANS9372E Unable to create the virtual machine to be restored due to an invalid host name, datacenter name, or datastore name.

Qu'est-ce que c'est que ce message bien naze comme quoi il trouve pas l'hôte de la VM, c'est à dire l'ESXi, alors que ça résout bien côté DNS et que ça ping dans tous les sens. J'essaie avec l'ESXi qui héberge la VM, en tentant une restauration "sur place" : là il me dit que la VM existe déjà dessus et que je peux me brosser pour qu'il l'écrase (visiblement TSM n'aime pas remplacer des VMs). J'essaie en changeant le nom de la VM restaurée, ou en attaquant les ESXi par IP : marche pas. J'essaie avec un faux mot de passe root : même message, donc il essaie même pas de se connecter pour la créer, sa *ùù$ù* de VM. J'essaie sans préciser l'hôte : il prend par défaut celui qui héberge le vCenter actuel. Donc en gros il a stocké quelque part l'info d'où le restaurer par défaut, et on échoue sur la validation de ce paramètre.

Arrivé là on hésite à partir sur la réinstallation du vCenter from scratch, mais ça sent quand même bien le bug à la con. Nouvelle tentative en passant toutes les options directement en arguments à la ligne de commande "dsmc" (sans rentrer dans le client interactif en ligne de commande). Cette fois il s'authentifie bien sur l'ESX (si je met un faux mot de passe ça foire). Mais le même message sur l'hôte introuvable. Probabilité de bug à la con : + 50%.

C'est là que l'expérience douloureuse avec les merveilleux logiciels IBM (Lotus, Tivoli, Traveler, iSeries...) paye : je subodore un problème de casse dans le nom qu'il attend. Les logiciels IBM aiment bien être case sensitive quand il n'y a pas lieu de l'être et vice versa. Je me logue sur un ESXi et regarde comment lui-même écrit son FQDN : bingo, il met l'hôte en majuscules et le domaine en minuscule. Je mets la même casse pour l'argument host et, ô joie ô bonheur ô cri devant mon écran à 23h30, TSM daigne enfin commencer la restauration du snapshot du vcenter.

Restauration qui foire aussitôt.

09/17/2013 23:33:02 ANS4187W CPU and Memory Resource Allocation configuration settings cannot be restored when the IBM Tivoli Storage Manager data mover node is connected directly to a Virtual Center managed ESX/ESXi host. These settings have been skipped.
09/17/2013 23:33:04 ANS9365E VMware vStorage API error for virtual machine 'vcentersrv'.
   TSM function name : visdkCreateVM
   TSM file          : vmvisdk.cpp (4845) 
   API return code   : 67
   API error message : A specified parameter was not correct. 

09/17/2013 23:33:04 ANS5250E An unexpected error was encountered.
   TSM function name : vmCreateNewVmMachine
   TSM function      : Can not create virtual machine
   TSM return code   : 4389
   TSM file          : ..\..\common\vm\vmcommonrestvddk.cpp (822) 
09/17/2013 23:33:04 ANS9404E Error creating the specified Virtual Machine. See log files for more information.

On n'est pas encore couchés quoi.
A nouveau on google les code d'erreurs et codes de retour TSM (ça au moins IBM le gère super bien : chaque code unique et tout) et on tombe à nouveau sur de croustillantes KB :


Ça devient de plus en plus sympa cette histoire : pour peut-être réussir à restaurer ma VM je dois passer des options expérimentales dans le fichier de config de mon client/proxy TSM, pour qu'il crée un OVF (XML) de la VM que je veux restaurer, le modifier en sabrant des options au pifomètre jusqu'à tomber sur celle(s) qui pose(nt) problème, et qu'il se base sur mon OVF modifié pour créer la VM restaurée...



Quand faut y aller faut y aller je suppose. Quel beau logiciel parfaitement approprié pour la sauvegarde d'infrastructures virtuelles...

Première tentative : Je vire carrément toutes les options "tsm:ExtraConfig" de l'OVF. Pas le temps de faire dans la dentelle. Miracle, la restauration démarre et je vais me coucher (après m'être fendu d'un petit mail gentil au type qui a choisi et fait installer/configurer TSM).

Arrivé au bureau le lendemain, pas de bol, la VM restaurée et démarée dégueule des lignes de message d'erreur disque. Quelque chose me dit que j'ai sabré trop d'options. Je fais une seconde tentative de restauration en ne virant qu'une seule des "tsm:ExtraConfig" qui a vraiment une sale gueule dans Notepad++.

Pile poil, il commence la restauration...