Message-ID: <CAJVRA1RuWFr0UNdVj=CA_fJVgg7VT+mTd=tr2U6HO7rLPxDH0Q@mail.gmail.com>
Date: Thu, 11 Aug 2011 04:14:03 -0700
From: coderman <coderman@...il.com>
To: full-disclosure@...ts.grok.org.uk
Subject: Re: DEF CON 19 - hackers get hacked!

On Wed, Aug 10, 2011 at 11:17 AM, coderman <coderman@...il.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/

Powered by blists - more mailing lists