S’envoyer des SMS multilignes via l’API de free-mobile

Free vient de mettre à disposition de ses abonnés Free-mobile un moyen simple de générer via une API accessible en ligne des SMS à soi-même. L'utilisation est globalement très simple et tient presque toutes ses promesses (actuellement il ne semble pas possible de faire du POST, seul le GET fonctionne).
Il suffit aux intéressés de se rendre sur leur interface de gestion de compte Free-mobile, dans la section "Mes options", et d'y activer (vers le bas de la page) l'option ad-hoc. Une fois l'option activée, Free vous gratifie d'un mot de passe dédié à cet usage, et vous renseigne un peu sur le fonctionnement du service :

free-mobile-notification

Une fois l'option activée, l'utilisation se résume à une requête HTTP de cette forme :

curl 'https://smsapi.free-mobile.fr/sendmsg?user=***&pass=***&msg=coucou'

Vous recevez alors sur votre téléphone Free-mobile le SMS contenant le message "coucou".

La création d'un message multiligne est un peu plus délicate. La plupart des plateforme Unix/Linux envoie en guise de séparateur de ligne un \n qui se traduit par %0a une fois "url-encodé". Malheureusement, l'API n'accepte pas ce %0a et le message sera tronqué à la première occurrence.
Par contre, le séparateur de ligne \r, encodé en %0d est bien accepté par l'API Free-mobile. Il faut donc, avant d'envoyer un message sur plusieurs lignes, traduire les \n en \r.

J'ai conçu un script shell pour mes besoins personnels. Il prend ses données en entrée standard, par exemple via un pipe :

echo "mon message" | sms.sh

Ce qui est plus souple pour moi dans bien des situations, que de devoir invoquer le script et de lui servir le message comme argument, par exemple :

autresms.sh mon message

Voici donc le code de mon script qui prend les messages via stdin, et qui converti les \n en \r. Notez que le SMS à l'arrivée ne contient pas de saut de ligne, donc prévoyez des espaces en fin de ligne si vous ne voulez pas que la fin de ligne soit collée au début de la ligne suivante.

#!/usr/local/bin/bash  
#
# push notification via smsapi.free-mobile.fr
#
LOGGEROPT="-p security.notice -t SMS"
REPLOGG=1
REPMAIL=1
MAILTO=root
USR="****"
PSW="****"
URL="https://smsapi.free-mobile.fr/sendmsg"
CURL=/usr/local/bin/curl

report() {
        [ ${REPLOGG} -eq 1 ] && echo $@ | logger ${LOGGEROPT}
        [ ${REPMAIL} -eq 1 ] && echo $@ | mail -s "SMS $@" ${MAILTO}
}

eval $(${CURL} --insecure -G --write-out "c=%{http_code} u=%{url_effective}" \
        -o /dev/null -L -d user=${USR} -d pass=${PSW} --data-urlencode msg="$(cat|tr '\n' '\r')" ${URL} 2>/dev/null | tr '&' ';')

echo ${c} ${u}\&pass=***\&msg=${msg} | logger ${LOGGEROPT}

case ${c} in
        "200")
                exit 0
                ;;
        "400")
                report "parameter missing" ; exit 400
                ;;
        "402")
                report "too many SMS..." ; exit 402
                ;;
        "403")
                report "service unavailable for user, or wrong credentials" ; exit 403
                ;;
        "500")
                report "server error, try later" ; exit 500
                ;;
        *)
                report "unexpected result" ; exit 600
                ;;
esac

Utilisation :

echo "mon message 
sur plusieurs 
lignes" | sms.sh

Il reste à faire :
- ajouter l'enregistrement dans les log système de chaque utilisation du script sms.sh
- ajouter la gestion des codes de retour HTTP autres que 200.

Attention
Pour bénéficier d'une gestion d'erreur et d'une trace dans les log de la machine j'ai utilisé une grosse ruse très sale avec eval. Cela permet de créer des variables à la volée à partir de données fournie par l'utilisateur. C'est éminemment risqué car tout ce est qui généré par c=%{http_code} u=%{url_effective} sera évalué sans distinction (avec potentiellement des exécutions de code).
Pour un système de monitoring c'est un risque négligeable : les messages sont connus et fixés par le logiciel qui les génère, sans interaction avec l'utilisateur. Pour une utilisation dans tout autre mécanisme la prudence est requise.

Related posts

Le PC dans mon téléphone

Précédemment, j'ai évoqué l'ordinateur de demain. J'ai fait un test grandeur nature façon corporate. Comprendre : vous aurez du mal à faire pareil chez vous. J'utilise en effet quelques artifices comme un accès VPN au réseau de mon employeur, et au travers de cet accès une machine virtuelle VMware View.
Au final, j'ai le bureau d'une machine Windows 7 affiché sur la TV du salon, j'ai un clavier et une souris bluetooth, le tout servi par mon téléphone malin, via un tunnel VPN dans une connexion WIFI. La connexion avec la machine virtuelle se fait via le client officiel View, de VMware (donc en PCoIP).

