Shared posts

21 Oct 18:22

Dyn issues affecting joint customers

by Filippo Valsorda

Today there is an ongoing, large scale Denial-of-Service attack directed against Dyn DNS. While Cloudflare services are operating normally, if you are using both Cloudflare and Dyn services, your website may be affected.

Specifically, if you are using CNAME records which point to a zone hosted on Dyn, our DNS queries directed to Dyn might fail making your website unavailable, and presenting a “1001” error message.

Some popular services that might rely on Dyn for part of their operations include GitHub Pages, Heroku, Shopify and AWS.

1001 error

As a possible workaround, you might be able to update your Cloudflare DNS records from CNAMEs (referring to Dyn hosted records) to A/AAAA records specifying the origin IP of your website. This will allow Cloudflare to reach your origin without the need for an external DNS lookup.

Note that if you use different origin IP addresses, for example based on the geographical location, you may lose some of that functionality by using plain A/AAAA records. We recommend that you provide addresses for many of your different locations, so that load will be shared amongst them.

Customers with a CNAME setup (which means Cloudflare is not configured in your domain NS records) where the main zone is hosted on a Dyn service will be affected as well. You might be able to make Cloudflare your authoritative DNS provider by contacting support and asking to be changed to Full mode and then updating your nameservers at your registrar, but the change can take up to 48h to propagate.

Please note that the Cloudflare status page and support system might be affected by the ongoing attack, since they are hosted on third parties, as per industry best practices.

06 Oct 08:29

TCP joke

29 Sep 06:01

SNMP Pwn3ge, (Wed, Sep 28th)

Sometimes getting access to company assets is very complicated. Sometimes it is much easier (read: too easy) than expected. If one of the goals of a pentester is to get juicy information about the target, preventing the IT infrastructure to run efficiently (deny of service) is also a win. Indeed, in some business fields, if the infrastructure is not running, the business is impacted and the company may lose a lot of money. Think about traders.

I was recently involved in a pentest with the goal to test the customers internal network. The scope was easy: to come on site,connect your laptop to a free network port and see what you can find/do. In such scenario, the breaking point is to successfully be connected to the network. If Mr DHCP is kind enough to provide you an IP address, you are in and you may consider the network as already compromised. This was the case for me, no protection against rogue devices, no network access control. I launched my Ettercap and started to sniff some packets playing MitM. I immediately grabbed some nice SNMP packets with interesting communities like public and private. As you probably know, those are the default ones on many systems. public provides usually a read-only access and private is used in read-write mode. Often, I hear this comment: But SNMP is just a monitoring protocol, why should I care?. Wrong! SNMP, as described by RFC 3411[1], meansSimple Network Management Protocol and not Monitoring Protocol. If you have SNMP read access to a device, you can collect interesting information (version, processes, IP information, health) for the reconnaissance phase. But if you have SNMP write access to a device, you can alter his configuration and cause much more damages

During"> # nmap -Pn -sU -p 161 -v -oA snmp grep 161/open/udp snmp.gnmap | awk { print $2 } | while read IPdo snmpwalk -v1 -c private $IP /dev/null 21 if [ $? == 0 then echo $IP accepts private community echo $IP vulnerable_ip.tmp fidone

The next step was to identify the vulnerable devices. This information is discoverable with the OID"> # snmpwalk -v1 -On -c xxxxxxxxx SNMPv2-MIB::sysDescr. = STRING: Cisco IOS Software, C1600 Software (AP1G2-K9W7-M), Version 15.2(2)JB2, RELEASE SOFTWARE (fc1)

Guess what? Most vulnerable devices were UPS management systems configured with default settings or, more precisely, not configured at all. The next step was to browse the vendor MIB (Management Information Base). The vendor ID was534 and is assigned to Eaton Corporation [2]. The MIB reveals someinteresting read/write OIDs like this one: This OID is called xupsControlOutputOffDelay. Here is the description:

Setting this value to other than zero will cause the UPS output to turn off after the number of seconds. Setting it to 0 will cause an attempt to abort a pending shutdown.

We are close to perform a nice DoS against the customers infrastructure. How? A simple snmpset command will help us. Let"> for IP in cat vulnerable_ip.tmpdo snmpset -c private -v1 $IP i 10 echo -n $IP d=10 do echo -n . done echo Tango down!done

