August 23, 2008

Is my (RedHat) system compromized ?

Recently RedHat informed it`s Fedora and RHEL users about some successfull intrusions into their key servers responsible for providing update to end-users and also a key system used for signing Fedora packages . Read about these two cases here (fedora) and here (REHL) .
As you may have noticed, attackers backdoored and signed(!) OpenSSH package on RHEL server.

If you`ve configured your systems to automatically download and install offered updates , you can use the script provided here to check if you`ve installed backdoored OpenSSH server or not .

I`m afraid that this year we`ve seen too much check-blacklist.sh scripts ... !

Below is list of affected packages , based on SANS alert :

Red Hat Desktop (v. 4)
Red Hat Enterprise Linux (v. 5 server)
Red Hat Enterprise Linux AS (v. 4)
Red Hat Enterprise Linux AS (v. 4.5.z)
Red Hat Enterprise Linux Desktop (v. 5 client)
Red Hat Enterprise Linux ES (v. 4)
Red Hat Enterprise Linux ES (v. 4.5.z)
Red Hat Enterprise Linux WS (v. 4)

August 22, 2008

10 نکته در مورد استفاده از Nmap

تا بحال بارها و بارها توسط افرادی که در کار با این نرم افزار به مشکل برخورده اند مورد سوال قرار گرفته ام . گفتم شاید از طریق این پست بتوانم خیال خودم و بقیه را کمی راحت تر کنم!

بدون شک با این نرم افزار آشنا هستید و بارها از آن استفاده کرده اید ، اما آیا از تمام امکانات آن استفاده می کنید ؟ با در نظر داشتن چند نکته و استفاده کمی حرفه ایی تر از قابلیت های Nmap می توان نتایج بسیار بهتری گرفت . در این پست سعی می کنم چند مورد از این نکات را مرور کنم .

1-
سیستم عامل مناسب برای اجرا : گرچه Nmap تقریبآ هر سیستم عاملی را برای کار خود پشتیبانی می کند اما برخی شرایط ایجاد شده توسط سیستم عامل یا موجب کندی و افزایش درصد خطای کار نرم افزار میگردد و یا به کل استفاده از برخی قابلیت های نرم افزار را غیر ممکن می کند . پیشنهاد دوستانه من این است که تا حد ممکن از استفاده از ویندوز برای این منظور پرهیز کنید . دلیل آن محدودیت های ایجاد شده در سطح درایور ها و قابلیت های دسترسی خام (RAW) برای تولید پکت ها ، از زمان انتشار XP Sp2 به بعد است . نرم افرار ها و Patch های متعددی برای حل این مشکل ارائه شده ، اما Nmap تحت ویندوز هرگز به خوبی و دقت نسخه لینوکسی آن کار نکرده است .

2-لینک ارتباطی مناسب برای دسترسی به شبکه : ذات Nmap با ارتباطات مبتنی بر PPPoE مشکل دارد و این مورد بخصوص در ویندوز جدی است . بسیاری از قابلیت های اساسی مانند انواع Ping Scan و تولید بسته های سفارشی شده (ICMP,IGMP,TCP,..) در این حالت ( و تحت ویندوز) مختل می شود . لینک های Dial-up نیز گاهی این مشکلات را پدید می آورند . حد اقل کاری که برای فرار از این موارد می توان انجام داد ، استفاده از نرم افزار با پارامترهای روبرو است “Nmap –sT –P0 به دلیل اینکه Nmap نمی تواند بسته های دلخواه ICMP خود را تولید کند ، ادامه کار نرم افزار درکشف Host های جدید با مشکل روبرو می شود. تا حد امکان سعی کنید سیستمی که Nmap بر روی آن اجرا می شود از طریق یک لینک Ethernet به شبکه متصل شده باشد .حتی اگر این لینک در نهایت به یک مودم ADSL منتهی شده که بر اساس PPPoE کار می کند .

3-انتخاب روش مناسب برای شناسایی سیستم های فعال : Nmap به هر روشی که فکر کنید به شما امکان شناسایی Host های فعال (Alive) را می دهد. بصورت پیشفرض و در صورت امکان ، استفاده از ARP Scanning بهترین گزینه است . بگذارید نکته ای را گوشزد کنم . اگر مطمئن هستید که Host مورد نظر شما وجود دارد و اصطلاحآ Down نیست ، وقت خود را تلف نکنید . با استفاده از پارامتر "-P0" همینجا به این مرحله خاتمه دهید . Nmap با فرض فعال بودن Host کار خود را ادامه می دهد . در غیر اینصورت شما سه روش متفاوت برای شناسایی Host ها پیش رو دارید که عبارتند از ICMP Scan , Protocol Scan و Syn/Ack Scan . پیش از اینکه تصمیم بگیرید از کدام روش استفاده کنید ، به یک سوال جواب دهدید . آیا شبکه هدف درخواست های ICMP را کلآ فیلتر کرده و یا فقط برخی سیستم ها به ICMP پاسخ می دهند ؟ این موضوع را به Ping کردن چند IP شناخته شده در آن شبکه (مثلآ DNS یا Web Server شبکه ) امتحان کنید.
حال می توانیم بهتر تصمیم بگیریم . حتی اگر یک مورد جواب ICMP داشتید ، اولین گزینه استفاده از روش ICMP Discovery می باشد که با یک یا چند پارامتر می توان پاسخ به انواع مختلف درخواست های ICMP را بررسی کرد . "nmap –PE –PP –PM " با این دستور هر سه حالت Echo , Time Stamp و NetMask Request برای تولید درخواست های ICMP استفاده می شود.
بهتر است تنها به نتایج ICMP اطمینان نکنید و از روش دوم هم برای تکمیل شناسایی استفاده کنید که همان روش Syn/Ack Scan است . در صورتی که حدست می زنید شبکه توسط یک فایروال Stateful حفاظت شده ، استفاده از پارامتر "-PS" ( همان Syn Scan) و اگر نوع فایروال Stateless باشد ، استفاده از "-PA" ( یا Ack Scan) انتخاب مناسب است . این دو پارامتر نیاز به یک شماره پورت نیز دارند تا بسته Syn/Ack را به آن پورت ارسال کنند . رایج ترین پورت ها برای این منظور به ترتیب 80,25,22,443,21,113,23,53,554,3389 هستند. می توانید یک یا چند پورت مختلف و همچنین چند روش مختلف اسکن را در یک اجرا داشته باشید . Nmap از این نظر بسیار مهربان و پر حوصله است!

"nmap –sP –PE –PE –PM –PS80,22,23,53 –PA80,22,25,3389 {hosts}"
در نهایت اگر فکر می کنید باز هم چیزی از قلم افتاده ، میتوان از روش
Protocol Scan در کنار روش های بالا استفاده کرد ("-PO") .

4-سرعت اسکن : اشتباه در تنظیم این مورد می تواند موجب از دست دادن سیستم ها و پورت های باز زیادی شود . همچنین شناسایی شدن عمل پورت اسکن شما وابسته به همین مورد است . در ساده ترین حالت توسط پارامتر "-T{1~5}" میتوانید سرعت اسکن را تنظیم کنید . کند ترین حالت "-T1" است. در صورتی که قصد پویش شبکه بزرگی مثل کل شبکه داخلی سازمان خود را دارید ، بهتر است بجای افزایش سرعت بدین روش ، تعداد اسکن های موازی را افزایش دهدید . دلیل این موضوع این است که هرچه سرعت (پارامتر T ) بیشتر باشد ، Nmap دقت و زمان کمتری را صرف تلاش مجدد و انتظار برای دریافت پاسخ از سیستم های کند یا دارای Load بالا می کند . با استفاده از یک زمانبندی مناسب (-T4) و در عوض افزایش تعداد پویش های موازی —min-parallelism , --max-parallelism میتوانید بهترین نتیجه را در زمان کوتاه تر بگیرید. استفاده از پارامتر —min-rate و –max-rate به شما امکان تنظیم دقیق تر این مورد را می دهد.

5-پورت های مورد نظر : nmap بصورت پیش فرض بیش از 1400 پورت را بررسی می کند . در صورتی که نمی دانید در شبکه هدف به دنبال چه چیزی هستید ، می توانید به لیست پیش فرض اعتماد کنید . در غیر اینصورت ، توصیه میکنم تنها اقدام به پویش برای پورت هایی کنید که می دانید قرار است با آنها چه کاری انجام دهید . در این صورت لیست پورت های مورد نظر شما بطور یقین کمتر از 100 مورد خواهد بود. ممکن است فکر کنید پارامتر –F (Fast Scan) تعداد پورت های بسیار کمتری را نسبت به لیست پیش فرض بررسی می کند ، اما این اختلاف تعداد پورت ها کمتر از 250 پورت است و پارامتر –F نیز بیش از 1000 پورت را بررسی می کند . بررسی تمامی پورت های یک سیستم ( پارامتر –p- برای اسکن کل 65535 پورت ) را تنها زمانی انجام دهدید که فکر می کنید سرویسی غیر عادی و یا ناشناخته بر روی سیستم فعال است ، و یا لیست پیش فرض خروجی قابل توجهی به شما نمی دهد . مثلآ ، Hostname آن سیستم نام یا وظیفه ایی مهم را درذهن تداعی می کند اما هیچ سرویس خاصی بر روی پورت های استاندارد به چشم نمی خورد .
اگر قصد پویش یک سرویس خاص در محدوده بزرگی را دارید ، مثلآ شناسایی کلیه سرویس های SMTP در محدوده 217.218.x.x ، باید این را بدانید که با کمال احترام Nmap نرم افزار مناسبی برای این کار نیست . من استفاده از نرم افزاری مانند Dfind ( برای ویندوز) و یا Grabb ( برای لینوکس( را بعنوان Banner Scanner ترجیج می دهم . اسکنر های بسیار زیادی وجود دارند که هدف از طراحی آنها ، پویش و شناسایی یک سرویس خاص در سطح گسترده می باشد .

6-قابلیت Name Resolution : Nmap بطور پیش فرض سعی می کند Hostname مربوط به هر IP را شناسایی کند مگر اینکه توسط پارامتر "-n" این مورد را غیر فعال کرده باشیم . در صورتی که اسکن را در شبکه داخلی انجام نمی دهید ، و یا نیاز خاصی به Hostname های هر IP ندارید این مورد را غیر فعال کنید . Nmap در صورت نیاز بصورت خودکار سعی می کند از DNS Server که در تنظیمات شبکه شما آورده شده ، برای تبدیل IP ها به Hostname استفاده کند . در صورتی که واقعآ به Hostname های دقیق نیاز دارید ، پیشنها می کنم توسط پارامتر –dns-servers نرم افزار Nmap را برای استفاده از DNS Server های شبکه هدف تنظیم کنید . بدین ترتیب اطلاعات دقیق تری بدست خواهید آورد . همچینین بهتر است علاوه بر DNS Server رسمی شبکه ، کلیه DNS Server های فعالی که در شبکه هدف وجود دارند را نیز در این پارامتر بگنجانید .

7-ستفاده از قابلیت Version Detection : در صورتی که واقعآ به این قابلیت نیاز ندارید ، بی جهت از آن استفاده نکنید ! در شرایطی که تعداد زیادی سیستم قرار است مورد بررسی قرار گیرد ، استفاده از این پارامتر (-sV) زمان مور نیاز برای تکمیل اسکن را بسیار افزایش می دهد. در مورد تعداد کم Host این مورد زیاد چشمگیر نیست ، اما اگر قصد پویش یک کلاس B از شبکه ایی را داشته باشید ، تفاوت کاملآ محسوس است. Nmap همچنین قابلیت جالب و نسبتآ جدیدی دارد که ایده آن استفاده از زبان اسکریپت نویسی خاص Nmap ، برای استخراج هر چه بیشتر اطلاعات از یک سرویس است . این قابلیت توسط پارامتر "-sC" فعال می شود . با استفاده از Nmap Scripting Language شما به راحتی می توانید همزمان با پویش برای پورت های باز ، اقدام به Enumeration و یا حتی جستجو برای یک ضعف امنیتی خاص نیز بکنید . توصیه می کنم حتمآ در مورد این قابلیت Nmap اطلاعات بیشتری کسب کنید .

اخطار : در شبکه های داخلی بزرگ و گسترده که انواع و اقسام سرویس ها و نرم افزارهای قدیمی و یا نا شناخته ممکن است وجود داشته باشد ، پارامتر –sV براحتی می تواند موجب بروز اختلال گردد . نسخه های قدیمی سرویس TNS اوراکل و سیستم های مانیتورینگ قدیمی از جمله تلخ ترین تجربه های من هستند ! بهتر است ابتدا چنین سیستم هایی را شناسایی کرده و توسط پارامتر های "—exclude و یا –excludefile" دور آنها خط قرمز بکشید.

8-استفاده از قابلیت هایOS Detection
: با تمام دقت و کاربرد های مفید این قابلیت Nmap ، من تنها زمانی از آن استفاده می کنم که قصد جمع آوری اطلاعات از یک سیستم خاص را داشته باشم و هرگز از این قابلیت ("-O") در اسکن تعداد زیادی سیستم استفاده نمی کنم . اولین دلیل آن طولانی شدن زمان لازم برای انجام اسکن است . پیشنهاد می کنم هر گاه واقعآ نیاز داشتید بدانید یک Host خاص چه سیستم عاملی دارد ، از این قابلیت فقط برای همان سیستم استفاده کنید. گاهی اوقات ممکن است قصد داشته باشید دل به دریا بزنید و تمام زیر و بم یک شبکه را بدست آورید. در این صورت و با قبول تمامی ریسک ها و احتمالات میتوانید از پارامتر ("-A") استفاده کنید که عمل Service Detection , Script-based Detection , OS Detection و Traceroute را یکجا برای شما انجام می دهد .

9-برخورد با فایروال ها در اسکن : در بسیاری از موارد شما با شبکه ایی روبرو هستید که توسط یک فایروال محافظت شده . در این صورت ممکن است قوانین فایروال در کار شما اختلال ایجاد کند . در این صورت رعایت چند نکته کوچک ممکن است در بسیاری از موارد به شما کمک کند . اولین مورد عدم استفاده از اسکن پورت بصورت سریال است . ( پرهیز از استفاده از پارامتر –r ) . مورد بعد استفاده از یک Source-port مورد اعتماد فایروال است . استفاده از پارامتر –source-port 53 در بسیاری از موارد می تواند رفتار فایروال با شما را کمی خوشایند تر کند ! در نهایت ، استفاده از سرعت پایین در انجام اسکن می تواند عکس العمل های فایروال را کاهش دهد. همچنین در مواردی که متود پیش فرض اسکن (-sS یا همان Syn Scan) نتایج درستی به شما نمی دهد ، میتوانید روش سنتی اما قابل اطمینان تر TCP Connect را با استفاده از پارامتر –sT امتحان کنید .

10-آخرین و کلی ترین نکته : nmap یک پروژه زنده بوده و هر روز دوچار تغییراتی شده و مشکلات مختلف آن شناسایی و رفع می شود . سعی کنید همواره از آخرین نسخه آن استفاده کنید . همچنین مطالعه فایل های راهنما (man pages) مربوط به آن اطلاعات بسیار جالبی را در اختیار شما می گذارد . Nmap دارای مستندات و راهنماهای بسیار جامع ، دسته بندی شده و کامل می باشد . از آنها استفاده کنید!

August 21, 2008

Damn Vulnerable Linux!

Hey wait , don`t go wrong with title . It`s not about any new vulnerability linux , while it`s all about vulnerabilities in Linux !
If you`ve ever been a trainer trying to teach students how vulnerabilities may be abused in a practical manner , you`ve probably though about some ready-to-attack system designed to be vulnerable . This is some times time consuming and you just want something vulnerable our of the box . This is where DVL show it`s value .

DVL is a (live) system specially designed for training purpose with aim of being as vulnerable as possible ! You can consider it as war-game server in your training classes. I`ll give it a try in my next training camp , for sure .

