Exostats/Exoscan |
Nombre de tests inclus
|
29036
|
|
Tests ajoutés |
Aujourd'hui |
Ce
mois |
7 |
26 |
|
|
[Infratech - vulnérabilité] Nouvelle version 0.8 de Bluetooth Stack Smasher
Par Pierre Betouin,
secuobs.com
Le 15/02/2006
Résumé : BSS (Bluetooth Stack Smasher) est un outil développé dans le but est d'effectuer différents tests sur les périphériques Bluetooth. BSS doit pouvoir effectuer ses tests de façon entièrement transparente. De nombreuses nouvelles options ont été ajoutées depuis la version 0.6. - Lire l'article
BSS v0.8 could be downloaded on lien ( sha1sum bss-0.8.tar.gz
6c5e028104c971e800424903581e246ffea3dfd2 )
Recently, Bluetooth security has become a new source of interest for many people involved in IT security. Although forsaken by now - in particular for short ranges reasons - Bluetooth security touches more and more people : almost every device manufactured nowadays has a native Bluetooth support : cellular phones, laptops, digital assistants, cameras...
Mobility evolution allows almost all users to get an instant connection wherever they want, whenever they require it, to check mails, chat, or link their devices together (headsets, GPS systems, and so on). This unquestionably creates new security threats. If security was still so obscure for many people few years ago, it should now be considered by everyone owning a wireless capable device (802.11, Bluetooth...).
Who wouldn't care about getting huge phone bills, revealing his address book or calendar to anyone, or being owned walking in the street or drinking a coffee in a pub ?
Trifinite group was the first to reveal Bluetooth attacks, such as BlueBug or BlueSnarf. This paper describes existing attacks, and introduces a new way to assess Bluetooth enabled devices using a low lever fuzzer. Security on such devices is indeed very difficult to estimate because of the use of proprietary technologies. Security analysis can be lead by using reverse engineering techniques (disassembly for instance) but fuzzing remains the quickest and easiest way to "stress" Bluetooth implementations.
Exhaustive analysis won't be realized using the fuzzer presented below : deeper studies would require a complete disassembly work but I have been really astonnished of the number of devices crashing or presenting irrational behaviours.
BSS (Bluetooth Stack Smasher) is a L2CAP layer fuzzer, distributed under GPL licence. Current version is 0.8.
Ollie Whitehouse gave us a huge help on new BSS releases. We plan to add together several new modes to BSS soon.
BSS requires the standard bluetooth library.
Performs several L2CAP checks sending malicious packets (L2CAP)
Initial source code analysis from tanya tool (tbear)
Example of use (short random L2CAP packets):
An example:
./bss -M 0 -m 13 -s 10 EF:F0:00:00:00:00
.
[*] bss: l2ping returned that the host is up!
[I] Potential crash detected for EF:F0:00:00:00:00, check l2ping response above
[I] ----------------------------------------------------
[I] Host EF:FF:00:00:00:00
[I] Packet size 0
[I] ----------------------------------------------------
[I] Replay buffer:
char replay_buggy_packet[]="";
[I]----------------------------------------------------
Now isolate the packet you think caused it, then if you had autogenerate test
case on (-o) do the following:
[1] If you generated the test case go into the 'replay_packet' dir
[2] locate the testcase file
[3] ./makereplay
i.e. ./makereplay replay_l2cap_packet_11022005101938.0
[4] ./replay
and try this packet against your equipment :
./replay 00:12:EE:XX:XX:XX
Core options
Bluetooth Stack Smasher - version 0.8
Usage: ./bss [-i iface] [-d delay] [-c] [-v] [-x] [-P0] [-q] [-o]
[-s size] [-m mode] [-p pad_byte] [-M maxcrash_count]
Extra options
There are a number of other options side of core set these are detailed below.
[-d delay] - Optional delay (miliseconds).
[-c] - Continue even on errors we would normally exit on (except malloc)
This overrides -x in most places
[-v] - Verbose debugging
[-x] - Exit on potential crashes that also don't respond to secondary l2ping's *
[-P0] - Do not perform L2CAP ping (some hosts don't respond to such packets
This overrides -x in most places
[-q] - Quiet mode - print minimal output
[-o] - Generate replay_packet.c automatically
[-s size] - L2CAP packet size (bytes)
[-M value] - Max crash count before exiting (Mode 13)
[-p value] - Padding value (modes 1-11)
[*] these can be considered verified crashes
Tips
Other examples using new options
[quite mode, generate testcase replay]
This will generate a replay template for each test case which it thinks caused
a crash while running in quiet mode.
./bss -q -o -M 0 -m 13 -s 10 00:11:22:XX:YY:ZZ
[*] silent mode: on
[*] automatic replay_packet.c generation: on
.!G.!G.!G.!G.!G.!G.!G.
[!] l2ping: Recv failed: Connection reset by peer
!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.!G.
[!] l2ping: Recv failed: Connection reset by peer
!G.!G.23 sent, 23 received, 0% loss
The output means:
. (test case sent)
! (we think we got a crash)
G (we generated a replay file in 'replay_packet/'
[quite mode, generate testcase replay only when host is down, exit when crash]
This will generate a replay template for each test case which it verifys causes
a crash while running in quiet mode. This will also exist once it's verified
the device has crashed.
./bss -x -q -o -M 0 -m 13 -s 10 DE:AD:BE:EF:00:00
[*] exit on no response to l2ping: on
[*] silent mode: on
[*] automatic replay_packet.c generation: on
.!.!.!.!.!.!.!.
[!] l2ping: Recv failed: Connection reset by peer
!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.!.
[!] l2ping: Recv failed: Connection reset by peer
!G
[ Available modes ]
0 ALL MODES LISTED BELOW
1 L2CAP_COMMAND_REJ
2 L2CAP_CONN_REQ
3 L2CAP_CONN_RSP
4 L2CAP_CONF_REQ
5 L2CAP_CONF_RSP
6 L2CAP_DISCONN_REQ
7 L2CAP_DISCONN_RSP
8 L2CAP_ECHO_REQ
9 L2CAP_ECHO_RSP
10 L2CAP_INFO_REQ
11 L2CAP_INFO_RSP
12 L2CAP full header fuzzing
13 L2CAP Random Fuzzing
[generate testcase]
This will generate a test case .c file for everyone it suspects
./bss -o -M 0 -m 13 -s 10 CA:FE:BE:EF:00:00
[*] automatic replay_packet.c generation: on
.
[*] bss: l2ping returned that the host is up!
[I] Potential crash detected for CA:FE:BE:EF:00:00, check l2ping response above
[I] ----------------------------------------------------
[I] Host CA:EF:BE:EF:00:00
[I] Packet size 0
[I] ----------------------------------------------------
[I] Replay buffer:
char replay_buggy_packet[]="";
[I]----------------------------------------------------
[d] generated ok!
Author Website on lien
Autres ressources sur la sécurité Bluetooth :
[Dossier Sécurité Bluetooth - partie 1] Introduction aux technologies Bluetooth lien
[Dossier Sécurité Bluetooth - partie 2] Présentation des utilitaires Bluetooth lien
[Dossier Sécurité Bluetooth - partie 3] Les attaques génériques lien
[Dossier Sécurité Bluetooth - partie 4] Les attaques d'implémentations lien
[Dossier Sécurité Bluetooth - partie 5] Scénarios possibles & synthèse lien
[Infratech - vulnérabilité] PoC pour le DoS sur les téléphones portables Sony/Ericsson lien
[Infratech - vulnérabilité] Déni de Service sur les téléphones mobiles Sony/Ericsson lien
[Infratech - vulnérabilité] PoC pour le DoS sur hcidump lien
[Infratech - vulnérabilité] Déni de Service sur hcidump lien
[Infratech - vulnérabilité] Déni de Service sur Nokia N70 lien
[Infratech - vulnérabilité] Deuxième type de Déni de Service sur Nokia N70 lien
- Article suivant : Un environnement de recherche de failles par SQL Injection
- Article précédent : [Infratech - vulnérabilité] Un Deuxième type de Déni de Service sur NOKIA N70
- Article suivant dans la catégorie Failles : Compromission de la confidentialité des échanges Skype ?
- Article précédent dans la catégorie Failles : [Infratech - vulnérabilité] Un Deuxième type de Déni de Service sur NOKIA N70
| Mini-Tagwall des articles publiés sur SecuObs : | | | | sécurité, windows, exploit, microsoft, réseau, attaque, vulnérabilité, système, audit, outil, virus, internet, données, linux, présentation, bluetooth, vista, metasploit, protocol, shell, scanner, réseaux, trames, téléphone, paquet, wishmaster, rootkit, engineering, sysun, https, black, mobile, noyau, téléphones, conférence, mémoire, source, scapy, google, reverse, détection, malveillant, snort, sécurise, patch |
| Mini-Tagwall de l'annuaire video : | | | | virus, spyware, vmware, firmware, security, malware, lockpicking, biometric, kernel, iphone, windows, adware, password, wimax, botnet, tutorial, phish, linux, symantec, rootkit, knoppix, metasploit, network, attack, server, virtual, internet, jailbreak, notacon, conference, exploit, google, wireshark, defcon, hacker, backtrack, openbsd, intel, ettercap, firewall, source, samsung, reprap, wireless, norton |
| Mini-Tagwall des articles de la revue de presse : | | | | security, microsoft, vulnérabilité, windows, vulnerability, network, attack, google, hacker, exploit, inject, internet, remote, server, mobile, malware, apple, iphone, black, patch, sécurité, virus, linux, ebook, conficker, crypt, source, intel, virtual, facebook, access, trojan, twitter, research, firefox, overflow, pirate, phish, vista, cisco, obama, office, local, opera, adobe |
| Mini-Tagwall des Tweets de la revue Twitter : | | | | security, cisco, linux, defcon, firewall, vmware, metasploit, attack, server, phish, network, twitter, exploit, windows, nessus, botnet, inject, backtrack, crypt, wireshark, vulnerabi, python, black, acking, iphone, source, engineering, google, social, conficker, clouds, patch, pentest, podcast, vulnerability, juniper, virus, hacker, apple, client, proxy, apache, virtual, complianc, javascript |
Poster un commentaire sur cet article:
|
|
|
|
|