Game over! Note that this is a proof of concept. In most pentestengagements, youre not allowed to perform such actions.

It is a pity that such very simple attack is still possible in 2016! If the customer followed the SANS Top-20 controls[3], this attack wouldnt be possible:

  • CSC1 -Inventory of authorized and unauthorized devices
  • CSC4 -Continuous vulnerability scanning, assessment, and remediation
  • CSC9 -Limitation and control of network ports, protocols, and services
  • CSC11 -Secure configuration for network devices such as firewalls, routers, and switches


Xavier Mertens (@xme)
ISC Handler - Freelance Security Consultant

(c) SANS Internet Storm Center. Creative Commons Attribution-Noncommercial 3.0 United States License.
28 Sep 07:39

In the Robot Skies : un film entièrement tourné par des drones autonomes

by Julien Lausson


Le film In the Robot Skies ne se contente pas de raconter une histoire où les drones tiennent une place importante. Il a aussi été tourné en utilisant des drones autonomes. [Lire la suite]
20 Sep 04:10

Watch Chinese Hackers Control Tesla's Brakes From 12 Miles Away

by Thomas Fox-Brewster
First ever remote Tesla hack sees brakes killed and the boot opened mid-drive, Tencent security researchers claim.
17 Sep 10:38

Equation Group était capable d’extraire les clés VPN des pare-feu Cisco PIX

by UnderNews
Les documents de la récente fuite ayant touché le groupe de pirates Equation Group ont pu être rapproché à ceux des révélations d'Edward Snowden. Une faille dans les pare-feu Cisco permettait à la NSA de s'emparer des clés VPN et de déchiffrer jusqu'à un millier de connexion VPN à l'heure.
02 Sep 09:45

Outsourcing en baisse sur fond de percée IaaS/SaaS en EMEA

by Maryse Gros
Pour le 2ème trimestre 2016, l’index ISG portant sur les contrats d’externalisation ayant une valeur annuelle supérieure à (...)
27 Jun 07:56

Les données de 112.000 policiers français et de leurs proches dans la nature

C'est la base de données de la Mutuelle Générale de la Police qui a été compromise. Mais il ne s'agirait pas d'une attaque, plutôt d'une vengeance.
13 Jun 10:10

Symantec rachète Blue Coat pour 4,65 Md$

by Maryse Gros avec IDG News Service
L’éditeur de solutions de sécurité Symantec rachète Blue Coat, spécialisé dans la cybersécurité, (...)
17 May 18:44

Dépitée, la Quadrature du Net ne se battra plus frontalement contre les lois

by Guillaume Champeau

Adrienne Charmet-Alix, directrice des campagnes de la Quadrature du Net.

Signe supplémentaire que les institutions dites « démocratiques » peinent de plus en plus à convaincre de leur efficacité démocratique, la Quadrature du Net explique mardi qu'elle est fatiguée de se battre sur les terrains parlementaires, et préfère réorienter son action au plus près du public. [Lire la suite]
10 May 08:17

Cisco : faille critique dans ses systèmes de téléprésence

La vulnérabilité, corrigée, permet une prise de contrôle à distance des équipements. Cisco annonce également d'autres patchs.
26 Apr 12:27

RuMMS: The Latest Family of Android Malware Attacking Users in Russia Via SMS Phishing

by Wu Zhou

Recently we observed an Android malware family being used to attack users in Russia. The malware samples were mainly distributed through a series of malicious subdomains registered under a legitimate domain belonging to a well-known shared hosting service provider in Russia. Because all the URLs used in this campaign have the form of hxxp://yyyyyyyy[.] (where represents the hosting provider’s domain), we named this malware family RuMMS.

To lure the victims to download the malware, threat actors use SMS phishing – sending a short SMS message containing a malicious URL to the potential victims. Unwary users who click the seemingly innocuous link will have their device infected with RuMMS malware. Figure 1 describes this infection process and the main behaviors of RuMMS.

Figure 1. Overview of the RuMMS campaign and behaviors

On April 3, 2016, we still observed new RuMMS samples emerging in the wild. The earliest identified sample, however, can be traced back to Jan. 18, 2016. Within this time period, we identified close to 300 samples belonging to this family (all sample hashes are listed in the Appendix).