August 14, 2008

Fake representations of Dan Kaminsky attack ?

Since release of details about the DNS flaw uncovered by Dan Kaminsty , I`ve seen some notes , tools or PoCs with a note somethin like "Ability to attack _patched_ dns servers..." .
While there`s no doubt about theorical possibility of that , they are actually kind of fake capabilities in real-world scenarios . Last case I came across is available here . As the write r commented :

# named -v
BIND 9.5.0-P2

BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range. Usually attacking server is able to send about 40-50 thousands fake replies before remote server returns the correct one, so if port was matched probability of the successful poisoning is more than 60%. Attack took about half of the day, i.e. a bit less than 10 hours. So, if you have a GigE lan, any trojaned machine can poison your DNS during one night...

What made Kaminsky`s attack so critical (and interesting) was it`s ability to poison
a remote server,
over internet,
in few minutes,
with acceptable amount of packets,
with very-high (>90%) success rate.

The key of success was lack of source-port randomization , which is addressed now . Without that , attempting to poison the server is no more the Kaminsky attack vector . it`s just soooooo old known weakness in DNS protocol that is really hard to exploit in real-world scenarios. Guessing corred ID for DNS response is really hard and resource intensive in normal environments, and some times totally impossible .

Attacking patched DNS servers requires HIGH bandwith and it takes SO LONG over remote systems . As high as a direct Gigabit ethernet link , and as long as 10 hours over mentioned link , with only 60% success rate . Have you ever compared the lab scenario mentioned above ,with one of your cases ?
If we`re already in same network segment of DNS server, thare are much better tricks to use. Why keep sending fake responses at Gigabit speed for at least 10 hours to guess the correct ID , while we can discover it with few fake ARP packets to implement an ARP poisoning attack to hijack DNS traffic and capture the right ID we`re looking for ? :)
Sure both of these can be easily detected . But compare a 10h long pick in MRTG graph with a few seconds long pick . Also the DNS related pick shows full bandwith useage while ARP one is minor , compared to DNS . So are we crazy to use the hardcore dns poisoning way ? :)

Extend above notes for a case were you`re attacking a remote DNS server over internet. I doubt if many of attackers out there are able to gain access to a host with 1Gbit internet bandwidth , and even if they have such host , their victim have same network bandwidth . And administrators of targetted server keep watching you flooding them for hours and hours...
Let`s forget it at all . You`ve not visited my blog at all , ok ? ;)

