From: Hacker F. <hac...@go...> - 2014-02-07 13:12:34
|
Hi all, My first attempt to send this email didn't appear to succeed so I am re-sending without attachment. Here is a copy of some slides https://github.com/HackerFantastic/Public/blob/master/presentations/mwri_labs-GSM-Hacking-Wireless-Mobile-Phone-Communication_2014-01-30.pdfI wrote for a presentation on security weaknesses within GSM. I used an Ettus E100 to develop a malicious BTS and GSM related attacks in a Faraday cage and presented on how these attacks work to better understand them for defensive purposes. I was able to use the E100 as a generic IP-router after I cross-compiled a new kernel with netfilter enabled and also I had to recompile a number of the packages such as Asterisk to enable ODBC and improved SQLite support, I also had to make some changes to Python and its modules. I used GNURadio 3.6.4 and I had to compile a specific version of the OpenBTS code as the recent transceiver application did not function with the E100. I was able to get the E100 to work as a GSM/GPRS router and do real-time call placement etc. I got it to function with real-time support and wrote a small script to provision new devices by watching the syslog and adding to the SQLite database. I also used osmocom-bb to do things like use gnuplot and graph the channel usage although the code is extremely ugly! I took RSSI measurements over a period of time into images and then tied them together for a movie, it isn't quite realtime but it makes pretty graphs. I mentioned how you could implement the MS side of the GSM stack using the osmocom project and as such am sharing the slides with the osmocom list. Just goes to show how mighty things come in small packages! Hope this material is useful to others on the list who may also be trying similar experiments. I ended up creating a firmware image that could be used to dd and boot an E100 but at this time I do not plan on hosting it for download unless there is sufficient interest. If you need it for some reason drop me an e-mail. Here is an example of the output of the greedyBTS script. As an example my code plays "Rick Astley - never going to give you up" when a user places a phone call and they have been provisioned with service. All of this work was done in a faraday cage which I obtained from Ramsey electronics which had very good frequency attenuation graph from 0mhz all the way to 1ghz. root@usrp-e1xx:~# ./launch.sh Launching asterisk Launching HLR SMS Launching OpenBTS Launching Greedy BTS.. 888 888 d8 e88 888 888,8, ,e e, ,e e, e88 888 Y8b Y888P 888 88e d88 dP"Y d888 888 888 " d88 88b d88 88b d888 888 Y8b Y8P 888 888b d88888 C88b Y888 888 888 888 , 888 , Y888 888 Y8b Y 888 888P 888 Y88D "88 888 888 "YeeP" "YeeP" "88 888 888 888 88" 888 d,dP , 88P 888 pDK++ "8",P" 888 [+] Current CELL configuration [-] ========================== [-] Shortname: 'Noone' [-] MCC: 901 MNC: 70 C0 ARFCN: 51 [-] LAC: 3336 ARFCN's: 1 BAND: 900 [-] [-] Radio Power [-] =========== [-] RxGain: 47 MaxPower: 10 MinPower: 0 --> help [+] HELP SCREEN [-] dump imei - lists all identified IMEI [-] dump assoc - lists all IMEI+IMSI associations [-] dump imsi - lists all identified IMSI [-] dump save - store a record of all identities [-] start service - provide service to IMSI & log traffic [-] show service - show all provisioned phones [-] stop service - deletes an identified IMSI from HLR [-] calls - provide call collection statistics [-] sms - provide sms collection statistics [!] gprs - provide gprs collection statistics [-] cellconfig - configure cell parameters for spoofing [-] cellinfo - dump information on current cell [-] cellshow - list short codes for common cells [!] sounddial - play a sound recording to an IMSI [!] spoofsms - send a spoof SMS message to an IMSI [!] trunksetup - display current SIP trunk details [-] verbose - turn on real time tracing [-] exit - leave without shutdown [-] shutdown - bye! --> dump imei [+] Dumping seen handset IMEI [-] 1: IMEI359209002648230 [-] 2: IMEI358622002760070 [-] 3: IMEI350694801239040 [-] Total IMEI identified 3 --> dump imsi [+] Dumping IMSI capture results [-] 1: IMSI901700000002484 [-] 2: IMSI901700000002486 [-] 3: IMSI901700000002488 [-] Total IMSI identified 3 --> dump assoc [+] Dumping IMSI/IMEI association [-] 1 IMEI:358622002760070 used IMSI901700000002486 [-] 2 IMEI:350694801239040 used IMSI901700000002488 [-] Total associations 2 --> show service [+] Displaying all provisioned IMSI [-] 1: exten: 2100 user: IMSI001010000000000 [-] 2: exten: 2339 user: IMSI901700000002484 [-] Total subscriber count 2 --> stop service [+] Deleting IMSI from HLR [-] Enter IMSI: IMSI901700000002484 [-] Deleted IMSI901700000002484 --> help [+] HELP SCREEN [-] dump imei - lists all identified IMEI [-] dump assoc - lists all IMEI+IMSI associations [-] dump imsi - lists all identified IMSI [-] dump save - store a record of all identities [-] start service - provide service to IMSI & log traffic [-] show service - show all provisioned phones [-] stop service - deletes an identified IMSI from HLR [-] calls - provide call collection statistics [-] sms - provide sms collection statistics [!] gprs - provide gprs collection statistics [-] cellconfig - configure cell parameters for spoofing [-] cellinfo - dump information on current cell [-] cellshow - list short codes for common cells [!] sounddial - play a sound recording to an IMSI [!] spoofsms - send a spoof SMS message to an IMSI [!] trunksetup - display current SIP trunk details [-] verbose - turn on real time tracing [-] exit - leave without shutdown [-] shutdown - bye! --> dump imei [+] Dumping seen handset IMEI [-] 1: IMEI359209002648230 [-] 2: IMEI358622002760070 [-] 3: IMEI350694801239040 [-] Total IMEI identified 3 --> dump imsi [+] Dumping IMSI capture results [-] 1: IMSI901700000002484 [-] 2: IMSI901700000002486 [-] 3: IMSI901700000002488 [-] Total IMSI identified 3 --> dump assoc [+] Dumping IMSI/IMEI association [-] 1 IMEI:358622002760070 used IMSI901700000002486 [-] 2 IMEI:350694801239040 used IMSI901700000002488 [-] Total associations 2 --> dump save [+] Saving IMSI capture results [+] Saving seen handset IMEI [+] Saving IMSI/IMEI association [-] logfile stored as 'greedybts.log' --> shutdown root@usrp-e1xx:~# cat greedybts.log [-] 1: IMSI901700000002484 [-] 2: IMSI901700000002486 [-] 3: IMSI901700000002488 [-] Total IMSI identified 3 [-] 1: IMEI359209002648230 [-] 2: IMEI358622002760070 [-] 3: IMEI350694801239040 [-] Total IMEI identified 3 [-] 1 IMEI:358622002760070 used IMSI901700000002486 [-] 2 IMEI:350694801239040 used IMSI901700000002488 [-] Total associations 2 Kind Regards, Matthew |
From: Luca B. <luc...@st...> - 2014-02-14 17:43:09
|
Hi Matthew, all, IMHO releasing such kind of image will just increase the number of script kiddies around that could mess with 2G networks (and that is a bloody seriously problem). From my experience (e.g. after releasing some slides http://www.slideshare.net/iazza/dcm-final-23052013fullycensored ) I have always been asked to release sources/scripts/etc. which I have promptly denied. The reason is pretty simple as you can imagine... If someone own an USRP or an OsmocomBB-MS... and also know just a bit of ETSI specs, SDR and C++... It is unlikely they will need a ready-to-deploy image. Obviously that is just my two cents. Just be wise about sharing it. Cheers, Luca > Hi Michael, > It is my intention to share an image and speed the process up for other researchers interested in GSM attacks and building simulations in their labs. At this time there are code changes I want to expand upon before I do (predominantly cosmetic changes and making it more feature useful from the python script). I am also hoping that enhanced detection of fakeBTS attacks will be expanded upon by the osmocom-bb toolkit (the launch of the detection capability occurred in December 2013 at CCC.) which would sufficiently detect anyone attempting to use tools of this nature in an illegal way. Most of the work I did can be recreated from the slides previously provided. If you are interested in the E100 platform, I spent alot of time exploring its capabilities and re-compiling packages. I first started trying to build the firmware from scratch with some discussion occurring between myself and the firmware developer at Ettus, eventually it became easier to customize the firmware provided by Ettus - the most difficult change being a cross-compiled kernel to enable netfilter so that IP routing became practical thus allowing for GPRS capabilities. I also had issues with the OpenBTS 52MTransceiver application in the more recent commits as significant overhaul has begun on changing its capabilities. I eventually settled on r6718 version as this provided GPRS capabilities and also was the last version functioning with the 52MTransceiver application. Most of the firmware I had to rebuild from source including things not available in package repos such as libpcap, asterisk (w/ODBC), odbc, libsqlite and python to get the capabilities I needed to demonstrate the practical elements of a GSM attack from an embedded device. I will be releasing the firmware image as soon as I tidy up some of my python code and detection tools become more effective. If you do really need the image for some research purpose then please e-mail me directly and I will gladly share a copy with you providing I can understand better your requirement for needing an off-the-shelf attack tool for GSM. > > Kind Regards, > Matthew > The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you. |
From: David A. B. <dbu...@jc...> - 2014-02-14 17:41:29
|
Luca - I generally agree, for whatever it’s worth. To release a “turn-key” attack tool is irresponsible. Anyone qualified to actually do this kind of research can hack together their own attack experiments from available software without much trouble. — David On Feb 14, 2014, at 19:27, Luca Bongiorni <luc...@st...> wrote: > Hi Matthew, all, > > IMHO releasing such kind of image will just increase the number of script kiddies around that could mess with 2G networks (and that is a bloody seriously problem). > From my experience (e.g. after releasing some slides http://www.slideshare.net/iazza/dcm-final-23052013fullycensored ) I have always been asked to release sources/scripts/etc. which I have promptly denied. > The reason is pretty simple as you can imagine... If someone own an USRP or an OsmocomBB-MS... and also know just a bit of ETSI specs, SDR and C++... It is unlikely they will need a ready-to-deploy image. > > Obviously that is just my two cents. > Just be wise about sharing it. > > Cheers, > Luca > >> Hi Michael, >> It is my intention to share an image and speed the process up for other researchers interested in GSM attacks and building simulations in their labs. At this time there are code changes I want to expand upon before I do (predominantly cosmetic changes and making it more feature useful from the python script). I am also hoping that enhanced detection of fakeBTS attacks will be expanded upon by the osmocom-bb toolkit (the launch of the detection capability occurred in December 2013 at CCC.) which would sufficiently detect anyone attempting to use tools of this nature in an illegal way. Most of the work I did can be recreated from the slides previously provided. If you are interested in the E100 platform, I spent alot of time exploring its capabilities and re-compiling packages. I first started trying to build the firmware from scratch with some discussion occurring between myself and the firmware developer at Ettus, eventually it became easier to customize the firmware provided by Ettus - the most difficult change being a cross-compiled kernel to enable netfilter so that IP routing became practical thus allowing for GPRS capabilities. I also had issues with the OpenBTS 52MTransceiver application in the more recent commits as significant overhaul has begun on changing its capabilities. I eventually settled on r6718 version as this provided GPRS capabilities and also was the last version functioning with the 52MTransceiver application. Most of the firmware I had to rebuild from source including things not available in package repos such as libpcap, asterisk (w/ODBC), odbc, libsqlite and python to get the capabilities I needed to demonstrate the practical elements of a GSM attack from an embedded device. I will be releasing the firmware image as soon as I tidy up some of my python code and detection tools become more effective. If you do really need the image for some research purpose then please e-mail me directly and I will gladly share a copy with you providing I can understand better your requirement for needing an off-the-shelf attack tool for GSM. >> >> Kind Regards, >> Matthew >> > > The information contained in this message may be CONFIDENTIAL and is intended for the addressee only. If you are not the addressee, please notify the sender immediately by return e-mail and delete this message. Thank you. > |
From: Hacker F. <hac...@go...> - 2014-02-14 17:45:43
|
Hi Luca, Whilst I agree that arming a bunch of script kiddies is completely detrimental to the security of everyone I must point out that there are many practical applications for the use of such technology to assist people working in security. For instance on multiple occasions I have been told "It is GPRS, not WIFI" which is a complete misunderstanding of the vulnerabilities in current mobility solutions used by many. I have no intention to weaken the state of security any further than it is but I am always happy to assist those who are interested in building stronger defences. When the detection tools become better it will be less of an issue but as it stands we are still in the infancy of detecting and preventing such threats because there is misunderstanding about the triviality of exploitation. I have no intention to provide material that could enable anyone to exploit others, I merely aimed to highlight what is possible and open the question as to how it can be accounted for in traditional security defences. Kind Regards, Matthew On Fri, Feb 14, 2014 at 5:27 PM, Luca Bongiorni < luc...@st...> wrote: > Hi Matthew, all, > > IMHO releasing such kind of image will just increase the number of script > kiddies around that could mess with 2G networks (and that is a bloody > seriously problem). > From my experience (e.g. after releasing some slides > http://www.slideshare.net/iazza/dcm-final-23052013fullycensored ) I have > always been asked to release sources/scripts/etc. which I have promptly > denied. > The reason is pretty simple as you can imagine... If someone own an USRP > or an OsmocomBB-MS... and also know just a bit of ETSI specs, SDR and > C++... It is unlikely they will need a ready-to-deploy image. > > Obviously that is just my two cents. > Just be wise about sharing it. > > Cheers, > Luca > > Hi Michael, > It is my intention to share an image and speed the > process up for other researchers interested in GSM attacks and building > simulations in their labs. At this time there are code changes I want to > expand upon before I do (predominantly cosmetic changes and making it more > feature useful from the python script). I am also hoping that enhanced > detection of fakeBTS attacks will be expanded upon by the osmocom-bb > toolkit (the launch of the detection capability occurred in December 2013 > at CCC.) which would sufficiently detect anyone attempting to use tools of > this nature in an illegal way. Most of the work I did can be recreated from > the slides previously provided. If you are interested in the E100 platform, > I spent alot of time exploring its capabilities and re-compiling packages. > I first started trying to build the firmware from scratch with some > discussion occurring between myself and the firmware developer at Ettus, > eventually it became easier to customize the firmware provided by Ettus - > the most difficult change being a cross-compiled kernel to enable netfilter > so that IP routing became practical thus allowing for GPRS capabilities. I > also had issues with the OpenBTS 52MTransceiver application in the more > recent commits as significant overhaul has begun on changing its > capabilities. I eventually settled on r6718 version as this provided GPRS > capabilities and also was the last version functioning with the > 52MTransceiver application. Most of the firmware I had to rebuild from > source including things not available in package repos such as libpcap, > asterisk (w/ODBC), odbc, libsqlite and python to get the capabilities I > needed to demonstrate the practical elements of a GSM attack from an > embedded device. I will be releasing the firmware image as soon as I tidy > up some of my python code and detection tools become more effective. If you > do really need the image for some research purpose then please e-mail me > directly and I will gladly share a copy with you providing I can understand > better your requirement for needing an off-the-shelf attack tool for GSM. > > Kind Regards, > Matthew > > > The information contained in this message may be CONFIDENTIAL and is > intended for the addressee only. If you are not the addressee, please > notify the sender immediately by return e-mail and delete this > message. Thank you. > > -- Matthew Hickey Tel: +44 7543 661237 Web: http://blog.hackerfantastic.com Please visit my website for blog postings, status updates and project information. |
From: Michael M. <moo...@nk...> - 2014-02-14 20:20:27
|
Matthew, Thank you for the information about how you optimized the E100 firmware. I have been having much trouble getting OpenBTS running on an E100. An already setup image would definitely speed up my development time. My area of interest is in how to improve GSM security with OpenBTS, so I do see the point David & Luca are making about not getting a prepackaged tool like this out in the wild. I have most of the features already implemented myself w/ a USRP2, but it would be nice to have a stable E100 system for my lab setup too. I am just impressed at how everything was presented in the greedyBTS interface. If I have any other questions I will send you an e-mail directly. Thank you everyone for the input, Michael On Fri, Feb 14, 2014 at 9:45 AM, Hacker Fantastic < hac...@go...> wrote: > Hi Luca, > Whilst I agree that arming a bunch of script kiddies is > completely detrimental to the security of everyone I must point out that > there are many practical applications for the use of such technology to > assist people working in security. For instance on multiple occasions I > have been told "It is GPRS, not WIFI" which is a complete misunderstanding > of the vulnerabilities in current mobility solutions used by many. I have > no intention to weaken the state of security any further than it is but I > am always happy to assist those who are interested in building stronger > defences. When the detection tools become better it will be less of an > issue but as it stands we are still in the infancy of detecting and > preventing such threats because there is misunderstanding about the > triviality of exploitation. I have no intention to provide material that > could enable anyone to exploit others, I merely aimed to highlight what is > possible and open the question as to how it can be accounted for in > traditional security defences. > > Kind Regards, > Matthew > > > On Fri, Feb 14, 2014 at 5:27 PM, Luca Bongiorni < > luc...@st...> wrote: > >> Hi Matthew, all, >> >> IMHO releasing such kind of image will just increase the number of script >> kiddies around that could mess with 2G networks (and that is a bloody >> seriously problem). >> From my experience (e.g. after releasing some slides >> http://www.slideshare.net/iazza/dcm-final-23052013fullycensored ) I have >> always been asked to release sources/scripts/etc. which I have promptly >> denied. >> The reason is pretty simple as you can imagine... If someone own an USRP >> or an OsmocomBB-MS... and also know just a bit of ETSI specs, SDR and >> C++... It is unlikely they will need a ready-to-deploy image. >> >> Obviously that is just my two cents. >> Just be wise about sharing it. >> >> Cheers, >> Luca >> >> Hi Michael, >> It is my intention to share an image and speed the >> process up for other researchers interested in GSM attacks and building >> simulations in their labs. At this time there are code changes I want to >> expand upon before I do (predominantly cosmetic changes and making it more >> feature useful from the python script). I am also hoping that enhanced >> detection of fakeBTS attacks will be expanded upon by the osmocom-bb >> toolkit (the launch of the detection capability occurred in December 2013 >> at CCC.) which would sufficiently detect anyone attempting to use tools of >> this nature in an illegal way. Most of the work I did can be recreated from >> the slides previously provided. If you are interested in the E100 platform, >> I spent alot of time exploring its capabilities and re-compiling packages. >> I first started trying to build the firmware from scratch with some >> discussion occurring between myself and the firmware developer at Ettus, >> eventually it became easier to customize the firmware provided by Ettus - >> the most difficult change being a cross-compiled kernel to enable netfilter >> so that IP routing became practical thus allowing for GPRS capabilities. I >> also had issues with the OpenBTS 52MTransceiver application in the more >> recent commits as significant overhaul has begun on changing its >> capabilities. I eventually settled on r6718 version as this provided GPRS >> capabilities and also was the last version functioning with the >> 52MTransceiver application. Most of the firmware I had to rebuild from >> source including things not available in package repos such as libpcap, >> asterisk (w/ODBC), odbc, libsqlite and python to get the capabilities I >> needed to demonstrate the practical elements of a GSM attack from an >> embedded device. I will be releasing the firmware image as soon as I tidy >> up some of my python code and detection tools become more effective. If you >> do really need the image for some research purpose then please e-mail me >> directly and I will gladly share a copy with you providing I can understand >> better your requirement for needing an off-the-shelf attack tool for GSM. >> >> Kind Regards, >> Matthew >> >> >> The information contained in this message may be CONFIDENTIAL and is >> intended for the addressee only. If you are not the addressee, please >> notify the sender immediately by return e-mail and delete this >> message. Thank you. >> >> > > > -- > Matthew Hickey > Tel: +44 7543 661237 > Web: http://blog.hackerfantastic.com > > Please visit my website for blog postings, status updates and project > information. > > > > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > -- Michael Mooradian Nathan Kunes Inc. 5055 North Harbor Drive, Suite 230 San Diego, CA 92106 619-822-1045 MAIN 619-553-3076 DIRECT 619-997-7055 CELL 619-221-1235 FAX...@nk... |
From: Mathew S. <ms...@gm...> - 2014-02-15 19:06:50
|
Hello Matthew, I completely understand and commend your desire to release a tool to help in assessing the security of cellular networks. At the same time I agree with Luca and company that releasing an image with all of the tools needed to not only assess but attack cellular networks might be irresponsible and potentially even dangerous. Anyone who has spent a bit of time assessing the current state of cellular security knows the kind of repercussions that could happen if point and click tools were given to anyone with a laptop and a $10 BTS. The last thing you would want (in my humble opinion) is to feel responsible for something negative to happen as a result of you releasing your tool - especially in the cellular space where everything is much harder to track... and affects the "physical world" a lot more directly then something like Metasploit. Though I do feel you could try to find a "middle ground". I personally do not see an issue with an OpenBTS image with a nice interface, good documentation, etc - but without the direct attack tools. Anyone who takes the time to download/install/run/learn the image can figure out how perform said attacks without too much effort (but it would deter the point and click crowd which is what I feel the majority of people are worried about). I personally feel a lot of people would be much more supportive of this - it could be used for any sort of cellular research/deployments not just direct security work. Regards, Mathew Solnik On Fri, Feb 14, 2014 at 9:45 AM, Hacker Fantastic <hac...@go...> wrote: > Hi Luca, > Whilst I agree that arming a bunch of script kiddies is > completely detrimental to the security of everyone I must point out that > there are many practical applications for the use of such technology to > assist people working in security. For instance on multiple occasions I have > been told "It is GPRS, not WIFI" which is a complete misunderstanding of the > vulnerabilities in current mobility solutions used by many. I have no > intention to weaken the state of security any further than it is but I am > always happy to assist those who are interested in building stronger > defences. When the detection tools become better it will be less of an issue > but as it stands we are still in the infancy of detecting and preventing > such threats because there is misunderstanding about the triviality of > exploitation. I have no intention to provide material that could enable > anyone to exploit others, I merely aimed to highlight what is possible and > open the question as to how it can be accounted for in traditional security > defences. > > Kind Regards, > Matthew > > > On Fri, Feb 14, 2014 at 5:27 PM, Luca Bongiorni > <luc...@st...> wrote: >> >> Hi Matthew, all, >> >> IMHO releasing such kind of image will just increase the number of script >> kiddies around that could mess with 2G networks (and that is a bloody >> seriously problem). >> From my experience (e.g. after releasing some slides >> http://www.slideshare.net/iazza/dcm-final-23052013fullycensored ) I have >> always been asked to release sources/scripts/etc. which I have promptly >> denied. >> The reason is pretty simple as you can imagine... If someone own an USRP >> or an OsmocomBB-MS... and also know just a bit of ETSI specs, SDR and C++... >> It is unlikely they will need a ready-to-deploy image. >> >> Obviously that is just my two cents. >> Just be wise about sharing it. >> >> Cheers, >> Luca >> >> Hi Michael, >> It is my intention to share an image and speed the >> process up for other researchers interested in GSM attacks and building >> simulations in their labs. At this time there are code changes I want to >> expand upon before I do (predominantly cosmetic changes and making it more >> feature useful from the python script). I am also hoping that enhanced >> detection of fakeBTS attacks will be expanded upon by the osmocom-bb toolkit >> (the launch of the detection capability occurred in December 2013 at CCC.) >> which would sufficiently detect anyone attempting to use tools of this >> nature in an illegal way. Most of the work I did can be recreated from the >> slides previously provided. If you are interested in the E100 platform, I >> spent alot of time exploring its capabilities and re-compiling packages. I >> first started trying to build the firmware from scratch with some discussion >> occurring between myself and the firmware developer at Ettus, eventually it >> became easier to customize the firmware provided by Ettus - the most >> difficult change being a cross-compiled kernel to enable netfilter so that >> IP routing became practical thus allowing for GPRS capabilities. I also had >> issues with the OpenBTS 52MTransceiver application in the more recent >> commits as significant overhaul has begun on changing its capabilities. I >> eventually settled on r6718 version as this provided GPRS capabilities and >> also was the last version functioning with the 52MTransceiver application. >> Most of the firmware I had to rebuild from source including things not >> available in package repos such as libpcap, asterisk (w/ODBC), odbc, >> libsqlite and python to get the capabilities I needed to demonstrate the >> practical elements of a GSM attack from an embedded device. I will be >> releasing the firmware image as soon as I tidy up some of my python code and >> detection tools become more effective. If you do really need the image for >> some research purpose then please e-mail me directly and I will gladly share >> a copy with you providing I can understand better your requirement for >> needing an off-the-shelf attack tool for GSM. >> >> Kind Regards, >> Matthew >> >> >> The information contained in this message may be CONFIDENTIAL and is >> intended for the addressee only. If you are not the addressee, please notify >> the sender immediately by return e-mail and delete this message. Thank you. >> > > > > -- > Matthew Hickey > Tel: +44 7543 661237 > Web: http://blog.hackerfantastic.com > > Please visit my website for blog postings, status updates and project > information. > > > > > > ------------------------------------------------------------------------------ > Android apps run on BlackBerry 10 > Introducing the new BlackBerry 10.2.1 Runtime for Android apps. > Now with support for Jelly Bean, Bluetooth, Mapview and more. > Get your Android app in front of a whole new audience. Start now. > http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > |
From: Michael M. <moo...@nk...> - 2014-02-14 16:23:50
|
Mathew, Is there any chance you will post the GreedyBTS E100 image online, or maybe even a screen capture demonstration of it working? I am very interested in how you were able to handle making the E100 run more efficiently. Also impressive is how you were able to script some very useful commands into your shell script. I would be very interested in how you were able to group all of it together. Thank you for any feedback you can give, Michael On Fri, Feb 7, 2014 at 5:12 AM, Hacker Fantastic < hac...@go...> wrote: > Hi all, > My first attempt to send this email didn't appear to succeed so I > am re-sending without attachment. Here is a copy of some slides > https://github.com/HackerFantastic/Public/blob/master/presentations/mwri_labs-GSM-Hacking-Wireless-Mobile-Phone-Communication_2014-01-30.pdfI wrote for a presentation on security weaknesses within GSM. I used an > Ettus E100 to develop a malicious BTS and GSM related attacks in a Faraday > cage and presented on how these attacks work to better understand them for > defensive purposes. I was able to use the E100 as a generic IP-router after > I cross-compiled a new kernel with netfilter enabled and also I had to > recompile a number of the packages such as Asterisk to enable ODBC and > improved SQLite support, I also had to make some changes to Python and its > modules. I used GNURadio 3.6.4 and I had to compile a specific version of > the OpenBTS code as the recent transceiver application did not function > with the E100. I was able to get the E100 to work as a GSM/GPRS router and > do real-time call placement etc. I got it to function with real-time > support and wrote a small script to provision new devices by watching the > syslog and adding to the SQLite database. > > I also used osmocom-bb to do things like use gnuplot and graph the channel > usage although the code is extremely ugly! I took RSSI measurements over a > period of time into images and then tied them together for a movie, it > isn't quite realtime but it makes pretty graphs. I mentioned how you could > implement the MS side of the GSM stack using the osmocom project and as > such am sharing the slides with the osmocom list. > > Just goes to show how mighty things come in small packages! Hope this > material is useful to others on the list who may also be trying similar > experiments. I ended up creating a firmware image that could be used to dd > and boot an E100 but at this time I do not plan on hosting it for download > unless there is sufficient interest. If you need it for some reason drop me > an e-mail. > > Here is an example of the output of the greedyBTS script. As an example my > code plays "Rick Astley - never going to give you up" when a user places a > phone call and they have been provisioned with service. All of this work > was done in a faraday cage which I obtained from Ramsey electronics which > had very good frequency attenuation graph from 0mhz all the way to 1ghz. > > root@usrp-e1xx:~# ./launch.sh > Launching asterisk > Launching HLR SMS > Launching OpenBTS > Launching Greedy BTS.. > > 888 888 d8 > e88 888 888,8, ,e e, ,e e, e88 888 Y8b Y888P 888 88e d88 dP"Y > d888 888 888 " d88 88b d88 88b d888 888 Y8b Y8P 888 888b d88888 C88b > Y888 888 888 888 , 888 , Y888 888 Y8b Y 888 888P 888 Y88D > "88 888 888 "YeeP" "YeeP" "88 888 888 888 88" 888 d,dP > , 88P 888 pDK++ > > "8",P" 888 > > > [+] Current CELL configuration > [-] ========================== > [-] Shortname: 'Noone' > [-] MCC: 901 MNC: 70 C0 ARFCN: 51 > [-] LAC: 3336 ARFCN's: 1 BAND: 900 > [-] > [-] Radio Power > [-] =========== > [-] RxGain: 47 MaxPower: 10 MinPower: 0 > > --> help > > [+] HELP SCREEN > > [-] dump imei - lists all identified IMEI > > [-] dump assoc - lists all IMEI+IMSI associations > > [-] dump imsi - lists all identified IMSI > > [-] dump save - store a record of all identities > > [-] start service - provide service to IMSI & log traffic > > [-] show service - show all provisioned phones > > [-] stop service - deletes an identified IMSI from HLR > > [-] calls - provide call collection statistics > > [-] sms - provide sms collection statistics > > [!] gprs - provide gprs collection statistics > > [-] cellconfig - configure cell parameters for spoofing > > [-] cellinfo - dump information on current cell > > [-] cellshow - list short codes for common cells > > [!] sounddial - play a sound recording to an IMSI > > [!] spoofsms - send a spoof SMS message to an IMSI > > [!] trunksetup - display current SIP trunk details > > [-] verbose - turn on real time tracing > > [-] exit - leave without shutdown > > [-] shutdown - bye! > > --> dump imei > > [+] Dumping seen handset IMEI > > [-] 1: IMEI359209002648230 > > [-] 2: IMEI358622002760070 > > [-] 3: IMEI350694801239040 > > [-] Total IMEI identified 3 > > --> dump imsi > > [+] Dumping IMSI capture results > > [-] 1: IMSI901700000002484 > > [-] 2: IMSI901700000002486 > > [-] 3: IMSI901700000002488 > > [-] Total IMSI identified 3 > > --> dump assoc > > [+] Dumping IMSI/IMEI association > > [-] 1 IMEI:358622002760070 used IMSI901700000002486 > > [-] 2 IMEI:350694801239040 used IMSI901700000002488 > > [-] Total associations 2 > > --> show service > > [+] Displaying all provisioned IMSI > > [-] 1: exten: 2100 user: IMSI001010000000000 > > [-] 2: exten: 2339 user: IMSI901700000002484 > > [-] Total subscriber count 2 > > --> stop service > > [+] Deleting IMSI from HLR > > [-] Enter IMSI: IMSI901700000002484 > > [-] Deleted IMSI901700000002484 > > --> help > > [+] HELP SCREEN > > [-] dump imei - lists all identified IMEI > > [-] dump assoc - lists all IMEI+IMSI associations > > [-] dump imsi - lists all identified IMSI > > [-] dump save - store a record of all identities > > [-] start service - provide service to IMSI & log traffic > > [-] show service - show all provisioned phones > > [-] stop service - deletes an identified IMSI from HLR > > [-] calls - provide call collection statistics > > [-] sms - provide sms collection statistics > > [!] gprs - provide gprs collection statistics > > [-] cellconfig - configure cell parameters for spoofing > > [-] cellinfo - dump information on current cell > > [-] cellshow - list short codes for common cells > > [!] sounddial - play a sound recording to an IMSI > > [!] spoofsms - send a spoof SMS message to an IMSI > > [!] trunksetup - display current SIP trunk details > > [-] verbose - turn on real time tracing > > [-] exit - leave without shutdown > > [-] shutdown - bye! > > --> dump imei > > [+] Dumping seen handset IMEI > > [-] 1: IMEI359209002648230 > > [-] 2: IMEI358622002760070 > > [-] 3: IMEI350694801239040 > > [-] Total IMEI identified 3 > > --> dump imsi > > [+] Dumping IMSI capture results > > [-] 1: IMSI901700000002484 > > [-] 2: IMSI901700000002486 > > [-] 3: IMSI901700000002488 > > [-] Total IMSI identified 3 > > --> dump assoc > > [+] Dumping IMSI/IMEI association > > [-] 1 IMEI:358622002760070 used IMSI901700000002486 > > [-] 2 IMEI:350694801239040 used IMSI901700000002488 > > [-] Total associations 2 > > --> dump save > > [+] Saving IMSI capture results > > [+] Saving seen handset IMEI > > [+] Saving IMSI/IMEI association > > [-] logfile stored as 'greedybts.log' > > --> shutdown > > root@usrp-e1xx:~# cat greedybts.log > > [-] 1: IMSI901700000002484 > > [-] 2: IMSI901700000002486 > > [-] 3: IMSI901700000002488 > > [-] Total IMSI identified 3 > > [-] 1: IMEI359209002648230 > > [-] 2: IMEI358622002760070 > > [-] 3: IMEI350694801239040 > > [-] Total IMEI identified 3 > > [-] 1 IMEI:358622002760070 used IMSI901700000002486 > > [-] 2 IMEI:350694801239040 used IMSI901700000002488 > > [-] Total associations 2 > > > Kind Regards, > Matthew > > > > > > > ------------------------------------------------------------------------------ > Managing the Performance of Cloud-Based Applications > Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. > Read the Whitepaper. > > http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk > _______________________________________________ > Openbts-discuss mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/openbts-discuss > > -- Michael Mooradian Nathan Kunes Inc. 5055 North Harbor Drive, Suite 230 San Diego, CA 92106 619-822-1045 MAIN 619-553-3076 DIRECT 619-997-7055 CELL 619-221-1235 FAX...@nk... |
From: Hacker F. <hac...@go...> - 2014-02-14 16:58:50
|
Hi Michael, It is my intention to share an image and speed the process up for other researchers interested in GSM attacks and building simulations in their labs. At this time there are code changes I want to expand upon before I do (predominantly cosmetic changes and making it more feature useful from the python script). I am also hoping that enhanced detection of fakeBTS attacks will be expanded upon by the osmocom-bb toolkit (the launch of the detection capability occurred in December 2013 at CCC.) which would sufficiently detect anyone attempting to use tools of this nature in an illegal way. Most of the work I did can be recreated from the slides previously provided. If you are interested in the E100 platform, I spent alot of time exploring its capabilities and re-compiling packages. I first started trying to build the firmware from scratch with some discussion occurring between myself and the firmware developer at Ettus, eventually it became easier to customize the firmware provided by Ettus - the most difficult change being a cross-compiled kernel to enable netfilter so that IP routing became practical thus allowing for GPRS capabilities. I also had issues with the OpenBTS 52MTransceiver application in the more recent commits as significant overhaul has begun on changing its capabilities. I eventually settled on r6718 version as this provided GPRS capabilities and also was the last version functioning with the 52MTransceiver application. Most of the firmware I had to rebuild from source including things not available in package repos such as libpcap, asterisk (w/ODBC), odbc, libsqlite and python to get the capabilities I needed to demonstrate the practical elements of a GSM attack from an embedded device. I will be releasing the firmware image as soon as I tidy up some of my python code and detection tools become more effective. If you do really need the image for some research purpose then please e-mail me directly and I will gladly share a copy with you providing I can understand better your requirement for needing an off-the-shelf attack tool for GSM. Kind Regards, Matthew On Fri, Feb 14, 2014 at 3:53 PM, Michael Mooradian < moo...@nk...> wrote: > Mathew, > > Is there any chance you will post the GreedyBTS E100 image online, or > maybe even a screen capture demonstration of it working? I am very > interested in how you were able to handle making the E100 run more > efficiently. Also impressive is how you were able to script some very > useful commands into your shell script. I would be very interested in how > you were able to group all of it together. > > Thank you for any feedback you can give, > > Michael > > > On Fri, Feb 7, 2014 at 5:12 AM, Hacker Fantastic < > hac...@go...> wrote: > >> Hi all, >> My first attempt to send this email didn't appear to succeed so I >> am re-sending without attachment. Here is a copy of some slides >> https://github.com/HackerFantastic/Public/blob/master/presentations/mwri_labs-GSM-Hacking-Wireless-Mobile-Phone-Communication_2014-01-30.pdfI wrote for a presentation on security weaknesses within GSM. I used an >> Ettus E100 to develop a malicious BTS and GSM related attacks in a Faraday >> cage and presented on how these attacks work to better understand them for >> defensive purposes. I was able to use the E100 as a generic IP-router after >> I cross-compiled a new kernel with netfilter enabled and also I had to >> recompile a number of the packages such as Asterisk to enable ODBC and >> improved SQLite support, I also had to make some changes to Python and its >> modules. I used GNURadio 3.6.4 and I had to compile a specific version of >> the OpenBTS code as the recent transceiver application did not function >> with the E100. I was able to get the E100 to work as a GSM/GPRS router and >> do real-time call placement etc. I got it to function with real-time >> support and wrote a small script to provision new devices by watching the >> syslog and adding to the SQLite database. >> >> I also used osmocom-bb to do things like use gnuplot and graph the >> channel usage although the code is extremely ugly! I took RSSI measurements >> over a period of time into images and then tied them together for a movie, >> it isn't quite realtime but it makes pretty graphs. I mentioned how you >> could implement the MS side of the GSM stack using the osmocom project and >> as such am sharing the slides with the osmocom list. >> >> Just goes to show how mighty things come in small packages! Hope this >> material is useful to others on the list who may also be trying similar >> experiments. I ended up creating a firmware image that could be used to dd >> and boot an E100 but at this time I do not plan on hosting it for download >> unless there is sufficient interest. If you need it for some reason drop me >> an e-mail. >> >> Here is an example of the output of the greedyBTS script. As an example >> my code plays "Rick Astley - never going to give you up" when a user places >> a phone call and they have been provisioned with service. All of this work >> was done in a faraday cage which I obtained from Ramsey electronics which >> had very good frequency attenuation graph from 0mhz all the way to 1ghz. >> >> root@usrp-e1xx:~# ./launch.sh >> Launching asterisk >> Launching HLR SMS >> Launching OpenBTS >> Launching Greedy BTS.. >> >> 888 888 d8 >> e88 888 888,8, ,e e, ,e e, e88 888 Y8b Y888P 888 88e d88 dP"Y >> d888 888 888 " d88 88b d88 88b d888 888 Y8b Y8P 888 888b d88888 C88b >> Y888 888 888 888 , 888 , Y888 888 Y8b Y 888 888P 888 Y88D >> "88 888 888 "YeeP" "YeeP" "88 888 888 888 88" 888 d,dP >> , 88P 888 pDK++ >> >> "8",P" 888 >> >> >> [+] Current CELL configuration >> [-] ========================== >> [-] Shortname: 'Noone' >> [-] MCC: 901 MNC: 70 C0 ARFCN: 51 >> [-] LAC: 3336 ARFCN's: 1 BAND: 900 >> [-] >> [-] Radio Power >> [-] =========== >> [-] RxGain: 47 MaxPower: 10 MinPower: 0 >> >> --> help >> >> [+] HELP SCREEN >> >> [-] dump imei - lists all identified IMEI >> >> [-] dump assoc - lists all IMEI+IMSI associations >> >> [-] dump imsi - lists all identified IMSI >> >> [-] dump save - store a record of all identities >> >> [-] start service - provide service to IMSI & log traffic >> >> [-] show service - show all provisioned phones >> >> [-] stop service - deletes an identified IMSI from HLR >> >> [-] calls - provide call collection statistics >> >> [-] sms - provide sms collection statistics >> >> [!] gprs - provide gprs collection statistics >> >> [-] cellconfig - configure cell parameters for spoofing >> >> [-] cellinfo - dump information on current cell >> >> [-] cellshow - list short codes for common cells >> >> [!] sounddial - play a sound recording to an IMSI >> >> [!] spoofsms - send a spoof SMS message to an IMSI >> >> [!] trunksetup - display current SIP trunk details >> >> [-] verbose - turn on real time tracing >> >> [-] exit - leave without shutdown >> >> [-] shutdown - bye! >> >> --> dump imei >> >> [+] Dumping seen handset IMEI >> >> [-] 1: IMEI359209002648230 >> >> [-] 2: IMEI358622002760070 >> >> [-] 3: IMEI350694801239040 >> >> [-] Total IMEI identified 3 >> >> --> dump imsi >> >> [+] Dumping IMSI capture results >> >> [-] 1: IMSI901700000002484 >> >> [-] 2: IMSI901700000002486 >> >> [-] 3: IMSI901700000002488 >> >> [-] Total IMSI identified 3 >> >> --> dump assoc >> >> [+] Dumping IMSI/IMEI association >> >> [-] 1 IMEI:358622002760070 used IMSI901700000002486 >> >> [-] 2 IMEI:350694801239040 used IMSI901700000002488 >> >> [-] Total associations 2 >> >> --> show service >> >> [+] Displaying all provisioned IMSI >> >> [-] 1: exten: 2100 user: IMSI001010000000000 >> >> [-] 2: exten: 2339 user: IMSI901700000002484 >> >> [-] Total subscriber count 2 >> >> --> stop service >> >> [+] Deleting IMSI from HLR >> >> [-] Enter IMSI: IMSI901700000002484 >> >> [-] Deleted IMSI901700000002484 >> >> --> help >> >> [+] HELP SCREEN >> >> [-] dump imei - lists all identified IMEI >> >> [-] dump assoc - lists all IMEI+IMSI associations >> >> [-] dump imsi - lists all identified IMSI >> >> [-] dump save - store a record of all identities >> >> [-] start service - provide service to IMSI & log traffic >> >> [-] show service - show all provisioned phones >> >> [-] stop service - deletes an identified IMSI from HLR >> >> [-] calls - provide call collection statistics >> >> [-] sms - provide sms collection statistics >> >> [!] gprs - provide gprs collection statistics >> >> [-] cellconfig - configure cell parameters for spoofing >> >> [-] cellinfo - dump information on current cell >> >> [-] cellshow - list short codes for common cells >> >> [!] sounddial - play a sound recording to an IMSI >> >> [!] spoofsms - send a spoof SMS message to an IMSI >> >> [!] trunksetup - display current SIP trunk details >> >> [-] verbose - turn on real time tracing >> >> [-] exit - leave without shutdown >> >> [-] shutdown - bye! >> >> --> dump imei >> >> [+] Dumping seen handset IMEI >> >> [-] 1: IMEI359209002648230 >> >> [-] 2: IMEI358622002760070 >> >> [-] 3: IMEI350694801239040 >> >> [-] Total IMEI identified 3 >> >> --> dump imsi >> >> [+] Dumping IMSI capture results >> >> [-] 1: IMSI901700000002484 >> >> [-] 2: IMSI901700000002486 >> >> [-] 3: IMSI901700000002488 >> >> [-] Total IMSI identified 3 >> >> --> dump assoc >> >> [+] Dumping IMSI/IMEI association >> >> [-] 1 IMEI:358622002760070 used IMSI901700000002486 >> >> [-] 2 IMEI:350694801239040 used IMSI901700000002488 >> >> [-] Total associations 2 >> >> --> dump save >> >> [+] Saving IMSI capture results >> >> [+] Saving seen handset IMEI >> >> [+] Saving IMSI/IMEI association >> >> [-] logfile stored as 'greedybts.log' >> >> --> shutdown >> >> root@usrp-e1xx:~# cat greedybts.log >> >> [-] 1: IMSI901700000002484 >> >> [-] 2: IMSI901700000002486 >> >> [-] 3: IMSI901700000002488 >> >> [-] Total IMSI identified 3 >> >> [-] 1: IMEI359209002648230 >> >> [-] 2: IMEI358622002760070 >> >> [-] 3: IMEI350694801239040 >> >> [-] Total IMEI identified 3 >> >> [-] 1 IMEI:358622002760070 used IMSI901700000002486 >> >> [-] 2 IMEI:350694801239040 used IMSI901700000002488 >> >> [-] Total associations 2 >> >> >> Kind Regards, >> Matthew >> >> >> >> >> >> >> ------------------------------------------------------------------------------ >> Managing the Performance of Cloud-Based Applications >> >> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. >> Read the Whitepaper. >> >> http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk >> _______________________________________________ >> Openbts-discuss mailing list >> Ope...@li... >> https://lists.sourceforge.net/lists/listinfo/openbts-discuss >> >> > > > -- > > Michael Mooradian > Nathan Kunes Inc. > 5055 North Harbor Drive, Suite 230 > San Diego, CA 92106619-822-1045 MAIN619-553-3076 DIRECT619-997-7055 CELL619-221-1235 FAX...@nk... > > -- Matthew Hickey Tel: +44 7543 661237 Web: http://blog.hackerfantastic.com Please visit my website for blog postings, status updates and project information. |
From: Jim F. <jrf...@ma...> - 2014-02-15 11:28:34
|
Mathew, > Whilst I agree that arming a bunch of script kiddies is completely detrimental to the security of everyone I must point out that there are many practical applications for the use of such technology to assist people working in security. For instance on multiple occasions I have been told "It is GPRS, not WIFI" which is a complete misunderstanding of the vulnerabilities in current mobility solutions used by many. I have no intention to weaken the state of security any further than it is but I am always happy to assist those who are interested in building stronger defences. When the detection tools become better it will be less of an issue but as it stands we are still in the infancy of detecting and preventing such threats because there is misunderstanding about the triviality of exploitation. I have no intention to provide material that could enable anyone to exploit others, I merely aimed to highlight what is possible and open the question as to how it can be accounted for in traditional security defences How about another alternative: you keep the script-kiddie image ready, but don't publish it. Instead, keep publicizing the vulnerabilities, with articles in the press, demos. Keep publishing and publicizing the results, but not the script. If someone asks for it, you could give it to them if you felt OK about them. If they felt creepy to you, maybe you wouldn't. My thought is that few of the people you seek to inform will take the trouble to download, test, etc. And if they're wiling to do that, asking you for a copy is minor effort. On the other hand, many script kiddies wouldn't want to bother asking -- they'll grab some other script. I think the result of this policy would be no fewer informed legitimate actors, and fewer script kiddies. My thoughts, Jim Forster Range Networks |