After landing on the victim’s phone, the RuMMS apps will request device administrator privileges, remove their icons to hide themselves from users, and remain running in the background to perform a series of malicious behaviors. So far we have identified the following behaviors:

●      Sending device information to a remote command and control (C2) server.

●      Contacting the C2 server for instructions.

  • Sending SMS messages to financial institutions to query account balances.
  • Uploading any incoming SMS messages (including the balance inquiry results) to the remote C2 server.
  • Sending C2-specified SMS messages to phone numbers in the victim’s contacts.
  • Forward incoming phone calls to intercept voice-based two-factor authentication.

Each of these behaviors is under the control of the remote C2 server. In other words, the C2 server can specify the message contents to be sent, the time period in which to forward the voice call, and the recipients of outgoing messages. As part of our investigation into this malware, we emulated an infected Android device in order to communicate with the RuMMS C2 server. During one session, the C2 server commanded our emulated device to send four different SMS messages to four different phone numbers, all of which were associated with Russian financial institutions. At least three of the messages were intended to check a user’s account balance at the institution (we could not confirm the purpose of the fourth).Through additional research, we identified several forum posts where victims complained of funds (up to 600 rubles) were transferred out of their accounts after RuMMS infected their phones.

We do not know exactly how many people have been infected with RuMMS malware. However, our data suggests that there have been at least 2,729 infections between January 2016 and early April 2016, with a peak in March of more than 1,100 infections.

Smishing: The Major Way To Distribute RuMMS

We have not observed any instances of RuMMS on Google Play or other online app stores. Smishing (SMS phishing) is currently the primary way threat actors are distributing the malware. The process starts when an SMS phishing message arrives at a user’s phone. An example SMS message is shown in Figure 1. The message translates roughly to“ You got a photo in MMS format: hxxp://”

So far we identified seven different URLs being used to spread RuMMS in the wild. All of the URLs reference the file “mms.apk” and all use the domain “”, which belongs to a top five shared hosting platform in Russia (the domain itself has been obfuscated to anonymize the provider).

The threat actors registered at least seven subdomains through the hosting provider, each consisting of eight random-looking characters (asdfgjcr, cacama18, cacamadf, konkonq2, mmsmtsh5, riveroer, and sdfkjhl2.) As of this writing, no files were hosted at any of the links. The threat actors seem to have abandoned these URLs and might be looking into other ways to reach more victims.

Use of a shared hosting service to distribute malware is highly flexible and low cost for the threat actors. It is also much harder for network defenders or researchers to track a campaign where the infrastructure is a moving target. Many top providers in Russia offer cheap prices for their shared hosting services, and some even provide free 30-day trial periods. Threat actors can register subdomains through the hosting provider and use the provider’s services for a short-period campaign. A few days later they can cancel the trial and do not need to pay a penny. In addition, these out-of-the-box hosting services usually provide better infrastructure than the attackers could manage to construct (or compromise) themselves.

RuMMS Code Analysis

All RuMMS samples share the same behaviors, major parts of which are shown in Figure 1. However, the underlying code can be quite different in that various obfuscation mechanisms were adopted to evade detection by anti-virus tools. We used a sample app named “org.starsizew” with an MD5 of d8caad151e07025fdbf5f3c26e3ceaff to analyze RuMMS’s code.

