Nyx0uf's blog

I – Introduction

Bon, il fallait un titre accrocheur, je ne vais pas vous parler de ver, mais de virus, wikipedia pour la différence.

Pas de virus sur Mac, combien de fois ai-je entendu ça, combien de fois l’ai-je moi même dit (dans le temps).
La principale raison pour laquelle “il n’y a pas de virus sur Mac” est dû, il faut bien l’avouer, au fait de sa faible part de marché (< 10% - avec les iPhones).

Jusque là les experts en sécurité n'étaient pas trop attirés par Mac OS, mais les choses changent, les parts de marché augmentent doucement et donc on commence à voir de plus en plus d'articles traitant de sécurité sur Mac.
Lors de la conférence Blackhat USA 2009, au programme il y avait 2 confs sur Mac OS, les deux traitaient d'implémentation de rootkits, toutefois la seconde, plus avancée, utilise les contrôleurs USB des claviers aluminium d'Apple, ce qui rend le rootkit indétectable aux logiciels traditionels.
Read more…

Un petit point sur Snow Leopard après 10 jours d’usage.
Comme lors de la sortie de tout nouvel OS, il y a son lot de problème, et Snow Leopard n’a pas été epargné, pour preuve hier soir est sortie une première mise-à-jour, seulement 15 jours après la sortie de l’OS.
Liste des corrections
Read more…

HAhaHa, je lisais le bouquin ‘Brèves de clavier’ (moi rouiller ?!, non!) l’autre jour quand je tombe sur une espèce de comparaison trollesque des langages de programmation qui m’a bien fait marrer, la voilà :

Comment se tirer une balle dans le pied..?

En C :
Vous vous tirez dans le pied.

En C++ :
Vous créez accidentellement une douzaine d’instances de vous-même et leur tirez toutes dans le pied. Apporter une aide médicale est impossible car vous ne pouvez pas distinguer lesquelles sont les copies, chacune se montrant du doigt et disant “C’est moi là-bas”.

En Fortran :
Vous vous tirez une balle dans chaque doit de pied, itérativement, jusqu’à ce que vous n’ayez plus de doigts de pied, puis vous changez de pied et recommencez l’opération. Si vous n’avez plus de balles, vous continuez quand même, car vousn n’avez pas pensé à installer un gestionnaire d’exceptions.

En BASIC :
Tirez dans votre pied avec un pistolet à eau.
Sur gros système, continuez tant que tout le corps n’est pas trempé.

En COBOL :
AVEC un REVOLVER COLT45 VISER PISTOLER à JAMBE.PIED, ALORS appuyer BRAS.MAIN.DOIGT sur REVOLVER.GACHETTE.
ALORS retourner REVOLVER à HOLSTER. VERIFIER si CHAUSSURE.LACET doit être refait.

En Unix :
% ls foot.c foot.h foot.o orteil.c orteil.o
%rm *.o
%ls
No such file or directory

En Assembleur 8086 :
Vous ne pouvez pas tirer car le pistolet et les balles ne se trouvent pas dans le même segment.

