December 14, 2008

How to make JohnTR use all of your cpu cores

Lack of time make people use available resources more efficiently . And this rule applies to me too . I`ve got a password hash to crack and can`t wait so many days for my 1.8Gh mobile CPU to try to crack it . My first idea was to look for more CPU power and speed ,something which is not much cheap if you`re looking for cutting-edge technology !

Available cpu on my notebook (Intel 1.8 Dothan) could try about ~3500 passwords per second . Damn low ! So I did a call-for-idle-cpu and got two of them . First one was AMD Athlon 5000 LD , working as fast as ~6200 c/s . Near two times faster than my own cpu , but still far away from what I`m looking for ! So I tried second cpu , Intel X5450 3Ghz . Fastest rate on this cpu with different compiles of JohnTR was a bit faster than AMD , around ~8500 c/s. I want it FASTER !

We`re living in age of multi-core processors but we rarely use all the power of our cpu . Raw JohnTR unfortunately , is not multi-core aware by default . It means that if you run it on a multi-core (2,4,8,... !) cpu JohnTR will use only ONE of cores , just like you have a normal cpu . Too much bad for us ! The Intel X5450 cpu I was using has 8 cores and I`m missing 7 of them.
Those idle cores made me remember a great projec , patching JohnTR for making it multi-core aware . It`s known as MPI Patch . MPI Patch itself is based on another project ( MPICH ) and a research work by Ryan Lim, available here .
As BindShell documentations about their MPI Patch was not much kiddy friendly , I though would worth a blog post trying to make it an easy to follow step-by-step experience for any honored multi-core cpu owner . So here it is :

JohnThe Ripper + MPI + Intel X5450 3Gh

Step One: Make sure you are ready to go for compiling few source code packages . All you need is a recent version of GCC and C++ . On the linux shell I had they were not available on fresh install , so what I did was :

yum install gcc
yum install gcc-c++.i386

Step Two: Get latest MPICH source package from here . Follow the simple extract>./configure>make>make install game . if you don`t know how to play this game , here is the instruction :

tar -xf mpich2-1.0.8.tar.gz
cd mpich2-1.0.8


make install

Step Three: Time to get MPI armored JohnTR . Get it from BindShell project page , and note to skip the version named "....-mp8-all..." . This version is patched to handle more password hash types , but we don`t need it now . And it`s also not compiling smoothly out of the box . So get this MPI-only patched version . Let`s play above game again :

tar -xf john-
cd john-

make generic

Have my advice and use "generic" rule to compile JohnTR . Don`t ask why , it`s just better for you and works without any problem . [Since I've had multiple comments & emails about this section of post, I`m updating it. Thank your Solar Designer and other visitors for your notes about this.]

Above you may have noticed the "genetic" switch used to make JohnTR. "generic" is the simplest option you may use here. To have the list of available options for make, simply use "make" without any parameter instead, and then you can replace 'generic' with the proper option which is the closest to your system architecture. The best and most optimized option for modern systems would be probably "linux-x86-64" but if you`re not using a 64bit operating system, next choice will be "linux-x86-sse2". Last but not least, if you`re going to compile JohnTR on a 64bit operating system you should use 64bit version of compiler instead of what I've mentioned in step one, to be able to use 64bit optimizations. If you`re still unsure about capabilities of your cpu, and want to know more about it, you can use below command:

cat /proc/cpuinfo

Choosing the right option for make is important, since it HIGHLY affect performance of JohnTR. For some hash types like MD5-based ones, difference between generic & optimized option is not really noticeable but for some algorithms like DES-based ones, using optimized make option will result in about 3x time faster crack speed. Before updating the post and adding this section I wrote everything simply based on generic build. So all screen-shots and numbers are OLD & UNOPTIMIZED. Solar.Designer mentioned that his optimized JohnTR compile running on ONE cpu core, crack 'Traditional DES' hashes as fast as my 8 cores cpu. So now you have some idea about effectiveness of proper build :)

Step Four: So far we`ve compile MPICH and JohnTR-MPI , but we`re not ready to run yet . MPICH needs some configurations to start it`s daemon . Don`t panic, a simple single-line config file is enough to keep things working :) Here`s how to make MPI work :

echo MPD_SECRETWORD=secret > /etc/mpd.conf
chmod 600 /etc/mpd.conf
mpd --daemon

Above configuration is for the cases you`re running mpd as root (not advised!) . If you feel insecure , go read full detailed manuals of MPI project .

Step Five : Time to fire JohnTR ! Since we want to use capabilities provided by MPI interface , we should run JohnTR on top of MPI ,and that`s why JohnTR is patched ! On my test-bed (8 cores Intel) here`s how I run it :

mpirun -np 8 /root/temp/john- /root/temp/shadow

Noticed bolded parameters ? There you can adjust number of threads for MPI , or in other words , number of processor cores you want JohnTR to use for running . If you`ve got a dual-core cpu , it would be " -np 2 " and so on ...

That`s it ! But how much FASTER we`re now ? I bet you`ll be excited by results . Below are benchmark tests of running John on ONE and then on 8 cores . I`ve highlighted differences in case you``re lost in numbers.

John running on 8 cores :

John runnong on 1 core :

Using all 8 cores of test-bed cpu at clock of 3Ghz I was able to achive speed of about 70,000 tries per second , compared to out-of-box speed of ~8000 tries per second . Yes , this what I consider FAST ! My focus was gaining better speed for cracking shadow passwords, but if you`re going to crack windows (LM) dumped hashes , cracking speed is madly high . About 42 Million tries per second using all 8 cores , versus 5.4 Million tries per second for a normal JohnTR lunch against LM hashes .
Things are not going to stop here . MPI let you distribute your cracking experiences not only to multiple cores on single cpu , but to multiple cpus on networked cluster of computers . Just imagine the processing power of 5 clustered 8-cores systems running JohnTR ... o.0