Btw , Since my past blog post about DNS , two of major DNS servers I was worry about tried to address their vulnerabilities . NIC and DCI dns servers looks safe to this attack vector now . About NIC I can`t be sure yet, as they`ve just blocked recursive queries . I hadn`t chance to check randomness of source-ports . If you`re using any of their DNS servers , check it and let me know about results here as a comment .

August 8, 2008

Your single source of web-hacking tools

There`s no project in security that you have nothing to do with web-applications anymore . So how do you orchestrate your tricks and tools ? OWASP prepared a great resource , listing almost any useful tool released so far for auditing web-applications and related systems . Here it is :

http://www.owasp.org/index.php/Phoenix/Tools

Be warned that it should be considered only a kind of reference . Most of listed tools are copies of original ideas provided and implemented in some other tools . If there was something like "Top 10 web-hacking tools" it could be much more interesting and useful IMO , but that`s how OWASP like to manage it :)

August 2, 2008

All country top-level DNS servers belongs to...

So , everyone talked about recent attack against DNS protocol uncovered by Dan Kaminsky (CVE-2008-1447) . Some rumors , some speculations , some partial leakages and finally accidental leakage of full details (Item titled "Reliable DNS Forgery in 2008") followed by release of few tools and exploits for implementing mentioned attack was what happened in past weeks .
I`m not going to repeat told stories about the case yet another time , but focus on something more seriously . Such cirtical holes in internet infrastructure can easily lead to serious problems if not handled properly . they`re considered high-risk , but if people decide to skip them for any reason , they will become terrible cases . This is exactly what seems to be going on here in Iran . About one month past the patch-day ( 8th July ) but almost non of those who must have already patched their systems taken any (effective) action . I`m not talking about internal vulnerable DNS servers nor low-level ISP`s who provide internet to wide range of users , but talking about so-called top level DNS providers in country , back-bone providers or even the infrastracture known as authority of .ir domains ! let`s check it in more visual way :




DCI which is likely to be Iran`s top-level internet (and DNS, among Nic.ir) provider ,is providing service to 40 other networks and each of these 40 links are provider of number of other neworks. SINET is one of these 40`s ,which is up-stream of NIC.ir . Check "Import" items in this link which shows who`s using DCI as it`s up-stream link . The bad thing about this vulnerability is that if you poison a top-level vulnerable DNS server , any down-stream DNS servers which forward their queries to vulnerable up-stream will get poisoned too . In more clear sentence , if you poison a top-level DNS , you`ve automatically poisoned all down-stream servers in a hierarchically manner .
Here`s the scary part of story . Almost all of mentioned up-stream DNS servers are still vulnerable ! To get more into details , I picked up few ( 15 ) random popular ISPs in country and repeated the test , for not just relying on top-level results :
Out of 15 checked ISP`s , 9 of them were directly making their users to forward queries to one of mentioned up-stream (top-level) DNS servers .
Out of 15 , only 2 of ISP`s turned to be secure against remote attacks. In remaining 13 , 6 of them had Open DNS servers which allow requrcive queries from anywhere in internet , but others were configured to accept recursive cueries only from their users (internal range). Althout better than being a wore DNS , but still vulnerable to attack.
And the Gold winner of the case IMO is NIC.IR. I`m sorry to say that authoritve DNS server of .ir domains is vulnerable too !
I`ve contacted few of top-levels through email and provided details among proof of concept on their systems but non of them replayed nor patched yet.

If you care about your security , I highly recommend you to use OpenDNS servers till our lazy DNS maintainers decide to patch .

A note for DNS admins :
Patching the server may not be enough ! Since core of the attack relys on weak source-port randomization , even a patched DNS server may remain vulnerable to attack if it`s behind a Firewall, NAT or some kind of forwarder system which brings your DNS to internet. Test your DNS servers both from internal and external zones to become sure about it . If you`re not sure how to check , try using this free checking service and review results . You should see any poor/weak item there in report .
So what if you can`t directly patch your vulnerable server ? well , first of all this is one of those vulnerabilities that you MUST patch . But as a partial workaround you may place your DNS behind iptables (or other good *nix firewalls) and make firewall do the port-randomization for you.

Note to Users :
Check the same test link provided above . If you see any poor/weak sign , it`s time to call your ISP and ask them to patch . This is not because you care about security of your ISP , but you care about your own security .