**** BEGIN LOGGING AT Thu Jan 03 02:59:59 2013 Jan 03 09:27:17 LOL, i've actually tried receiving an MMS for the first time in my life. Jan 03 09:27:28 Had to use online PDU decoder to get the link. Jan 03 09:27:34 Then googled for how to use that link. Jan 03 09:27:37 Then changed APN Jan 03 09:27:43 Then exported http_proxy Jan 03 09:27:54 Then used wget to get contents through that proxy Jan 03 09:27:56 All to get Jan 03 09:28:21 +Q���text_0.txt�"�text_0.txtС новым годом! Счастья и удачи в новом году! Jan 03 09:29:13 Not even a single image or anything like that. Only silly text. That's truely retarded. I now know firsthand that MMS is an utter crap. Jan 03 09:29:33 Synchronized Multimedia Integration Language? To hell with it! Jan 03 10:08:28 https://github.com/kumadasu/tizen-history/blob/master/tizen-history.pdf?raw=true Jan 03 10:08:31 lolz Jan 03 10:39:06 The operator told me their system detects automatically whether my cellphone is capable of receiving messages with mms. But he couldn't tell how it does that :/ Jan 03 15:27:34 lindi-: big thanks for sharing that video! Jan 03 15:30:43 PaulFertser: another surprisingly refreshing talk was http://ftp.ccc.de/congress/29C3/mp4-h264-HQ/29c3-5195-en-executable_metadata_h264.mp4 Jan 03 15:33:31 djb's facthack talk is good, too Jan 03 15:33:46 but sage doesn't build on my system :( Jan 03 15:35:53 I also posted to bugtraq today but it's stuck in the moderation still :) Jan 03 15:38:13 what was the first video? /me missed it Jan 03 15:38:52 pabs3: http://ftp.ccc.de/congress/29C3/mp4-h264-HQ/29c3-5226-en-further_hacks_calypso_h264.mp4 Jan 03 15:38:52 pabs3: the calypso one Jan 03 15:39:45 ah. yeah, good talk. I also enjoyed nion's one about GSM subscriber DoS Jan 03 15:41:03 Harald wrote there're too many non-technical and German talks planned. Was the event enjoyable in general? Jan 03 15:42:40 well I skipped the german talks Jan 03 15:42:53 PaulFertser, yes of course Jan 03 15:44:38 Was there anybody from the invisiblethingslab btw? Jan 03 15:44:59 I don't think I saw any presentation from them Jan 03 16:49:42 I didn't see an assembly Jan 03 20:49:12 PaulFertser: http://www.securityfocus.com/archive/1/525190/30/0/threaded Jan 03 20:52:50 lindi-: good job! Aastra is so lame, guess they think that's not an issue and thus there's no reason to care. Jan 03 20:53:24 PaulFertser: unfortunately I know several TFTP servers that serve SIP passwords to the whole world now Jan 03 20:54:04 PaulFertser: they also contain admin passwords that in many deployments allow you fully remotely manage the phones.. Jan 03 20:55:16 lindi-: then probably per-phone per-port vlans need to be configured and the phones remain connected to the same port every time. Jan 03 20:55:33 PaulFertser: it was interesting to figure out how to map these actually. I eventually noticed that they all DNS query 2.aastra.pool.ntp.org so I only needed to check which DNS servers had that in their cache Jan 03 20:56:26 lindi-: do you mean those devices need internet access to work? Sorry probably i'm too sleepy to fully understand or lacking the context. Jan 03 20:56:58 PaulFertser: in the deployment that I saw they do connect to internet to get their configuration files from a public TFTP server Jan 03 20:57:29 PaulFertser: the telco just ships phones around and wants to keep its infrastructure in one place Jan 03 20:58:02 lindi-: what does telco think about the vulnerability? Jan 03 20:58:16 PaulFertser: I don't think they have had time to comment about this yet Jan 03 20:58:23 lindi-: i guess if they would approach Aastra that would be different for them :) Jan 03 20:58:57 PaulFertser: hard to say Jan 03 20:59:15 this is actually very difficult for Aastra to properly fix, there are deeper problems than what I published so far Jan 03 20:59:26 (they have not really figured out this key distribution issue...) Jan 03 21:00:01 lindi-: eh heh Jan 03 21:00:04 tough Jan 03 21:00:20 PaulFertser: yeah, it's difficult to do out of the box deployment securely Jan 03 21:00:33 they'd need to generate a unique secret key for each phone in factory Jan 03 21:00:45 and somehow figure out how to ship this list to the users securely Jan 03 21:01:03 but of course they ended up using the same key on all phones... Jan 03 21:08:07 lindi-: yeah, i see, the whole solution sucks Jan 03 21:08:48 PaulFertser: yeah adding a sim card reader sounded like the simplest solution to me Jan 03 21:08:56 PaulFertser: but they are not going to recall all their phones :) Jan 03 21:10:10 lindi-: how does tftp server identify the client? Jan 03 21:12:07 PaulFertser: it doesn't Jan 03 21:12:20 PaulFertser: the client just downloads ${MAC}.tuz Jan 03 21:12:42 so any client can download any configuration file Jan 03 21:12:44 lindi-: and once you figure the key, you can download and fully decrypt any file instantly. Jan 03 21:12:53 PaulFertser: yeah, did that last year Jan 03 21:13:05 just practising responsible disclosure (TM) here :) Jan 03 21:13:10 :) Jan 03 21:13:34 it was bit messy since they are not using standard 3DES Jan 03 21:14:23 lindi-: or even when not knowing the key you can substitute one file with the other and make your phone pretend it's someone else, right? Jan 03 21:14:35 PaulFertser: yes Jan 03 21:15:30 lindi-: heh, so the vendor is really retarded, and telco's fucked up with that. Great find :) Jan 03 21:17:31 PaulFertser: I am mostly worried about using these phones as a stepping stone to attack internal networks Jan 03 21:17:33 lindi-: probably they do not verify the SSL certificates too and if you didn't know the key you still would be able to perform MITM for SIP and get the sip password? Jan 03 21:19:52 PaulFertser: its digest authentication with a nonce Jan 03 21:19:59 lindi-: i see Jan 03 21:20:06 it's Jan 03 21:20:51 PaulFertser: getting SIP password only lets you make free calls and social engineering, not a big deal compared to getting access to internal networks Jan 03 21:21:33 lindi-: did understanding the differences in crypto implementation require you to get really deep into the topic or was it relatively easy? Jan 03 21:21:58 PaulFertser: I had to modify a DES implementation slightly to match it Jan 03 21:22:19 lindi-: well, the trick is to find out how exactly to modify it :) Jan 03 21:22:46 PaulFertser: I'll show that in the next mail, I'll wait for response to this first vulnerability first Jan 03 21:23:27 lindi-: for another year? :) well, ok, i'll wait :) Jan 03 21:23:47 not another year, a month maybe Jan 03 21:24:48 PaulFertser: another reason is that the code is really messy Jan 03 21:25:11 PaulFertser: and I'd rather ship a simple tool that can be used to both encrypt and decrypt .tuz files instantly Jan 03 21:25:13 lindi-: btw, another earlier presentation by Sylvain described how they figured the DSP programming with a bit more details: http://people.osmocom.org/tnt/talks/phdays2012-abusing-calypso-phones.pdf Jan 03 21:25:54 currently many asterisk installations use a binary-only 32-bit linux executable to generate the configuration files Jan 03 21:26:54 I'm expecting aastra to pull that tool completely if I release more details so I'd rather offer an alternative tool to make them realize they can't stop anything by pulling their tool Jan 03 21:29:01 lindi-: but why do you care? Jan 03 21:29:50 PaulFertser: we have plenty of these phones :P Jan 03 21:31:38 lindi-: do you mean you hope to repurpose them for something safe for you and the networking environment? Jan 03 21:31:58 PaulFertser: it's a long story Jan 03 21:33:06 PaulFertser: we had our own asterisk server and phones until last year. then management outsourced that to a big telco who wanted to replace all the phones since they wanted something that'd support encrypted configuration files so that they could safely manage them Jan 03 21:35:44 lindi-: but you still have your old phones and now you got passwords so you can use your own devices (you trust) with the big telco's network. Jan 03 21:36:02 PaulFertser: technically yes Jan 03 21:36:54 PaulFertser: we can also use asterisk as a bridge with the new phones Jan 03 21:37:19 lindi-: ah, yes, now that you can control them yourself :) Jan 03 21:37:49 our old telcho just gave use a list of sip usernames and passwords and we used asterisk with those Jan 03 21:37:55 lindi-: i wonder if you management can sue the telco for not providing the secure service that's apparently promised. Jan 03 21:38:11 heh Jan 03 21:39:55 lindi-: btw, are the phones the only untrusted devices that can possibly gain access to your internal network? Jan 03 21:40:45 PaulFertser: afaik yes Jan 03 21:40:53 printers are not routed to internet Jan 03 21:41:25 experimental fpga network testing gear is in its own vlan :) Jan 03 21:41:52 in general we only have a http proxy outside Jan 03 21:42:07 so at least accidentally a device shouldn't be accessing outside network Jan 03 21:43:01 lindi-: btw, it seems that any http proxy is in general goes against the basic Internet principles and there's no decent way to use one (working sane auto-configuration). Jan 03 21:44:03 lindi-: i thought about that for a while and talked to some people and it looks like that's just something that won't properly work. And e.g. traffic accounting should be better done on iptables (or some deep packet inspection) level on the border gateway. Jan 03 21:52:14 lindi-: malicios code can get through an http proxy to the end user computer just fine. Are you sure considering the internal network considerably more trusted than the internet makes sense? Jan 03 21:52:55 I think the idea of a internal proxy is also for auditing Jan 03 21:53:38 PaulFertser: yes it can Jan 03 21:53:51 at one of my previous job, we used windows installation on C:/win32 or something like that, so most malware would fail because they hardcoded the path :) Jan 03 21:53:57 misc: there exist no sane supported way to tell all the http clients the proxy address so it's unusable anyway. Jan 03 21:54:15 PaulFertser: transparent proxying, kinda work Jan 03 21:54:26 misc: nah, https Jan 03 21:54:36 PaulFertser: yeah, there is this issue Jan 03 21:54:51 * misc know a embassy that blocked https due to that Jan 03 21:55:00 misc: so it doesn't work for half the cases so it doesn't make sense. Jan 03 21:55:28 PaulFertser: still better than nothing, we found quite a lot of virus/malware that used http Jan 03 21:55:49 there is no total solution, but even 30% is better than nothing Jan 03 21:56:12 ( technically, if you manage the computers, you can do mitm and https proxying, but that's ugly ) Jan 03 21:56:44 misc: and also your users won't complain they can't use that access for any personal purposes, i'd get offended by that. Jan 03 21:56:57 PaulFertser: i would too Jan 03 21:57:11 s/won't/will/ Jan 03 21:57:11 PaulFertser meant: misc: and also your users will complain they can't use that access for any personal purposes, i'd get offended by that. Jan 03 21:58:01 I am frankly not for spying on users, but for example, forcing a http proxy for servers would make some sense Jan 03 21:58:15 misc: thinking about the malware you're talking about, it seems you're right. Luckily i'm not a sysadmin and i do not need to try secure some loosy systems from some loosy malware. Jan 03 21:58:45 PaulFertser: some malwares developpers are crative Jan 03 21:58:54 like setting ipsec, ipv6, to bypass filter Jan 03 21:58:58 misc: russian mobile operators use DPI and transparent proxying for all the http traffic, even on non-standard ports. Jan 03 21:59:00 PaulFertser: mailed finnish cert and asked them to notify the telcos Jan 03 21:59:08 PaulFertser: same in france Jan 03 21:59:23 in fact, i still trying to figure why mtr and traceroute give me so weird result Jan 03 22:01:02 lindi-: that might make them think, heh. You're doing so much cool stuff, that's amazing. Jan 03 22:01:24 I still am fascinated by that ublox trick to get raw data. Jan 03 22:11:48 PaulFertser: thanks :) **** ENDING LOGGING AT Fri Jan 04 02:59:58 2013