Currently on: Stripe's Capture The Flag

I'm all excited about this contest. Although I've been running many of these, this one is particularly well structured, with a strong emphasis on web applications, injections and analysis of source code. The source code for all exercices is given. It's always amazing how you can make software work in unthought ways.

The programme is, at least : code injection, SQL injection, Javascript injection, and that in PHP, Ruby, Python and of course, HTTP protocol ;-)

For now, I just arrived to level 6 (out of 8). Much fun, some learning and much practicing. A must-do if you're interested in IT security.

If you're aware of other security contests like this one, please let me know, I'm always interested.

Time passes so fast

First time I worked as CISO: almost 5 years ago,
first time I was paid by a company just to do IT: 8 years ago,
first time I owned a PC on my own: 12 years ago,
first time I wrote a full-featured game, on a TI calculator: 13 years ago,
first time I gave a lesson on IT matters: 13 years ago,
first time I used Linux as my main OS for home: 13 years ago,
first time I reverse-engineered a piece of software: 14 years ago,
first time I used the Internet, wrote a website (and learnt English): 15 years ago,
first time I used Linux : 15 years ago,
first time I used a PC : 18 years ago,
first time I wrote code, on a CASIO calculator : 20 years ago.

Remarque agnostique sur Linux en entreprise

Pour avoir travaillé dans de nombreuses sociétés, il me semble évident que Linux représente une menace. Notez que je ne dis pas que c’est le choix de Linux qui représente une menace, car Linux n’est pas un choix. Linux est imposé par le marché. De plus en plus d’outils utilisent Linux, y compris des sociétés très respectables et des éditeurs de logiciels métier. Ce qui représente une menace, c’est le manque de réaction managériale face à l’arrivée de Linux.

Deux menaces principales existent :

• Le scénario de ne pas savoir intervenir en cas de panne, par faute de formation.
• Le scénario d’avoir tellement de Linux différents que l’on ne sait plus comment les gérer et que l’on multiplie les coûts.

Ces remarques s’étendent à Linux, à Mac OSX, aux BSD et aux autres sortes d’Unix.

Ma recommandation

Tout d’abord, cesser le déni et reconnaître que Linux est utilisé au sein de l'entreprise. Ensuite, accorder un crédit de temps *qui peut être de l’autoformation* à un ou plusieurs administrateurs système, pour se former à Linux.

Enfin, faire un certain nombre de choix concernant Linux, visant à éviter le chaos de la muliplication. Par exemple, le choix d’une ou deux distributions « supportées » par le service informatique et l’achat d’une suite logicielle permettant l’intégration des machines Linux aux outils centraux, y compris outils Microsoft.

At the Heart of Security: Doing What You Say And Saying What You Do

Security is about deciding what's forbidden, what's allowed and enforcing these decisions.

There's the technical part, doing what you can to technically enforce the decisions.
And there's the human part, managing things in a way that reduces related uncertainties.

The human part is the most important. You cannot enforce every decision technically. Besides, you have to allow for people to switch on/off certain features, eg to allow for good functioning outside of the company's premises. So, you forcibly leave some room for employees to decide by themselves whether they respect the rules or not. And that's the moment when the human factor matters.

The most important tool for the human factor is the security policy. You have to say what you do in terms of security and to do precisely what you say.

If you don't do what you say, you invite people to force the system, they think they can fool you. It may go as far as disregarding completely the policy.
If you don't say what you do, you invite people to rebel and contest the security measures. Additionally, you scramble people's understanding of your security policies, which may lead them to give up trying to respect it.

Note on the Future of RSS Feeds

These days, I see a decline in the publication of RSS feeds. Either they're not present, not advertised much, or incomplete. This is especially true of mainstream, non-professional sites.

One of the reasons that might lead bloggers and webmasters to remove or neglect RSS feeds is that they provide no way to count followers (unique followers). A good evolution off RSS would be to allow a simple "declarative" download of RSS feeds.

• Authentication might be hard to obtain and maintain.
• Identified-only feeds might make users reluctant to use them.
• "Declaration" of an identifier of the follower is subject to many uncertainties, but could allow for a better count of unique users, returning users, etc.

Security ROFL 6

• 10 (or so) of the worst passwords exposed by the LinkedIn hack, like "ihatemyjob", "fuckmylife" or "123456" through Anton Chuvakin's G+.
• Using tax refunds to steal money from taxpayers ;-) Tax Return Identity Theft from Bruce Schneier's blog.
• Displaying password in the TV news is no good idea ;-) from the Front Line Sentinel blog.
• Movie Hacking vs Real Hacking, from the Saturday Morning Breakfast Cereal webcomics.
• Dilbert's use of users' private data :-D
• And finally the eternal lesson from the Demotivators : 

A l'attention des RSSI : Sur la fuite des mots de passe LinkedIn

Il y a quelques jours, une fuite massive de comptes et de mots de passe LinkedIn a été révélée sur Internet.

Je recommande aux RSSI de faire suivre le mot au sein de leur entreprise/administration.

En effet, comme le site LinkedIn utilise l'adresse e-mail des gens comme identifiant, la plupart des utilisateurs moyens utilisent pour ce site le même mot de passe que pour leur adresse e-mail. Ainsi, les adresses e-mail de ces utilisateurs deviennent des cibles, via les webmails.
De plus, les utilisateurs qui réutilisent leurs mots de passe risquent aussi de les réutiliser pour tous les autres sites dont l'identifiant est l'adresse e-mail. Ces autres sites sont donc menacés aussi.

Exemple : Un utilisateur lambda, Jean Dupont, travaille pour la société Youpeee. Son adresse e-mail est "jean.dupont@youpeee.fr". Son mot de passe est "kevin1502", le prénom de son fils et sa date d'anniversaire. Jean s'enregistre sur LinkedIn avec son adresse e-mail et, pour simplifier, le même mot de passe "kevin1502". Il fait de même sur Facebook. Il fait de même sur Amazon.
De plus, pour qu'il puisse télé-travailler, son entreprise met à disposition un site http://webmail.youpeee.fr où il peut consulter son courrier électronique.


Aujourd'hui son mot de passe LinkedIn fuite sur Internet. Résultat :

• Ses comptes Facebook et Amazon sont menacés.
• Son courrier électronique d'entreprise est menacé.
• Si l'entreprise Youpeee utilise d'autres moyens de télétravail, ils peuvent eux aussi être menacés.