Several of the main components of RuMMS are shown in Figure 2. The activity class “org.starsizew.MainActivity” executes when the app is started. It first starts another activity defined in “org.starsizew.Aa” to request device administrator privileges, and then calls the following API of “” (the Android package manager to remove its own icon on the home screen in order to conceal the existence of RuMMS from the user:

            setComponentEnabledSetting(MainActivity.class, 2, 1)

At the same time, ”org.starsizew.MainActivity” will start the main service as defined in “org.starsizew.Tb”, and use a few mechanisms to keep the main service running continuously in the background. The class “org.starsizew.Ac” is designed for this purpose; its only task is to check if the main service is running, and restart the main service if the answer is no. The class “org.starsizew.Tb” also has a self-monitoring mechanism to restart itself when its own onDestroy API is triggered. Other than that, its major functionality is to collect private device information, upload it to a remote C2 server, and handle any commands as requested by the C2 server. All those functions are implemented in asynchronous tasks by “org.starsizew.i”.

Figure 2. Android Manifest File of RuMMS

The class “org.starsizew.Ma” is registered to intercept incoming SMS messages, the arrival of which will trigger the Android system to call its “onReceive” API. Its major functionality is also implemented through the call of the asynchronous task (“org.starsizew.i”), including uploading the incoming SMS messages to the remote C2 server and executing any commands as instructed by the remote attacker.

C2 Communication

The C2 communication includes two parts: sending information to the remote HTTP server and parsing the server’s response to execute any commands as instructed by the remote attackers. The functionality for these two parts is implemented by doInBackground and onPostExecute respectively, two API methods of “android.os.AsyncTask” as extended by class “org.starsizew.i”.

Figure 3. Method doInBackground: to send information to remote C2 server

As seen from the major code body of method doInBackground shown in Figure 3 (some of the original classes and methods are renamed for easier understanding), there are three calls to HttpPost with different contents as parameters. At line 5, local variable v4 specifies the first parameter url, which can be changed by the remote C2 server later. These URLs are all in the form of “http://$C2.$SERVER.$IP/api/?id=$NUM”. The second parameter is a constant string “POST”, and the third parameter is a series of key-value pairs to be sent, assembled at runtime. The value of the first item, whose key is “method” (line 7), indicates the type of the contents: install, info and sms.

The first type of content, starting with “method=install”, will be sent when the app is started for the first time, including the following device private information:

  • Victim identifier
  • Network operator
  • Device model
  • Device OS version
  • Phone number
  • Device identifier
  • App version
  • Country

Figure 4 is an example of this string as seen by the FireEye Mobile Threat Prevention platform.

Figure 4. Example HTTP post message

The second type of information will be sent periodically to indicate that the device is alive. It only has two parts, the method indicated by word “info” and the victim identifier. The third type of information will be sent when RuMMS intercepts any SMS messages, including the balance inquiry results when it contacts the SMS code of a particular financial service.

Method onPostExecute parses the response from the above HTTP session and executes the commands provided by the remote attacker. As seen from the code in Figure 5, the commands RuMMS supports right now include:

  • install_true: to modify app preference to indicate that the C2 server received the victim device’s status.
  • sms_send: to send C2-specified SMS messages to C2-specified recipients.
  • sms_grab: to upload periodically the SMS messages in the inbox to C2 server.
  • delivery: to deliver specified text to all victim’s contacts (SMS worming).
  • call_number: to forward phone calls to intercept voice based two-factor authentication.
  • new_url: to change the URL of the C2 server in the app preference.
  • ussd: to call a C2-specified phone number.

Figure 5. Method onPostExecute: to handle instructions from remote C2

Figure 6 shows an example response sent back from one C2 server. Note that inside this single response, there is one “install_true” command, one “sms_grab” command and four “sms_send” commands. With the four “sms_send” commands, the messages as specified in the key “text” will be sent immediately to the specified short numbers. Our analysis suggests that the four short numbers are associated with Russian financial institutions, presumably where a victim would be likely to have accounts.

Figure 6. Example Response in JSON format

In particular, short number “+7494” is associated with a payment service provider in Russia. The provider’s website described how the code 7494 can be used to provide a series of payment-related capabilities. For example, sending text “Balance” will trigger a response with the victim’s wallet balance. Sending text “confirm 1” will include proof of payment. Sending text “call on” will activate the USSD payment confirmation service.

During our investigation, we observed the C2 server sending multiple “balance” commands to different institutions, presumably to query the victim’s financial account balances. RuMMS can upload responses to the balance inquiries (received via SMS message) to the remote C2 server, which can send back additional commands to be sent from the victim to the provider’s payment service. These could include resetting the user’s PIN, enabling or disabling various alerts and confirmations, and confirming the user’s identity.

RuMMS Samples, C2, Hosting Sites, Infections and Timeline

In total we captured 297 RuMMS samples, all of which attempt to contact an initial C2 server that we extracted from the app package. Figure 7 lists the IP addresses of these C2 servers, the number of RuMMS apps that connect to each of them, and the example URL used as the first parameter of the HttpPost operation (used in the code of Figure 3). This indicates that multiple C2 servers were used in this campaign, but one ( was the most heavily used.

Figure 7. RuMMS samples and C2 servers

Figure 8 shows how these samples, C2 servers and hosting websites are related to each other, including when they were compiled or observed. In the quadrant, the smaller boxes in blue-gray represent particular apps in the RuMMS family, while the bigger boxes in deep-blue represent C2 servers used by some RuMMS apps. The dotted arrows represent the use of a particular C2 server by a specific app to send information and fetch instructions. In this figure we have 11 RuMMS samples, all of which were hosted on the website as shown in the “y” axis. The dates on the “x” axis show the dates when we first saw these apps in the wild. This figure demonstrates the following interesting information:

The time range when threat actors distributed RuMMS on those shared-hosting websites is from January 2016 to March 2016.

  • Threat actors used different websites to host different payloads at different times. This kind of “moving target” behavior made it harder to track their actions.
  • The same websites have hosted different RuMMS samples at different dates.
  • C2 servers are shared by multiple samples. This matches our observations of C2 servers as shown in Figure 7.

Figure 8. RuMMS samples, hosting sites, C2 servers from Jan. 2016 to Mar. 2016

We do not know exactly how many people have been infected with RuMMS malware; however, our data suggests that there are at least 2,729 infections with RuMMS samples from January 2016 to early April 2016.

Figure 9 shows the number of RuMMS infections recorded in the last four months. When we first observed the malware in January, we recorded 380 infections. In February, we recorded 767 infections. In March, it peaked at 1,169 infections. In April, at the time of writing this post, we recorded 413 RuMMS infections. Although the propagation trend seems to be slowing down a bit, the figure tells us that RuMMS malware is still alive in the wild. We continue to monitor its progress.


Figure 9. RuMMS infections from Jan. 2016 to Apr. 15, 2016


Smishing (SMS phishing) offers a unique vector to infect mobile users. The recent RuMMS campaign shows that Smishing is still a popular means for threat actors to distribute their malware. In addition, the use of shared-hosting providers adds flexibility to the threat actor’s campaign and makes it harder for defending parties to track these moving targets.

Fortunately, FireEye Mobile Threat Prevention platform can recognize the malicious SMS and networking behaviors used by these RuMMS samples, and help us quickly identify the threat. To protect yourself from these threats, FireEye suggests that users:

  • Take caution before clicking any links where you are not sure about the origin.
  • Don’t install apps outside the official app store.

To detect and defend against such attacks, we advise our customers to deploy our mobile security solution, FireEye MTP/MSM. This helps our clients gain visibility into threats in their user base, and also enables them to proactively hunt down devices that have been compromised. In addition, we advise our customers with NX appliances to ensure that Wi-Fi traffic is scanned by NX appliances to extend coverage to mobile devices.

Appendix: RuMMS Sample Hashes












































































































































































































































































































18 Mar 23:00

Connaissance du 19/03/2016

La "parabole des talents" est un chapitre de l'Evangile selon Saint Matthieu. Celui-ci incite à faire des placements financiers et explique les bases du capitalisme actuel (on prend aux pauvres pour donner à celui qui a déjà beaucoup).
26 Nov 09:00

GhostSec pirate l'État islamique avec du prozac

GhostsSec, un groupe souvent associé à Anonymous, vient de frapper fort en piratant un des sites de l’État islamique sur le réseau Tor et en remplaçant la page d’accueil par une publicité pour une pharmacie en ligne...

17 Nov 17:04

ProtonMail, le Webmail anti-NSA, s'est relevé de la "plus grande cyber-attaque de Suisse"

Le service d'e-mail hyper-sécurisé suisse ProtonMail a subi une attaque DDoS d'une ampleur inégalée en Suisse. Indisponible 5 jours, il est parvenu à se relever mais l'attaque continue. Prot [...]

06 Nov 23:01

Connaissance du 07/11/2015

Lors des Jeux Olympiques d'été de Paris en 1900, les épreuves de natation se déroulaient dans la Seine.
07 Nov 22:56

Connaissance du 08/11/2015

L'actuel drapeau américain a été créé en 1958 par un étudiant de 17 ans dans le cadre d'un projet scolaire; il obtenu un B-. Le drapeau fut accepté par le Congrès Américain, son professeur changea sa note en A.
05 Oct 20:35

If anyone is wondering!

21 Sep 08:40

For the fans of Batman

03 Sep 11:59

Renseignement : la Quadrature et la FFDN multiplient les recours et visent l'international

La Quadrature du net et la Federation French Data Network ont fait le point sur les multiples recours déposés en justice afin de s’attaquer à l’édifice législatif encadrant la surveillance et le contrôle d’Internet en France.
11 Aug 09:47

Il n’est désormais plus possible de se rétracter avant la livraison d’un bien acheté en ligne


Depuis l’entrée en vigueur de la loi Macron, les consommateurs ayant acheté un bien sur Internet ne peuvent plus exercer leur droit de rétractation avant que celui-ci leur soit livré. Une évolution jugée guère favorable aux consommateurs, dans la mesure où les frais de retour (à la charge du client insatisfait) sont habituellement une forte barrière psychologique et financière.

07 Aug 06:35

Great idea to take with when camping

05 Aug 03:20

The comparison

05 Aug 20:10

Alexei Ananenko, Boris Baranov and Valeri Bezpalov. They are not anonymous, and they shouldn't be.

19 Jul 22:21

Uggy : Cas debug DNS

by Uggy

Je suis tombé sur un petit problème DNS interressant...
Le voici dans l'ordre...

- Je clic sur un lien et me voila envoyé vers un article du site
- Patatra, marche pas.
- Vérification DNS:

$ dig

; > DiG 9.9.5-9+deb8u1-Debian >
;; global options: +cmd
;; Got answer:
;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
; IN A

;; Query time: 448 msec
;; WHEN: Wed Jul 15 21:36:55 CEST 2015
;; MSG SIZE rcvd: 46


Marche pas, status: SERVFAIL

- Interressant

$ dig cname 86400 IN CNAME

Bon cette 1ère partie fonctionne.

- Essayons de voir ce que donne

$ dig

; > DiG 9.9.5-9+deb8u1-Debian >
;; global options: +cmd
;; Got answer:
;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
; IN A

;; Query time: 25 msec
;; WHEN: Wed Jul 15 21:39:41 CEST 2015
;; MSG SIZE rcvd: 59

Donc c'est lui qui ne résoud pas chez moi... status: SERVFAIL...

- Voyons voir les DNS de ou plutôt ceux de

$ dig ns +short

- Testons les en direct

$ dig +short
$ dig +short
$ dig +short

Arf çà répond.
Alors que cela ne répond toujours pas avec mon serveur local:

$ dig

; > DiG 9.9.5-9+deb8u1-Debian >
;; global options: +cmd
;; Got answer:
;; ->>HEADER ;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

; EDNS: version: 0, flags:; udp: 4096
; IN A

;; Query time: 44 msec
;; WHEN: Wed Jul 15 21:44:22 CEST 2015
;; MSG SIZE rcvd: 59

- Comme vous l'avez remarqué, j'interroge mon serveur récursif local.

Quand la demande passe par lui, cela ne fonctionne pas, sinon cela semble fonctionner.

$ dig @ +short

- Mon serveur DNS local est Unbound, et il semble qu'un truc le dérange (uniquement avec ces serveurs DNS !)...

- Activation des logs verbeux par la ligne

verbosity: 3

- Et on regarde les logs:

1436989983] unbound[12494:1] info: reply from
1436989983] unbound[12494:1] info: Capsforid fallback: getting different replies, failed
1436989983] unbound[12494:1] debug: return error response SERVFAIL

