Full Disclosure mailing list archives
Re: DEF CON 19 - hackers get hacked!
From: coderman <coderman () gmail com>
Date: Thu, 11 Aug 2011 04:14:03 -0700
On Wed, Aug 10, 2011 at 11:17 AM, coderman <coderman () gmail com> wrote:
lots of misunderstanding...
c'mon people, you're killing me.. "Are you claiming Anon/Lulz did this?" wow, you absorb a disturbing amount of broadcast media and comodo PR to think they could do this. no; was implying whoever deployed this used a scorched earth approach to finding the information on desired targets at any cost. this offensive tech did not take no for an answer; many different ways to pry a yes please can i have another out of your Windows or Linux or Android phone. the continuous and methodical deployment of this system from Saturday through Monday 8AM implies a bit more discipline than young whipper snappers all lushed up at a conference can muster. ;) not to mention the impressive arsenal of weaponized exploits specifically tailored for use in an active man-in-the-middle environment against many targets and protocols simultaneously... "You're full of shit!" i have nothing to prove. if you care, come next year and get your first hand taste. i do this for my own personal edification. preparing you a thorough analysis turns my fun con into sad work. ~_~; "What does a WiMax/4G session jacking look like?" <6>[68822.336791] Thread-736(parent:zygote): vibrates 30 msec <7>[68825.233947] ALS value: 0x3, level: 0 # <7>[68825.877868] wimax0: no IPv6 routers present <7>[68826.195312] ALS value: 0x7, level: 1 # <6>[68827.070068] sequans_xxx: tx_queue len 0, enabling netif_queue <6>[68827.308776] sequans_xxx: card switched to DROPPED state <6>[68829.662414] sequans_xxx: got RX data, card is not asleep <6>[68829.663116] sequans_xxx: WiMAX carrier LOST [ignored] <7>[68832.368225] usb0: no IPv6 routers present <6>[68832.566741] sequans_xxx: WiMAX carrier LOST [ignored] <6>[68832.860931] sequans_xxx: WiMAX carrier PRESENT [ignored] <7>[68832.963958] ALS value: 0x3, level: 0 # <6>[68835.575408] [Port list] Add port [80] <6>[68835.575530] [Port list] [1] = 53 <6>[68835.575714] [Port list] [2] = 80 <7>[68837.787841] ALS value: 0x9, level: 2 # <7>[68840.690673] ALS value: 0x3, level: 0 # <7>[68843.368194] wimax0: no IPv6 routers present --- or a less subtle: 2:55 9.882 >| DC/Device SEVERE >| Stack trace, from last to first: 12:55 9.882 >| DC/Device SEVERE >| 1) 0x0004136C epsFatalError() +156 12:55 9.882 >| DC/Device SEVERE >| 2) 0x00042F20 epsAssertFailed() +76 12:55 9.882 >| DC/Device SEVERE >| 3) 0x0010A950 dlcsAgc::purgeAgc() +116 12:55 9.882 >| DC/Device SEVERE >| 4) 0x000FADD0 dlcsSync::purgeAgc() +64 12:55 9.882 >| DC/Device SEVERE >| 5) 0x001061CC dlcsAcquisition::handlePllOff(void*) +316 12:55 9.882 >| DC/Device SEVERE >| 6) 0x0010702C dlcsAcquisition::notifyEvent(dlcsAcquisition::Event, void*) +264 12:55 9.882 >| DC/Device SEVERE >| 7) 0x002F5138 dlcsEventCmd<dlcsAcquisition, dlcsAcquisition::Event>::execute() +72 12:55 9.882 >| DC/Device SEVERE >| 8) 0x0029C790 stkCommandProcessor::run() +88 12:55 9.882 >| DC/Device SEVERE >| 9) 0x00010504 Cyg_HardwareThread::thread_entry(Cyg_Thread*) +40 12:55 9.882 >| DC/Device SEVERE >| 10) 0x000104DC Cyg_HardwareThread::thread_entry(Cyg_Thread*) +0 12:55 9.882 >| DC/Device SEVERE >| 12:55 9.882 >| DC/Security detail >| idling => stopped 12:55 9.882 >| EARL/fsm info >| old=success, new=idle 12:55 9.882 >| EARL/tls WARNING >| (EAP-TLS) Calling SSL_shutdown() 12:55 9.882 >| EARL/tls audit >| Couldn't shut down SSL connection. 12:55 9.882 >| EARL/tls audit >| (EAP-TLS) Freeing mytls_vars->ctx! 12:55 9.884 >| EARL/tls audit >| (EAP-TLS) Freeing session key const! 12:55 9.884 >| EARL/fsm audit >| Session destroyed --- as for bandwidth, you can often observe a MitM via bandwidth. in this case a normal link has good download and roughly half that or less in upload. this is because the towers have a harder time hearing your relatively quiet radio in your phone while you phone can hear the towers perfectly fine. a middle will reverse this characteristic unless proper attention to traffic shaping / capacity is applied. notably indicative is a twice over fast upload or more. this occurs when the middle is caching incoming traffic prior to analysis, mangling, and forwarding. good bandwidth sample: Date,ConnType,Lat,Lon,Download,Upload,Latency,ServerName,InternalIp,ExternalIp "2011-08-08 00:29","Cell","45.51041","-122.78143",814541,221776,98,"Las Vegas, NV","108.112.139.132, 192.168.42.129","184.223.198.15" MitM bandwidth sample: Date,ConnType,Lat,Lon,Download,Upload,Latency,ServerName,InternalIp,ExternalIp "2011-08-08 04:39","Cell","45.51041","-122.78143",20432,211542,104,"Las Vegas, NV","184.224.144.151, 192.168.42.129","184.224.144.151" "2011-08-08 04:42","Cell","45.51041","-122.78143",27183,149596,105,"Las Vegas, NV","184.224.144.151, 192.168.42.129","184.224.144.151" "Send me a copy of your packet dumps, payloads, rootkit binaries,.." oh aren't you quite the jester... seriously EOM this time. _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Current thread:
- DEF CON 19 - hackers get hacked! coderman (Aug 10)
- Re: DEF CON 19 - hackers get hacked! -= Glowing Sex =- (Aug 10)
- Re: DEF CON 19 - hackers get hacked! coderman (Aug 10)
- Re: DEF CON 19 - hackers get hacked! -= Glowing Sex =- (Aug 10)
- Re: DEF CON 19 - hackers get hacked! coderman (Aug 10)
- Re: DEF CON 19 - hackers get hacked! coderman (Aug 10)
- Re: DEF CON 19 - hackers get hacked! Eric McCann (Aug 10)
- Re: DEF CON 19 - hackers get hacked! coderman (Aug 11)
- <Possible follow-ups>
- Re: DEF CON 19 - hackers get hacked! Basan (Aug 11)
- Re: DEF CON 19 - hackers get hacked! Ivan . (Aug 11)
- Re: DEF CON 19 - hackers get hacked! chris nelson (Aug 12)
- Re: DEF CON 19 - hackers get hacked! -= Glowing Sex =- (Aug 10)