En LISP :
(defun pan() (tirer (pied (viser (revolver (sortir())))))

Vous noterez que dans ce comparatif il n’y a pas d’allusion à Java, sans doute parce qu’il aurait fallu écrire un roman.. Plus sérieusement (ou pas) on pourrait avoir quelque chose de ce style :
En Java :
Après avoir installé les frameworks pistolet et personne, vous tentez vainement d’interfacer les 2 ensembles, mais manque de bol il vous manque environ 354 plugins dans votre IDE.
Houra, vous avez réussi à interfacer les 2 frameworks en utilisant respectivement toutes leurs classes, vous n’avez eu besoin que de 17 fichiers .java, vous êtes très fier de vous.
Mais c’était sans compter la JVM, la balle ne part pas assez vite et ne rentre pas dans votre pied.
Vous êtes dépité et décidez finalement de vous tirer une balle dans la tête (une vraie cette fois).

Qui a dit que je n’aimais pas le Java ? :>

Il existe sur Mac OS X une API nommée KUNC (Kernel-User Notification Center).
Cette API est utilisée par le kernel (typiquement un kext) quand celui-ci veut afficher des notifications aux utilisateurs ou lancer des commandes userland.
Il existe donc une fonction : KUNCExecute()
Voici le prototype prit de xnu-xxxx.xx.x/osfmk/UserNotification/KUNCUserNotifications.h (disponible ici) :

1
2
3
4
5
6
7
8

#define kOpenApplicationPath    0
#define kOpenPreferencePanel    1
#define kOpenApplication        2
 
#define kOpenAppAsRoot          0
#define kOpenAppAsConsoleUser   1
 
kern_ret_t KUNCExecute(char *executionPath, int openAsUser, int pathExecutionType);

La fonction est toute simple, voici un bref détail des 3 paramètres :
- executionPath : Le chemin vers le programme à exécuter.
- openAsUser : Flag prenant soit la valeur kOpenAppAsConsoleUser qui exécutera le programme avec les droits de l’user loggé, soit kOpenAppAsRoot qui lancera le programme avec les droits root.
- pathExecutionType : Flag qui spécifie le type d’application à exécuter qui peut être un des 3 définis plus haut, kOpenApplicationPath : le chemin absolu vers un exécutable, kOpenPreferencePanel : le nom d’une Preference Pane dans /System/Library/PreferencePanes, kOpenApplication : Le nom d’une application dans /Applications.

Par exemple si on voulait lancer une backdoor située dans /tmp on procéderais de la façon suivante :

1

KUNCExecute("/tmp/backdoor", kOpenAppAsRoot, kOpenApplicationPath);

On entend souvent beaucoup de chose sur Mac OS X et son noyau, qu’il est écrit en C++, que c’est un microkernel.. blabla…
Qu’en est-il réellement ?
Le noyau de Mac OS X n’est pas un microkernel, c’est un noyau hybride nommé XNU, qui est un acronyme récusrsif pour XNU’s Not Unix.
XNU est sous licence APSL, et est donc téléchargeable sur le site opensource.apple.com.

Read more…

En surfant l’autre jour (sur le net hein..) je suis tombé sur un bout de code sur le site osxbook pour simuler un kernel panic.
Bon et comme sur Mac on en voit pas souvent [TROLL=ON]PAS COMME SUR WINDOWS[TROLL=OFF] je me suis dit qu’il fallait que je vous montre ce petit bout de code

1
2
3
4
5
6
7
8
9
10
11

#include <sys/types.h>
#include <sys/sysctl.h>
 
#define KERN_PANICINFO_TEST (KERN_PANICINFO_IMAGE + 2)
 
int main(void)
{
    size_t oldnewlen = 0;
    int mib[3] = { CTL_KERN, KERN_PANICINFO, KERN_PANICINFO_TEST };
    return sysctl(mib, 3, NULL, (void*)&oldnewlen, NULL, oldnewlen);
}

1
2

gcc panic_test.c -o panic_test
sudo ./panic_test

Résultat :

Notez qu’il faut être root pour exécuter le programme (à cause de l’appel à sysctl()).

Y a un autre article sur le site pour changer l’écran de kernel panic, bon sa sert à rien mais quand on s’ennuit pourquoi pas…

Je me suis souvent demandé lorsque j’avais besoin de faire des opérations de lecture / écriture dans des progs, quelle était la taille optimale du buffer.
Après quelques recherches j’ai fini par trouver.
Il faut se servir de la fonction stat, laquelle nous remplit une struct stat, qui contient un champ intéressant (extrait du man):

1

u_long st_blksize; /* optimal file sys I/O ops blocksize */

Voici un petit exemple d’utilisation très minimal qui se contente juste de lire le fichier passé en argument :

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
32
33
34
35
36
37
38
39

#include <stdio.h>
#include <fcntl.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <sys/types.h>
 
int main(int argc, const char* argv[])
{
	int fd;
	struct stat s;
	unsigned char* buffer;
 
	stat(argv[1], &buf);
 
	if (-1 == (fd = open(argv[1], O_RDONLY)))
	{
		perror("open() ");
		return EXIT_FAILURE;
	}
	if (NULL == (buffer = (unsigned char*)malloc(s.st_blksize * sizeof(unsigned char))))
	{
		close(fd);
		perror("malloc() ");
		return EXIT_FAILURE;
	}
 
	unsigned long ul_bytes = 0;
	while (ul_bytes < s.st_size)
	{
		ssize_t bytes_read = read(fd, buffer, s.st_blksize);
		ul_bytes += bytes_read;
	}
	free(buffer);
	close(fd);
 
	return EXIT_SUCCESS;
}