- Capsforid... Interressant

- Allons voir la doc de la conf d'Unbound

use-caps-for-id: Use 0x20-encoded random bits in the query to foil spoof
attempts. This perturbs the lowercase and uppercase of query
names sent to authority servers and checks if the reply still
has the correct casing. Disabled by default. This feature is
an experimental implementation of draft dns-0x20.

Donc en gros, avec ce paramètre à "yes", unbound envoit le nom à résoudre avec des minuscule/majuscule aléatoires, puis vérifie que la réponse à la question, qui contient la question, à bien les minuscules/majuscules aux bons endroits.

Et ce paramètre est a "yes" dans ma conf Unbound.

- Avant d'aller voir le draft dns-0x20, on lance wireshark



On voit clairement ce qui se passe, la réponse contient la question en minuscule, donc pas exactement comme elle a été posée.

- Vérifions avec un autre domaine.. Au hasard

$ dig +short

Mon unbound résoud parfaitement.

On voit bien que la réponse, contient bien cette fois exactement la question, avec les minuscules/majuscules aux bons endroits.


- Vérifions en mettant à "no" le use-caps-for-id (ce qui, il est vrai, est la valeur par défaut)

Bingo, çà fonctionne cette fois

$ dig +short

Unbound considère maintenant comme valide la réponse des serveurs de
Victoire, je peux lire mon article sur