Windows dans ma TV sur mon téléphone

Ci dessus une photo de la TV affichant le bureau de la VM dans laquelle est lancé le client VSphere (outil d'administration de datacenter VMware).

À 2m50, le texte dans l'interface n'est pas hyper lisible sur l"écran 80cm, donc pour le PC dans le canapé, on repassera, ou alors on fera des réglages spéciaux sur la machine virtuelle.

Le client View se comporte relativement bien, néanmoins, il y a comme un petit souci avec le clavier. Ce dernier fonctionne parfaitement en azerty partout, sauf à l'intérieur du Windows, où il fonctionne en qwerty. Le client View dispose d'un champs de saisie qui permet de taper du texte à l'extérieur de la VM et de l'envoyer ensuite vers cette dernière. À cet endroit, c'est bien de l'azerty. Mais le même texte tapé directement dans la VM passe en qwerty. C'est peut être du à mon téléphone, qui est paramétré tout en anglais.

Aussi, suite à un blocage logiciel sur ma VM, j'ai tenté un ctrl-alt-suppr via mon clavier bluetooth. Le programme n'a pas rendu la main, la VM n'a pas rebooté. Non. C'est le téléphone qui a rebooté. Ça m'a fait rire.

Related posts

Collecte en aveugle

Elle est belle celle-là :

213.61.149.100 […20:00:26 +0100] "GET / HTTP/1.0" 301 235 
213.61.149.100 […20:00:27 +0100] "GET /blog/ HTTP/1.0" 200 63772 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:28 +0100] "GET /www.patpro.net.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:29 +0100] "GET /www.patpro.net.sql HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tar.gz HTTP/1.0" 404 493 
213.61.149.100 […20:00:30 +0100] "GET /patpro.tgz HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.zip HTTP/1.0" 404 493 
213.61.149.100 […20:00:31 +0100] "GET /patpro.sql HTTP/1.0" 404 493 

Et particulièrement astucieuse, je suis persuadé qu'elle permet de ramasser des tonnes de trucs très intéressants.

Related posts

On s’amuse avec IPMI

AOC-IPMI20-E-copyright-supermicroJ'ai passé un week end plutôt divertissant en compagnie d'IPMI. Tout a commencé avec la lecture d'un article édifiant sur arstechnica.com présentant IPMI comme un parasite, une sangsue.
J'ai toujours su instinctivement que l'IPMI pouvait, quelque part, poser un souci en terme de sécurité. Mais jamais je n'aurai imaginé que la situation fût aussi dramatique.
Les failles sont à tous les niveaux, tant dans le protocole IPMI, que dans les implémentations semi-propriétaires des fabricants. Elles sont dans les logiciels utilisés, elles sont dans le verrouillage que les fabricants imposent aux BMC, les rendant impossible à auditer, etc. Sysadmin de tout poil, je vous invite fortement à lire l'article d'Ars, et les proses de Dan Farmer et HD Moore.

Bref, j'ai tout lu, et disposant d'exemplaires HP et SuperMicro, j'ai tenté moi-même d'exploiter les failles décrites. Je ne rentre pas dans les détails, tout est déjà très bien expliqué dans la littérature sus-mentionnée. Par contre je vais donner quelques pistes pour l'installation des outils sous FreeBSD.

ipmitool, l'outil de base doit être installé avec FreeIPMI, sinon les manipulations permettant d'exploiter les BMC vulnérables ne fonctionneront pas. Sous FreebSD on peut simplement utiliser les ports :

# cd /usr/ports/sysutils/ipmitool
# make install clean
On active l'option "FREEIPMI" dans la configuration, et c'est parti.

On active l'option "FREEIPMI" dans la configuration, et c'est parti.

Ensuite il est possible d'installer metasploit, outils puissant et complexe. Pour gagner du temps, et si vous ne souhaitez pas approfondir l'usage de ce logiciel, vous pouvez décocher l'option "DB" au moment de l'installation du port :

# cd /usr/ports/security/metasploit
# make install clean

Si vous souhaitez jouer un peu avec les outils et scripts développés par Dan Farmer, vous devrez installer en plus le module perl CaptureOutput.pm, nécessaire au fonctionnement de rak-the-ripper.pl :

# cd /usr/ports/devel/p5-IO-CaptureOutput
# make install clean

Si vous avez en plus une machine disposant d'une BMC qui tourne sur FreeBSD, voici ce qu'il faut faire pour accéder à ce contrôleur parasite via ipmitool :

# kldload ipmi

Cela charge le module ipmi, si ce n'est déjà fait. Vous aurez quelque chose de ce style dans la sortie de dmesg -a :