Let me thank you s_hahroo_z for providing AMD processor test result , and special thanks for Mr.Hajimoradi for sharing his dusty 8 core cpu , and of course the root shell ! :)

November 8, 2008

WPA is sick (Not dead yet!)

I`m glad (As a security adviser) and again glad (As a for-hire intruder) that WPA is seriously sick ,but not really died yet ! Later you`ll notice why I`m glad in both positions.

Few days ago I noticed a post in SANS dairy portal announcing a new attack against WPA leading to compromise integrity and partially confidentiality of underlying traffic protected by WPA. Full technical details and possibilities are not disclosed yet and everyone have to wait few days till announced talk on PacSec .

So what is this about ?
Let`s get back to 2004 , the time practical chop-chop attack against WEP encryption came out of dark. WEP was actually (read theorically) broken since 2001 but chop-chop concept made so easy that even your grandmother can own you !
In chop-chop the encryption is not really attacked , and as a result of sucessfull attack you would NOT get clear-text of data protected by WEP (RC4 if you like crypto terms). chop-chop only let you make educated guesses on contents of some of encrypted packets (like ARP) and confirm that you can repreduce these packets with your own values while still not knowing the encryption key used to protect it .
Why was this possible in WEP? It`s because of the way protocol was designed . in WEP we can split protection of 802.11 frames into two parts . One part is the payload (where encrypted data resides) and another part is the checksum of encrypted part . If you try to send a modifyed (encrypted) payload that don`t match it`s checksum it would be rejected by access-point , but if you do a right guess where checksum and payload matches, AP will replay back an ACK . This is where chop-chop catch it to begin it`s attack . In chop-chop attack is implemented against ARP packets , because of their nature . ARP packets are small and their contents are easy to guess . In short , you have only two bytes to guess (or actually brute-force) to find a right match between checksum and header of packet. these two bytes are last two part of IP digit , like 192.168.X.Y. Other parts of ARP packet are fixed and known . As a result attacker will be able to get clear-text content of frame without knowing the key used to encrypt them.
Finally result of chop-chop attack will be used to make AP generate too many packets with weak IV , letting us to crack and extract encryption key .

In WPA things are a little different . There are some countermeasures to prevent attacker from continuing re-sending frames with bad checksum . If the client recives two bad-checksums withing 60 seconds , it will pause 60 seconds and then attempt to generate new key and negotiate the connection again . This is what TKIP do and why WPA is better than WEP because of enhanced checksum algorythm (Named 'Michael') implemented in WPA. Note that TKIP is still weak becayse it`s still based on RC4 and is not the best workaroung for WEP weaknesses. TKIP (as one of three workarounds provided for WEP death) was just to keep backward-compatibility . Other two workarounds provided were based on AES encryption .

How new attack against WPA is possible?

In chop-chop , to be able to break things we needed to be able to re-send packets, which is exactly what TKIP prevent to happen . Here`s the main point or trick in discovered attack against WPA . Basically and based on standars , considering existance of TKIP we can only have two re-sends . But this new attack let us have something between 7 to 15 re-sends , making it possible to use chop-chop concept again , against WPA !
The trick is that , although TKIP monitor and prevent re-sending but there is a weakness in this monitoring and prevention process . New attack abuse a 802.11e feature; QoS .
In QoS , packets can be prioritaised . This happen by placing different packets in different queus . Like VoIP packets in queu one , normal data in qeue two and etc ... and QoS will manage these packets (marked with different queues) to give them priority to travel arround network. Here`s exactly where things break for TKIP . IEEE has not considered this little queue point while implementing TKIP , so if you use different QoS queues for each of your re-send attempts, TKIP will miss them! Although 802.11e seems to have only 4 available queues for QoS but the standard have actually 8 . Reasearchers discovered that there are still 8 more available for marking packets in some way . Each available queu means ability to re-send one more frame!
Low number of available queues is why this attack takes long time ( 900 seconds as they have announced the talk, which is for guessing a valid ARP packet and 16bits of to-guess values) . If we send too much (more than one re-send withing 60 seconds over each available queu) , TKIP will generate new key and we`re lost .

This research is a result of work of Erik Tews (The guy behind PTW attack) and Martin Beck , a member of aircrack-ng team .
There are some notes about this new attack.
  • This attack is valid only against WPA , and WPA2 ( Whith using AES as encryption) is considered safe. This is why I was happy at begining of the post! Since few years ago I've compleletly ignored WPA in my consultances and never accepted WPA to live just because some lame people out there in network can not upgrade their devices to support WPA2.
  • Don`t waste a single day if you`ve not upgraded your environment to WPA2 . Even with WPA2 you should NOT rely on the security of protocol and you`re highly recommended to use second layer of deffence by implementing IP-Sec or VPN over wireless links.
  • This attack will NOT lead to compromizing clear-text data directly and like chop-chop just let us gain access to the PRGA (used to ecnrypt frames).
  • This attack only works against traffic FROM access-point TO client . Client to AP traffic is considered safe.
  • This attack make it possible to inject packets in affected traffic stream! For example , it is possible to implement ARP Poisoning attack through abusing it.
  • This attack is still as slow as discovering one bit of frame per minute . This is why it`s effectiveonly against small packets like ARP or DNS. However it`s just time limitation , and most of hackers have enough time for what they`re planning to do!
  • This research is NOT a secret anymore . Researchers provided some PoC through SVN repository of the aircrack-ng suite . The tool is named TKIPtu-ng .