- C'est quoi, ils auraient leur propre serveur DNS maison ?

"We’re dedicated to building a faster web for everyone in the world. Cedexis optimizes web performance across data centers, content delivery networks (CDNs) and clouds..."

Ah oui, çà colle, ils seraient bien capable d'avoir leur implémentation DNS maison.

- Maintenant allons voir ce fameux draft dns-0x20.

Déjà on peut noter que c'est rédigé par Paul Vixie de l'ISC, c'est du sérieux.

Je vais vous résumer en gros:

Le protocole DNS est tel, qu'il y a parfois moyen de réussir à forger des réponses et donc de poluer les caches DNS.
Il est donc ensuite possible de rediriger les users vers des faux site web.. bref pas cool.. mais rien de nouveau pour l'instant.
Mais tout moyen permettant d'améliorer la sécurité, en rendant plus difficile de forger des fausses réponses, sans tout casser au protocole existant, est donc la bienvenue.
Ce draft expose un moyen d'y parvenir.

Comme vous l'avez compris (pour les 3 personnes qui sont arrivées jusqu'ici, chapeau bas), il s'agit de mettre des majuscules/minuscules aléatoires dans la question envoyée au serveur DNS, puis considérer comme invalides, les réponses qui ne reprendaient pas la question en respectant la casse.