ipmi0: <IPMI System Interface> port 0xca2,0xca3 on acpi0
ipmi0: KCS mode found at io 0xca2 on acpi
ipmi0: IPMI device rev. 1, firmware rev. 2.35, version 2.0
ipmi0: Number of channels 2
ipmi0: Attached watchdog
ipmi1: <IPMI System Interface> on isa0
device_attach: ipmi1 attach returned 16

Et vous pourrez ensuite vous livrer à toutes sortes d'expériences en local (donc une fois de plus sans authentification…).
La prudence veut que vous désactiviez immédiatement ce module ensuite :

# kldunload ipmi

même si, ne nous voilons pas la face, ça retarderait juste de quelques dizaines de secondes un éventuel attaquant.

Mettez bien à jour le firmware de vos BMC. Et quand je dis bien à jour, c'est très sérieux, puisque des firmwares récents chez HP (juin) ne corrigent pas l'énorme faille du Cipher-0. Il faut utiliser le firmware 1.60 publié fin juillet pour avoir une chance de corriger cette faille de sécurité.

Related posts

Message personnel à Mme Filippetti

Bonjour Madame Filippetti,

Votre entrevue récente avec Libération m'interpelle. Vous y déclarez ceci :

Vous avez aujourd’hui des outils qui permettent d’accéder à de la musique, du cinéma, des contenus audiovisuels, mais qui ne participent pas du tout au financement de la création. Ce n’est pas normal.

Allez-vous taxer les lunettes, lentilles correctrices, et appareils auditifs ? En toute logique, nous sommes nombreux à ne "consommer" de la culture qu'au travers de ce type d'appareil, il serait donc judicieux de les taxer rapidement.

On n'est pas loin du monde idéal rêvé par les gros portefeuilles de l'entertainment : un monde où la simple possibilité d'accéder à du contenu devient payante, qu'on y accède ou pas. Ça évite d'avoir à courtiser les clients avec des contenus de qualité, bien trop compliqués et coûteux à produire. Il vaut mieux comme toujours prendre un peu à tout le monde que beaucoup à une minorité.

Bref, raz le bol quoi.

Related posts

Pas tous égaux devant le spam

Là où je travaille, une partie de la population ne reçoit pas de spam, ou presque. L'autre partie reçoit une grosse quantité de spam. La raison est simple : les utilisateurs du second groupe ont leur adresse email publiée sur le portail web de l'université.
Alors bien sûr, c'est une évidence. On le sait tous depuis longtemps : une adresse email publiée sur un site web devient immanquablement, et en l'espace de quelques jours, une cible privilégiée pour le spam. Oui, on le sait. Mais est-ce qu'on le mesure ?
Comme mes serveurs MX brassent des millions de messages par mois, je peux faire des statistiques assez simplement (moyennant de longues heures de traitement sur des giga octets de logs). J'ai donc compté le spam visant les deux groupes, ainsi que les volumes de phishing relevés lors de 4 "attaques" facilement traçables. Le constat est sans équivoque :

Une adresse email publiée sur le portail web de l'université reçoit 31,2 fois plus de spam qu'une adresse non publiée.

Une adresse email publiée sur le portail web de l'université a 59 fois plus de risque d'être la cible d'un phishing qu'une adresse non publiée.

À bon entendeur...

Related posts

Aux utilisateurs de Google Reader…

RSS-iconeSi vous figurez au nombre des utilisateurs qui suivent ce blog au travers de Google Reader, sachez que ce service de Google va fermer en juin 2013.
Vous pouvez dès à présent migrer vos flux RSS vers la solution de pulse.me ou celle de feedly.com. Dans les deux cas vous pourrez importer directement vos feed.

Related posts

To data, or not to data

On me glisse à l'oreille qu'un téléphone malin sans forfait "data" c'est un peu comme un pantalon sans poche : un truc de fille. Ce à quoi je réponds sans ambages et avec les mots d'un autre : j'aime les filles.
Je n'adhère pas au principe de consommation des smartphones qui lave les cervelles à coup de faux illimité vraiment limité, de forfaits à 50 euros qui servent juste à regarder des chats sur youtube, et qui encourage la débauche d'appli au dépend immédiat de la sécurité de l'utilisateur. Globalement, je suis devant ou à proximité d'un ordinateur connecté à internet environ 16 heures par jour, pendant environ 6 heures je dors, il me reste donc 2 heures "loin" d'internet. 2 heures pendant les quelles je me déplace, je mange, je me douche, etc.
Alors à quoi me servirait un forfait data ? Relever mes mails dans le tramway, au lieu de savourer un bon bouquin ? Non merci. A fortiori puisque je m'en passe depuis que ça existe et que je ne suis pas pressé d'ajouter une dépendance à ma liste. J'ai pris le minimum avec mon forfait à zéro euros : l'option data à 1 euro pour 20 Mo de données. Autant dire que ça se consume comme un feu de paille. En désactivant la fonction de consommation data de mon téléphone, je me garde une petite réserve sous le coude pour les urgences, et c'est tout ce dont j'ai besoin.

Related posts