If you`re interested in reading more (technical) details about this new attack I recommend you reading these two sources . Wait few days and we`ll all get full details :)
Keep this in mind that this is just the discovery phase of this new attack vector! I belive there would be many improvements and new tricks based on this in future . So, there`s no reason to not to think to migrate to WPA2 .

I`m planning to practically test this attack ASAP , so I may update you through new post on this topic . Now I have a better motivation to unpack and use my 300mw Ubiquiti wireless adaptor :p

[Update 1 // November 9]
Well , the official paper related to their interesting work has just been published. Here it is.

October 24, 2008


You should have already heard about this out of band patch ,released by Microsoft. There are many points,failurs,good and bad news about this case . Everyone has his own story about this case worth writing a complete post ,article or analysis report and it`s still on going . I`ll try to sum them all in this post.

At first , we had MS08-067 patch from Microsoft . A critical vulnerability in Server Service that allows remote code-execution on ALL microsoft platforms. great!

The truth is that Microsoft`s patch was not really the begining of this story . This is one of those vulnerabilities microsoft got in wild , being used in targetted attacks against fully patched Windows XP/2003 systems . Unlike what many people have mentioned , detected in-wild use is not really a true worm . Targetted attacks happened through a trojan , which has been armed with an extra module to exploit this vulnerability and spread . Here you can read some details about catched case. That`s how we`ve got the buletin.

Now some details about who`s vulnerable and who`s not . Here comes most of bad news . ALL versions of windows (2000 / XP sp1~3 / 2003 sp0~2 / Vista / 2008) are vulnerable to this. The only difference is about Vista and windows server 2008 . These two platforms are less affected and that`s because vulnerable RPC endpoint is only accessible to authenticated users. In 2000/xp/2003 it`s possible to access and exploit the vector anonymously without any authention required.
On Vista & 2008 /GS and ASLR comes handy and make the situation _harder_ to attacker, for exploiting this bug . Since this is stack-overflow thing and there are many geeks out there already using techniques to bypass these , while Microsoft use "Likely DoS condition" term you shouldn`t have any doubt about possibility of successful code-execution on these platforms.
The authentication limitation on Vista/2008 shouldn`t either fool you. This may prevent mass attacks orginated by worms but if you`ve got a windows domain where your systems are placed in , attackers have already got some passwords to do a clean 'authenticated' compromise.
Finally, we have detault windows firewall rules ahead . Windows XP SP2 have it enabled by default and systems are protected from the interface windows consider it 'public' . BUT windows have file and print sharing EXCLUDED by default for 'Lan' interfaced which means no protection.
This table will give you idea about your current state ,based on your platform and configurations . Here`s related post on Microsoft security response blog about the case .

And if you`re digging for exploits , yes there are already some exploits available thorough some commercial services. Kostya of Immunity seems to be fighting with non-executable pages at the moment :) . With all of those protections around stack , it looks a complex case to solve on latest versions of windows.

Now Let`s look at the case from another point of view:
[Why this vulnerability has not been spotted before ?]

This is the question I was asking myself since the time I understood technical details behind it. Most odd and interesting point was that this bug is on the same service that has already been covered back in 2006 with MS06-040 . As Alex Sotirov mentioned in his blog post here , the vulnerability is even in same code area as ms06-040 ! He has de-compiled vulnerable function and mentioned what caused the overflow to happen . As it`s demistrified , you can see a complex loop for parsing supplied variables , one of them being a path.