Pour forger une fausse réponse DNS et donc polluer le cache, il faudrait donc non seulement trouver le bon ID (Kaminsky, Paradoxe des anniversaires etc..) mais donc en plus avoir les bonnes majuscules/minuscules aux bons endroits. (Pas con le Paul Vixie ! )

Mais pour que l'idée soit exploitable, il faut donc voir ce que dit la RFC 1035 et voir comment réagissent les principales implémentations de serveurs DNS authoritatives.

Pour ce qui est de la RFC1035 on peut lire en 7.3

that the question section corresponds to the information currently desired

Mmmm...Ce n'est pas super précis ... Est-ce que cela inclu le respect de la casse... ?

Voyons voir les différentes implémentations:

On peut lire en 6.1

Several popular authoritative DNS implementations including ISC BIND (versions 4, 8, and 9), Nominum ANS, Akamai AKADNS, Neustar UltraDNS, Verisign Atlas, NLNetLabs NSD, PowerDNS, and DJBDNS were tested. All copied the question name exactly, bit for bit, from the request into the response.

Et en 6.2

Operational testing has revealed a small set of rare and/or private label authoritative DNS implementations who modify the 0x20 bits in question names while copying the question section from the request to the response. Usually this modification is to set the 0x20 bit, thus converting a domain name to be all-lower-case (0x61..0x7A, e.g., a-z).

- Conclusion:

Toutes les implémentations de serveur DNS authoritative majeures répondent en respectant la casse de la question.
Si les serveurs récursifs pouvaient implémenter cette vérification, ceci pourrrait améliorer la sécurité du DNS.
Et c'est d'ailleurs la 1ère fois que j'ai ce problème avec un serveur DNS, je vais donc garder mon paramêtre, et tant pis pour le site web du Parisien ;)

Les serveurs DNS de ne semblent pas tourner sous une "popular authoritative DNS implementations" :)
Je les ai contacté pour les informer.... si çà les interresse...

Gravatar de Uggy
Original post of Uggy.Votez pour ce billet sur Planet Libre.

Articles similaires

02 Jul 08:10

World, if it was scaled down to only 100 people.

17 Jun 00:00


[10 years later] Man, why are people so comfortable handing Google and Facebook control over our nuclear weapons?
08 Jun 01:25

Change the way you think...

24 Oct 08:35

Long exposure+ low iso level + DSLR+ luck = Real photograph

17 Sep 22:07

Connaissance du 18/09/2014

La "Rainbow valley" ou "Vallée Arc-en Ciel" est une zone du Mont Everest traversée par les alpinistes pour atteindre le sommet. Elle se nomme ainsi en raison des combinaisons multicolores portées par les cadavres qui jonchent le long du chemin.