This wasn`t enough for me though. After all of past hype on MS-RPC fuzzing and LOTS OF discussions about it in lists, books, fuzzers, conts, etc... in last months of 2008 we still have such a case . My first attempt was asking some of those who`re believed to be masters in this field , but later I came across a post by Michael Hovard, the SDL guy of Microsoft. In his blog post he answered why this bug was under radar all of these times. Not their manual code audits , nor their automated static analysis tools neither their fuzzing methodologies found this !
He has clearly discussed the case and why they faced with this total failur . I recommend you read the 'code analysis and review' section in his post to get most of what you want. While his statements about complexity of code segment and why it`s hard to spot the bug in code-review (manual or automated) I was really disappointed about the fuzzing topic . I think Dave Aitel should have something to say about this :)

Before reading Michael Hovards post , I had three questions about this case . His post answered only one of them, related to SDL . But two remainings are :
*What`s the real story behind MS08-067 ? Is it about lack of effectivenes in current MS-RPC fuzzing techniques (As we`ve read multiple times that MS-RPS has been fuzzed to death!) or it`s the story of effective warez getting leaked one a while ?

Iran`s X.25 NUA Directory

Well , long time ago this directory was a big secret for me ,as I`m sure thi s is the first ever published list of NUA, covering Iran`s X.25 network . Nowadays most of networks switched to IP based neworks and x.25 based access systems are part of history now . But in 2008 ,there are still a lot of blinking LEDs on x.25 modems out there ;)
So here`s the complete* list of dedicated NUA`s in official x.25 network of telecom co .
This is not the up to date version and now it`s about 4 years old , but hey there`s still a lot of fun behind it :)

And why I`m publishing this list today? Only "For educational purpose" . Also because I felt this list (which has been privately and limitedly published somewhere else) is spreading too much out there , without proper copy-right!!! So please do not abuse the list . If you`re unfamiliar with x.25 technology , don`t waste your time much for learning it from scratch. There are lots of new technologies out there , replacing it . The last word is that I`m NOT RESPONSIBLE for what you`re going to do with these numbers. If you don`t know how to use this list , just consider it a pice of very valuable but now-outdated information .
This list was useful for me back in the days it was fresh , as it could save me a lot of time doing the war-dial concept on x.25 networks . With this list you can skip all of your scanning toys and directly shoot your bullet to target :p . Note that the file is password protected , and "0ceb8fa5773ac8f973ab648aba0d8ae0" is the password.

Dowload the directory from here.

*For obvious reasons, I`ve removed some NUAs from this list . Most of removed items belongs to goverment or military or important banking systems. If you need them , you should already have them anyway !

October 22, 2008

Interesting piece of research on attacks against wired keyboard

After TEMPEST , this is the most interesting 'public' demonstration of exploiting electromagnetic emanations of wired keyboards . Researchers have not released the paper and technical details yet, but as mentioned in DailyDave , we should expect it .
MoD in Iran seems to have it`s own implementation on this and other TEMPEST research attack vectors , but I`m not aware of technical details of their work .

Yet another post about Foot-printing (The MAP!)

To many people this article may just be as useful as knowing who use what ,or which social networking is more popular in specific area of the world , but to me , it looks totally different!

Previously I`ve mentioned a tip on using social networks to gather more interesting information about targets , to have a more effective profiling and foot printing . This map looks like guide for using best match against your target . So based on it , would be choise #1 . Although this is not a complete map and lacks many info , but it`s just a good sample about the idea .
Finding a more detailed map ,showing more details about each country could be great . For example it would be cool to see popularity percentage of other netwroks in Iran .
Source of these information (based on notes in map) is Alexa site. It won`t be that hard to build your own map for other topics . Visiting this url for example , will tell you where most of facebook users come from .
There`s just one remaining note . Since some of these social networking sites are filtered in Iran (What`s the fucking reason to do it anyway ?!) results are not accurate . This is mostly because of using VPNs , proxy or bouncer systems .

October 19, 2008

بدون شرح

امروز بر حسب اتفاق سری به اکانت بلاگرم زدم و تعدادی از پست های نوشته شده اما منتشر نشده (به هر دلیل) را مجددآ مرور کردم . گفتم شاید بتوان چیز بدرد بخوری که بدون تغییر یا تکمیل آماده پست شدن باشد پیدا کرد .نوشته زیر نیز مربوط به تقریبآ یک سال پیش ---(10/2008) میباشد که آن زمان از پست کردن آن صرف نظر کرده و بحالت آرشیو در آوردم . اما با این اوضال گل و بلبل که اخیرآ پیش رو داشته ایم ، گفتم شاید خواندن این مورد نیز برای درک عمق فجایع ، خالی از لطف نباشد.
ویرایش شده در 10/2009---

از دوستان عاجزانه تقاضا می کنم قبل از مراجعه به لینک زیر پودر او . آر. اس به میزان کافی بصورت حل شده در آب در دسترسی داشته باشید . همچنین افراد دارای حساسیت های پوستی و ناراحتی قلبی و خانم های باردار از مراجعه به این لینک اکیدآ خودداری فرمایند.

در چنین شرایطی دقیقآ مشخص نیست که لوله آفتابه را باید به کدام سمت گرفت، مطبوعات و رسانه های فرهیخته یا .... ؟

October 2, 2008

Syngress always surprise me !

Some times while searing Amazon for new pubished books , I see strange or unexpected titles . For me , SYNGRESS has always been a pioneer in publishing strange titles ! This time , They`ve dedicated a complete book to the swiss army knide , NetCat ! I`m waiting to take a look at it ASAP. after that , I`ll update this post about contents and quality of conents. Oh and is really NetCat that complex that it requires five authors to work together for writing it`s dedicated book ?!

Well , I finished review of this brilliant book !
If you`re new to netcat (Oh if so ,why are you reading this blog?!!) , skip chapter 1 & 2 and go read NetCat`s original manual , then come back for later chapters. the only real useful tip is how to make a backdoor with netcat at end of chapter 2 ! Chapter 3 & 4 are about banner grabbing , service detection and enumeration . I`m just not sure why I read nmap,p0f,amap,etc... very often in these chapters . The title of book says "NetCat..." . Ok nevermind , I guess these are typo and spelling errors!!!
Same typo and spelling errors in chapter 5! In these ~30 pages you`ve to learn what we call nmap tips and tricks . They are cool , but not worth reading 30 pages . all of them could be explained in less than 5 pages ,among their details and describtions. Chapter 6 is trying to show even more tricks , following chapter 5 . The only positive point about this chapter is that it introduce other variants of NetCat , armed with encryption or backdooring capabilities . It could be summed in less than 5 pages too , not 40 pages! Chapter 7 in my opinion is the only usefull pice of this book (for network operators) as it show you how to troubleshoot some of common problems with help of netcat .
After all , I found 70% of this book NOT to be about NetCat . Remaining 30% is not even pure NetCat related and includes lot`s of unnecessary blah blah notes .
That`s it!

بات نت ها و روش های شناسایی و بررسی - قسمت سوم

در پست قبلی ، کلیاتی از مکانیزم های کاری و گسترش بات نت ها و همچنین انواع سیستم های هانی پات آورده شد. آنچه مرور شد در واقع مکانیزم ها و روش های مختلف برای شناسایی فعالیت بات نت ها و پس از آن بدست آوردن یک نمونه از بات برای بررسی های بیشتر بود . در ادامه بیشتر به بحث آنالیز نمونه ها نزدیک خواهیم شد و به کاربرد سیستم های Sandbox در این زمینه اشاره خواهم کرد .

صرف اینکه یک بات نت توسط مکانیزم های کنترل ترافیک شبکه یا سیستم های هانی پات ما شناسایی شده ، بررسی متوفف نمی شود . بلکه در طی چند مرحله بعدی اولآ می بایست ارتباطات برقرار شده توسط سیستمی که به این نمونه آلوده شده کنترل و بررسی گردد ، مشخص گردد که نمونه بدست آمده چه تغییراتی در سیستم اعمال می کند و در نهایت بررسی دقیقی که مشخص می کند فایل باینری نمونه دقیقآ چه کارد و قابلیت هایی را داراست .

یکی از ساده ترین راه هایی که برای آنالیز نمونه به ذهن می رسد ، اجرای نمونه بدست آمده بر روی یک سیستم ، و نظارت کردن بر فعالیت های انجام شده توسط باینری است . این روش بررسی را می توان به دو صورت دستی و خودکار انجام داد . در روش دستی نمونه بر روی یک سیستم (معمولآ تحت Virtual Machine) کاملآ پاک (Fresh Install) اجرا شده و در طی مدت فعالیت سیستم ، توسط ابزارهای مختلف و متعددی آنچه بر روی سیستم در حال رخ دادن است ثبت و بررسی می گردد . این بررسی می تواند شامل نظارت بر فعالیت های دیسک (خواند و نوشتن) ، فعالیت های شبکه (ترافیک ارسالی/دریافتی) ، فعالیت های انجام شده در رجستری ، API های فراخوانی شده ، آدرس های حافظه فراخوانی شده ، و بسیاری موارد دیگر باشد . مجموعه ابزارهای SysInternals که حقوق آن اخیرآ توسط مایکروسافت خریداری شده از جمله ابزارهای مفید در این زمینه می باشند.

روش دستی علاوه بر نیاز به دقت و مهارت در استفاده از ابزارهای مختلف زمانبر نیز می باشد . همچنین ممکن است نمونه تحت بررسی فعالیت هایی را انجام دهد که از دید ابزارهای متفرقه و روش بررسی دستی پنهان بماند و یا کنترل آنها بدین صورت مشکل باشد. به همین دلیل گرایش به سمت استفاده از مکانیزم های خودکار بررسی بیشتر است . در روش بررسی خودکار ، نمونه در یک محیط شبیه سازی شده ، مجازی و یا حتی واقعی اجرا شده و توسط مکانیزم های خاصی در سطح پایین (سیستم عامل و منابع سیستم ) تحت نظارت قرار می گیرد . این محیط معمولآ توسط ابزارها و اسکریپت های خاصی کنترل می گردد تا هر آنچه بر روی آنها اتفاق می افتد به دقت و با جزئیات ثبت گردد . سیستم های Sandbox موجود دقیقآ همین امکانات را در اختیار قرار می دهند . مفهوم Sandboxing تنها در بحث جاری کاربرد ندارد بلکه اساس و ریشه آنرا در محیط هایی مانند Java ، .Net و یا Flash(Action Script) می توانید دنبال کنید . اساس Sandboxing بر اجرای کد و دستورات ناشناخته (نا امن) در یک محیط کاملآ ایزوله از سیستم میزبان است ، بطوری که حتی در صورت مخرب بودم دستورات اجرا شده آسیب و تهدیدی متوجه سیستم میز بان نباشد .

Sandbox هایی که در حال حاضر موجود بوده و برای بررسی Malware ها از آنها استفاده می شوند ، علی رغم تعدد در نام های تجاری و قابلیت ، همگی از تکنیک های مشابهی استفاده می کنند . سیستم های کنونی یا از روش مانیتور کردن فعالیت های پروسس اجرا شده (در سطح فراخوانی API ها ) در یک سیستم عامل واقعی استفاده می کنند ، و یا نمونه در یک محیط شبیه سازی شده (Emulated) اجرا شده و API هایی که نمونه قصد استفاده از آنها را دارد را شبیه سازی کرده و پاسخ های از پیش برنامه ریزی شده ایی به آنها می دهند . در ادامه چند نمونه از شناخته شده ترین سیستم های Sandbox آورده شده اند .

هر یک از این سیستم ها از روش خاص خود برای پیاده سازی ایده Sandboxing استفاده کرده اند . CWSandbox با تکیه بر روش Process Injection ، یک DLL خاص را به نمونه اجرا شده تزریق کرده و بکمک آن API Call ها را تحت نظر گرفته و یا دستکاری می کند (API Hooking). این سیستم مبتنی بر استفاده از ماشین های مجازی (مانند VMware) است اگرچه به راحتی با استفاده از مکانیزم کاری نرم افزار DeepFreez امکان استفاده از یک ماشین واقعی را نیز به ما می هد.

در Norman Sandbox ، نمونه در یک محیط کاملآ شبیه سازی شده اجرا می گردد و از سیستم (یا سیستم عامل) واقعی استفاده نشده است . این روش اگرچه سریع و جمع و جور است ، اما در مقابل بسیاری از Malware های پیشرفته امروزی که قابلیت تشخیص سیستم های مجازی و یا حتی Sandbox را دارند ، ضعیف عمل می کند .

TTAnalyzer با استفاده از QEMU ،یک سیستم عامل ویندوزی را اجرا کرده و با روش API Hooking فعالیت ها را شناسایی می کند .

ایده بکار برده شده در SandNet کمی متفاوت است . در این سیستم ، نمونه ابتدا در یک سیستم و سیستم عامل واقعی اجرا می شود و پس از 60 ثانیه مکانیزم Sandbox سیستم را مجبور به Reboot می کند و پس از آن سیستم توسط روش PXE ( بوت از طریق شبکه) بوت شده و در سیستم عامل لینوکس اجرا شده دیسک سیستم عامل ویندوزی Mount شده و تغییرات حاصله در آن با یک نمونه پاک و دست نخورده مقایسه شده و تغییرات در رجیستری و فایل سیستم مشخص می گردد . سپس Image پاک بر روی دیسک بازنویسی شده و سیستم برای بررسی نمونه بعدی آماده می شود .

مکانیزم کاری Truman نیز بی شباهت به TTAnalyzer نیست . در سیستم Truman مجموعه ای از سیستم ها و ابزارها یک شبکه اینترنت مجازی را نیز در اختیار نمونه قرار می دهند . همچنین علاوه بر تغییرات ثبت شده بر روی دیسک ، یک کپی از حافظه سیستم عامل اجرا شده تحت Sandbox نیز آنالیز می شود .

روش کاری JoeBox تقریبآ مشابه سیستم Norman Sandbox می باشد ، اما تجربه شخصی من نشان داد که این سیستم بسیار بهتر و کامل تر از Norman عمل می کند .

سیستم Anubis در واقع ادامه و نمونه تکمیل شده سیستم TTAnalyze می باشد و تقریبآ از همان مکانیزم کاری بهره می برد .

خروجی هایی که سیستم های Sandbox در اختیار قرار می دهند در برخی موارد چیزی جز اطلاعات خام نیست و به خودی خود استفاده مستقیمی نمی توان از آن داشت . یکی از مهم ترین اطلاعاتی که در خلال بررسی نمونه می بایست بدست آید ، مکانیزم کاری سیستم Command & Control یا فرماندهی نمونه بات می باشد . در بسیاری از موارد این مکانیزم یا مبتنی بر IRC بوده و یا بر اساس Web می باشد . در صورتی که نمونه ما فاقد تمهیدات امنیتی باشد و بصورت شفاف با سرور فرماندهی خود ارتباط برقرار کند ، با دنبال کردن پکت های ارسالی و حتی استفاده از نرم افزارهای کلاینت معمولی می توان دامنه اطلاعات در خصوص سیستم C&C مورد استفاده توسط نمونه را گسترش داد . اما همیشه کار به همین راحتی نیست !

بسیاری از نمونه ها ارتباطات خود را بصورت رمز شده و یا Encode شده برقرار می کندد . در چنین شرایطی ، مرحله آنالیز دقیق و کامل نمونه شروع می شود . در این مرحله فایل باینری بدست آمده به روش Reverse Engineering مورد بررسی قرار گرفته و تک تک قابلیت های آن اعم از مکانیزم های حمله ، آلوده سازی ، سرقت اطلاعات و ... مورد بررسی قرار می گیرد .

موضوع بررسی و آنالیز malware ها و حتی مشخصآ بات نت ها بحثی بسیار گسترده و دربرخی موارد پیچیده می باشد . در طول این سه پست ارسالی من تنها سعی در معرفی تیتر وار _برخی_ از مباحث کردم . در صورت فراهم شدن مجال دوباره و علاقه شما ، می توان چند قسمت دیگر به این سری اضافه کرد تا مطالب مورد نظر شما را پوشش دهد .

September 30, 2008

بات نت ها و روش های شناسایی و بررسی - قسمت دوم

پیش از اینکه به سراغ بحث بررسی و آنالیز نمونه ها برویم و یا حتی آشنایی با سیستم ها و نرم افزارهایی که در این زمینه می توانند به ما کمک کنند ، لازم است بدانیم که با چه چیزی قرار است سر و کار داشته باشیم ؟ با Bot ها !

Bot ها را میتوان از دو دیدگاه مختلف مورد بررسی قرار داده و دسته بندی کرد. از لحاظ تکنولوژی مورد استفاده برای برقراری ارتباط با کنترل کننده مرکزی (Command & Control system) که به اختصار C&C خوانده می شود ، و یا از نظر نحوه و هدف گسترش و آلوده سازی قربانیان جدید .

انواع Bot ها از نظر تکنولوژی مورد استفاده برای C&C :

  • مبتنی بر IRC : استفاده از پروتکل و مکانیزم کاری IRC برای برقراری ارتباط
  • مبتنی بر Web : استفاده از پروتکل HTTP برای برقراری با کنترل کننده مرکزی و دریافت یا ارسال دستورات و داده ها
  • مبتنی بر پروتکل های Peer to Peer ( P2P) برای برقراری ارتباط با یکدیگر و C&C
  • مبتنی بر پروتکل های Instant Messaging ( مانند MSN ,YIM ,ICQ)
  • مبتنی بر پروتکل FTP

انواع Bot ها از نظر مکانیزم مورد استفاده برای انتشار و آلوده سازی قربانیان:

  • استفاده از ضعف های امنیتی سرویس های اجرا شده توسط سیستم عامل یا نرم افزارهای جانبی ( مانند RPC , WEB , FTP , Backup,…) و اکسپلویت کردن آنها برای حصول دسترسی به سیستم قربانی جدید
  • استفاده از ضعف های امنیتی نرم افزارهای تحت وب (ضعف های منتج به اجرای کد یا دستور سیستم عامل)
  • استفاده از ضمیمه های آلوده ارسال شده به روش Spamming و ترغیب کاربر به اجرای آنها
  • استفاده از ضعف های امنیتی نرم افزارهایی که اصطاحآ Client-Side خوانده می شوند (Browsers, Mail Clients ,Media players,…)
  • استفاده از اعتماد (Trust) موجود در شبکه های داخلی بر روی پروتکل هایی مانند FTP ,SMB ,NFS و یا شبکه های به اشتراک گذاری فایل (P2P File Sharing)
  • استفاده از روش حدث کلمات عبور ضعیف پروتکل هایی مانند SSH ,Telnet,… و دسترسی به سیستم جدید از طریق آنها

تا اینجا مشخص شد که با چه نوع نرم افزارها و روش های حمله ایی روبرو خواهیم شد . توضیحات مختصری در مورد هر یک از موارد دسته بندی های بالا را در کتاب Botnet که پیش از این معرفی کردم می توانید مطالعه کنید . موضوع بعدی که می بایست بدان پرداخته شود این است که اولآ آیا ما نمونه ایی از Malware ( یا صرفآ Bot) را در اختیار داریم یا نه ؟ در صورتی که نمونه از هر طریقی در اختیار ما قرار داده شده باشد می بایست به سراغ روش ها و تکنولوژی های مورد استفاده برای بررسی نمونه رفت . فرض ما بر این است که خود ما می بایست قادر به کشف و بدست آوردن نمونه ها نیز باشیم . با همین رویکرد می توان ادامه کار را از دو روش مختلف دنبال کرد :

  • تشخیص و شناسایی Bot ها بصورت غیر فعالانه (Passive) از طریق آنالیز ترافیک شبکه
  • تشخیص و شناسایی و شکار نمونه ها از طریق ایجاد تعامل به هر نحو ممکن با Malware( Bot)

هر دو روش مزایا و معایب خاص خود را دارند . از مزایای روش اول می توان به Passive بودن آن اشاره کرد و اینکه به راحتی قابل استفاده در سطح و حجم زیاد ترافیک است . در این حالت با تکیه بر روش های Anomaly Detection در کنار امضا ها (Signature & Rule) به تشخیص فعالیت های BotNet ها پرداخته می شود . از مهم ترین ضعف های این روش می توان به درصد خطای بالا و همچنین وابستگی زیاد به داشتن آگاهی قبلی از نمونه ها اشاره کرد . در کل این روش زمانی کارایی خود را نشان می دهد که شما قبلآ یک یا چند نمونه و حتی تکنیک خاص گسترش را آنالیز کرده اید و قصد شناسایی نمونه های مشابه را درترافیک عبوری شبکه دارید.

مواردی که در روش تشخیص از طریق آنالیز ترافیک مورد توجه هستند بشرح زیر می باشند :

  • مانیتور کردن ترافیک و جستجوی امضاهای خاص (Signature Based Monitoring)
  • مانیتور کردن ارتباطات برقرار شده از یا به آدرس ها و دامنه های Black-List شده
  • مانیتور کردن حجم بالا و غیر معقول ترافیک ایجاد شده توسط سیستم ها (scan,request,replay,connection,name resolution,…)
  • مانیتور کردن محتوای DNS Cache شبکه و کنترل موارد برای مشاهده هرگونه نام Blacl-list شده
  • مانیتور کردن سیستم های Cache و Proxy شبکه و استفاده از روش Pattern Matching
  • شناسایی و مانیتور کردن ارتباطات رمزنگاری شده مشکوک
  • مانیتور کردن فعالیت ها وترافیک هدایت شده به سمت DarkNet ها

برخی از سیستم ها و ابزارهایی که در این روش برای بررسی ترافیک مورد استفاده قرار می گیرند :

روش دوم بر خلاف روش اول ، کاملآ تعاملی بوده و شما بطور مستقیم و تحت شرایط خاص اقدام به بدست آوردن نمونه ها و اجرای آنها می کنید تا به ماهیت رفتاری آنها پی ببرید . در این حالت هدف اصلی این است که با در معرض خطر قرار دادن یک سیستم آسیب پذیر ( یا به ظاهر آسیب پذیر) منتظر حمله به این سیستم شویم و پس از وقوع حمله ، رفتارهای حمله کننده در خلال نفوذ به سیستم و حتی پس از آن (تغییرات اعمال شده در سیستم قربانی توسط حمله کننده) را بررسی کنیم . این کار در واقع همان مفهوم ایده HoneyPot می باشد که به روش ها و حالت های مختلف پیاده سازی می شود . چیزی که موضوع اصلی بحث کتاب Virtual Honeypots است .

در روش تعاملی اولین قدم (از دید حمله کننده یا همان Bot) نفوذ به سیستم است و قدم دوم آلوده سازی سیستم . ما نیز کار خود را برهمین اساس دنبال می کنیم . یعنی پیاده سازی و استفاده از ابزارها و روش های سفارشی شده برای شکار Bot ها ، و اجرا و آنالیز نمونه های بدست آمده در سیستم ها و محیط های خاص برای شناسایی رفتار آنها . برای اینکه بتوان یک نمونه را با موفقیت بدست آورد ، لازم است بدانیم که Bot ها از چه روش هایی به سیستم آسیب پذیر نفوذ می کنند ، و خیلی خلاصه رایج ترین آنها را پیش از این مرور کردیم . حال با توجه به همین روش های خاص ، ما می بایست سیستم های HoneyPot سفارشی شده ایی داشته باشیم تا بتواند بطور موفیت آمیز با یک یا چند نمونه از این روش ها تعامل داشته باشد . دقیقآ به همین دلیل است که برای شکار هر خانواده از Bot ها از نوع خاصی از Honeypot ها استفاده می شود . در ادامه جزئیات بیشتری را در مورد Honeypot ها را بازگو خواهم کرد .

با توجه به اینکه برای فریب یک حمله کننده (Bot) لازم است تا یک سیستم آسیب پذیر در دسترس و محدوده جستجوی وی قرار گیرد ، می بایست یا از یک سیستم واقعی و یا از یک مکانیزم شبیه سازی استفاده شود که وجود یک سیستم آسیب پذیر واقعی را شبیه سازی می کند . بر همین اساس هانی پات ها را به دو دسته کلی High-Interaction و Low-Interaction تقسیم می کنند .در انواع High-Interaction ایده و روش بر این اساس است که یک سیستم یا نرم افزار آسیب پذیر واقعی ، در شرایط کاملآ مانیتور شده و ایزوله شده ، در اختیار حمله کننده قرار می گیرد . این روش البته خطرات و ریسک های امنیتی خاص خود را دارد از جمله اینکه از خود هانی پات نیز ممکن است برای حمله به سایر سیستم ها استفاده شود .

برخی از شناخته شده ترین نمونه های هانی پات های High-Interaction :

همانطور که گفته شد ، سیستم های High-Interaction خود ممکن است مورد سو استفاده قرار گیرند . همچنین نگهداری و مدیریت این دسته از هانی پات ها غالبآ عملی مشکل و زمانبر بوده و نیازمند پیاده سازی مکانیزم های مختلفی برای خودکار سازی آنهاست . همه این موارد باعث گرایش به سمت ایده دوم یعنی سیستم های Low-Interaction می گردد . در این دسته ، درواقع یک نمونه تقلبی (Fake) و شبیه سازی شده از نرم افزارو یا سرویس آسیب پذیر در دسترس حمله کننده قرار می گیرد . میزان شبیه سازی باید آنقدر بالا باشد که حمله کننده به آن شک نکرده و مکانیزم حمله را متوقف نکند ، و همچنین شبیه سازی نباید آنقدر کامل و پیچیده باشد که بیش از حد نیاز و انتظار حمله کننده باشد . بطور مثال یک Bot که به یک سرویس خاص FTP حمله می کند ، تنها به دنبال دستور LOGIN و هدف قرار دادن آن است و هرگز درخواستی برای اجرای سایر دستورات مانند PUT و یا GET را ارسال نمی کند . بنا بر این نیازی به شبیه سازی آنها نیز نیست! البته این موضوع در عمل کمی پیچیده تر از این مثال ساده است . هانی پات های دسته Low-Interaction ممکن است یک نرم افزار و یا سرویس خاص را شبیه سازی کنند و یا حتی ممکن است قابلیت شبیه سازی یک سیستم عامل یا یک شبکه کامل را داشته باشند . بسته به اینکه هدف از راه اندازی هانی پات چه باشد ، از یک یا ترکیب چند سیستم هانی پات مختلف استفاده می شود . برخی از نمونه های هانی پات از دسته Low-Interaction بشرح زیر می باشند :

سیستم های هانی پاتی نیز طراحی و پیاده سازی شده اند که ترکیبی از قابلیت های High-Interaction و Low-Interaction را در اختیار قرار می دهند . این قبیل هانی پات ها غالبآ بصورت محصول و نرم افراری آماده مصرف در دسترس عموم نیستند , بلکه حاصل یک پروژه و یا کار تحقیقاتی می باشند که تنها مستندات و کلیات مکانیزم کاری آنها برای عموم منتشر شده است . به این دسته از سیستم ها Hybrid HoneyPot گفته می شود .برخی از این نمونه ها عبارتند از :

ماجرای هانی پات ها به همینجا ختم نمی شود . در ابتدای توضیحات گفتم که یکی از روش های مورد استفاده Bot ها برای گسترش و آلوده سازی سیستم های جدید ، استفاده از ضعف های امنیتی نرم افزار های Client-Side است . نکته مهم این است که بسیاری از BotNet ها امروزه بر استفاده از همین روش گسترش تآکید داشته و بطور بسیار گسترده از آن استفاده می کنند . این دسته از Bot ها را نمی توان با هیچ یک از سیستم های هانی پات که پیش از این به آنها اشاره کردم (بصورت خودکار) شناسایی کرد . دلیل این موضوع نیز این است که در همه موارد ( و روش های گسترش قبلی) این حمله کننده (Bot) است که به سراغ سیستم ما آمده و به آن حمله می کند . اما در روش گسترش مبتنی بر ضعف های امنیتی Client-Side ، این هانی پات است که باید به جستجوی حمله کننده بپردازد ! با توجه به اینکه که طیف بسیار زیادی از این حملات از طریق هدایت قربانی به سمت وب سایت های آلوده و مخرب صورت می گیرد ، هانی پات های نسل جدید نیز می بایست همانند یک کاربر اینترنت معمولی به مرور سایت های مختلف بپردارند تا مورد حمله واقع شوند . به این دسته از هانی پات ها اصطلاحآ Client Honeypot گفته می شود و همانند انواع قبلی در دو دسته High-Interaction و Low-Interaction جای می گیرند . فصل 8 کتاب Virtual Honeypots می تواند شروع بسیار خوبی برای آشنایی با مکانیزم کاری Client Honeypot ها باشد . تصویر زیر شمایی کلی از آنچه تاکنون به آن اشاره کردم را نشان می دهد .

در پست بعدی ، به معرفی سیستم های Sandbox و سایر نکات در خصوص بررسی Bot ها خواهم پرداخت.