شناسایی برنامه‌های روی وب سرور
در این بخش از دوره آموزشی OWASP-OTG به اولین بخش از استاندارد OTG با شناسه OTG-INFO-004 می پردازیم که مربوط به شناسایی برنامه‌های روی وب سرور می باشد.
خلاصه
یکی از گام‌های مهم در ارزیابی آسیب پذیری‌های وب اپلیکیشن، یافتن لیست برنامه‌هایی است که روی وب سرور اجرا می‌شوند. بسیاری از اپلیکیشن‌ها دارای آسیب پذیری‌های قابل اکسپلویت و روش‌های حمله معروف برای گرفتن دسترسی از راه دور هستند.
علاوه بر این، اغلب اپلیکیشن‌ها پیکربندی ضعیفی شده و حتی به روز رسانی نشده‌اند چرا که گمان می‌رود از این اپلیکیشن‌ها فقط در شبکه داخلی استفاده خواهد شد و به همین علت هیچ نوع ریسکی آن‌ها را تهدید نمی‌کند.
با افزایش وب سرورهای مجازی، مفهوم و معنی رابطه یک به یک بین آدرس IP و وب سرور کم رنگ‌تر می‌شود.
امروزه داشتن چندین وب سایت یا اپلیکیشن که نام دامنه آن‌ها به یک آدرس IP اشاره می‌کند، امری بعید نیست. این سناریو فقط محدود به محیط‌های هاستینگ نمی‌شود؛ بلکه محیط‌های شرکتی و حقوقی را نیز شامل می‌شود.
متخصصان امنیتی غالباً یک مجموعه IP برای تست و ارزیابی در دست دارند. مشکل اینجاست که آدرس IP داده شده هاست یک سرویس HTTP روی پورت 80 است؛ اما اگر ارزیاب امنیتی بخواهد با آدرس IP به آن دسترسی داشته باشد، با خطای “no web server configured at this address” مواجه می‌شود.
سیستم می‌تواند بعضی از اپلیکیشن‌ها را که مرتبط با آدرس دامنه مشخص نیستند مخفی کند. گستردگی و وسعت آنالیز بستگی به این دارد که ارزیاب می‌خواهد همه یا بخشی از اپلیکیشن‌هایی که از وجود آن‌ها با خبر است، تست کند.
بعضی اوقات، اطلاعات اولیه و جزئیات هدف کامل و غنی است. ممکن است ارزیاب امنیتی لیستی از آدرس‌های IP و نام دامنه‌های مرتبط با آن‌ها را در دست داشته باشد. با این اوصاف، شاید این لیست اطلاعاتی جزئی به ارزیاب انتقال دهد، مثلاً، بعضی از نام دامنه‌ها ذکر نشود و کلاینت از امر با خبر نباشد. این وضعیت بیشتر در سازمان‌ها و شرکت‌های بزرگ رخ می‌دهد.
از سایر مشکلاتی که بازه ارزیابی را تحت تاثیر قرار می‌دهند می‌توان به وب اپلیکیشن‌هایی اشاره کرد که لینک آن‌ها آشکار نیست و در جای دیگری به آن‌ها اشاره نشده است.
برای حل این مشکلات، باید وب اپلیکیشن کشف شود.
اهداف تست و ارزیابی
هدف از این تست و ارزیابی، کشف برنامه‌های روی وب سرور است.
چگونه تست کنیم؟
تست جعبه سیاه
کشف وب اپلیکیشن فرایندی است که هدفش شناسایی برنامه‌های سازمان است. برای همین منظور مجموعه‌ای از آدرس‌های IP یا به عبارتی یک بلوک شبکه یا مجموعه‌ای از نام دامنه‌ها یا ترکیبی از هر دو به ارزیاب امنیتی قبل از انجام هر تستی داده می‌شود.
در صورتی که در قرارداد تست نفوذ به صراحت ذکر نشود که اپلیکیشن موجود در یک آدرس مشخص تست شود، باید همه تلاش‌ها از جانب ارزیاب امنیتی صورت گیرد تا نتیجه تست و بررسی همه جانبه و جامع باشد. به عنوان مثال، نتیجه تست باید همه اپلیکیشن‌های قابل دسترسی از طریق هدف داده شده را مشخص کند.
مثال‌های بعدی، چند روش و تکنیک که برای تحقق این هدف مورد استفاده قرار می‌گیرند را بررسی می‌کنند.
نکته: بعضی از تکنیک‌های ذکر شده مربوط به وب سرورهای سمت اینترنت و سرویس‌های جست و جوی DNS و reverse IP و استفاده از موتورهای جست و جو است. مثال‌های آورده شده از آدرس‌های IP خصوصی مانند 192.168.1.100 که نشان دهنده آدرس‌های IP عمومی با هدف مخفی‌سازی و ناشناس بودن، استفاده می‌کنند.
سه عامل وجود دارند که بر تعداد اپلیکیشن‌های مرتبط با نام DNS یا آدرس IP تاثیر می‌گذارند:
1.URL های متنوع
شاخص‌ترین نقطه ورود به یک وب اپلیکیشن www.example.com که خلاصه شده و میانبر http://www.example.com/ است، می‌باشد.
با این حال، یک قانون کتبی نوشته وجود ندارد که همه وب اپلیکیشن‌ها را مجبور به شروع از “/” کند. به عنوان مثال، ممکن است همان آدرس فرضی گفته شده با سه وب اپلیکیشن مرتبط باشد:
http://www.example.com/url1
http://www.example.com/url2
http://www.example.com/url3
در این حالت، آدرس http://www.example.com/ با یک صفحه معناداری مرتبط نمی‌باشد و در صورتیکه ارزیاب امنیتی نداند چگونه به وب اپلیکیشن‌ها در سه آدرس url1، url2 و url3 دسترسی داشته باشد، هر سه وب اپلیکیشن از دید او مخفی خواهند ماند.
اگر مالک سایت نخواهد که وب اپلیکیشن‌ها را در حالت استاندارد در معرض عموم قرار دهد و آماده اطلاع‌رسانی به کاربران درباره موقعیت دقیق آن‌ها باشد، نیازی به انتشار آن‌ها با چنین قالبی وجود ندارد. این به معنی نیست که وب اپلیکیشن‌ها محرمانه هستند؛ بلکه به این معنی است که وجود و موقعیت آن‌ها صراحتاً منتشر نشده است.
2.پورت‌های غیر استاندارد
غالباً وب اپلیکیشن‌ها بر روی پورت‌های 80 و 443 که به ترتیب معرف http و https هستند، اجرا می‌شوند. با این حال باید بدانید که در پورت‌های 80 و 443 یک چیز جادویی خاصی اتفاق نمی‌افتد! در واقع، وب اپلیکیشن‌ها می‌توانند روی هر نوع پورت TCP دلخواد دیگری اجرا شوند و می‌توان با مشخص کردن شماره پورت با فرمت http[s]://www.example.com:port/ به آن دسترسی پیدا کرد.
3.هاست‌های مجازی
DNS اجازه می‌دهد تا یک آدرس IP به چندین نام نمادین اشاره کند. به عنوان مثال، آدرس IP 192.168.1.100 ممکن است به نام‌های DNS www.example.com، helpdesk.example.com و webmail.example.com اشاره کند. ضرورتی وجود ندارد که همه‌ی نام‌ها مربوط به یک دامنه DNS باشند.
رابطه 1 به N را مفهومی به نام هاست مجازی محقق می‌سازد. در صورتیکه فردی از وجود helpdesk.example.com و webmail.example.com با خبر نباشد، به وجود آن‌ها صرفاً از طریق وب اپلیکیشن www.example.com پی نخواهد برد.
رویکردهایی برای حل مشکل آدرس‌های متنوع و غیر استاندارد
هیچ راهی برای اطمینان حاصل 100% از وجود وب اپلیکیشن‌هایی با آدرس‌های غیر استاندارد وجود ندارد. از آنجایی که نام‌گذاری آن‌ها غیر استاندارد است، پس یک قانون و دستورالعمل برای نحوه نام‌گذاری آن‌ها نیز وجود ندارد. با این حال، چند روش و تکنیک وجود دارند که ارزیاب امنیتی می‌تواند از آن‌ها برای اخذ اطلاعات اضافی استفاده کند.
اولاً، اگر پیکربندی وب سرور صحیح نباشد، امکان رصد اپلیکیشن‌ها وجود دارد. اسکنرهای آسیب پذیری در این مورد می‌توانند کمک بسزایی داشته باشند.
ثانیاً، احتمال اینکه از صفحات دیگر وب به این وب اپلیکیشن‌ها ارجا داده شده باشد و به همین علت، توسط موتورهای جست و جو کشف و ایندکس شده باشند، وجود دارد. اگر ارزیاب امنیتی به وجود چنین اپلیکیشن‌های مخفی شک کند، می‌تواند از طریق جست و جو با عامل site در موتور جست و جو مانند site:www.example.com اپلیکیشن‌های مخفی را پیدا کند.
راهکار دیگر تست URLهایی است که می توانند نمایانگر اپلیکیشن‌های منتشر نشده باشند. به عنوان مثال، آدرس دسترسی به web mail می‌تواند به یکی از قالب‌های https://www.example.com/webmail، https://webmail.example.com یا https://mail.example.com باشد.
این راهکار برای رابط‌های مدیریتی نیز صدق می‌کند. بنابراین، جست و جو بر اساس دیکشنری یا حدس‌های هوشمندانه می‌تواند نتایجی مفیدی داشته باشند. اسکنرهای آسیب پذیری نیز می‌توانند در این مورد کمک بسزایی داشته باشند.
رویکردهایی برای حل مشکل پورت‌های غیر استاندارد
بررسی وجود یا عدم وجود وب اپلیکیشن روی پورت‌های غیر استاندارد کار آسانی است. اسکنر پورت مانند nmap می‌تواند با گزینه –sV نوع سرویس اجرا شده روی پورت‌ها را شناسایی کرده و سرویس‌های http[s] را روی پورت‌های دلخواه دیگر تشخیص دهد. البته لازم به ذکر است که اسکنر بایستی همه پورت‌های TCP که تقریباً 64000 عدد هستند را اسکن کند.
به عنوان مثال، دستور زیر همه پورت‌های آدرس 192.168.1.100 را اسکن خواهد کرد و تلاش خواهد کرد تا سرویس‌های اجرا شده روی هر پورت را شناسایی کند:
nmap –PN –sT –sV –p0-65535 192.168.1.100
کافی است تا خروجی دستور فوق را برای یافتن سرویس http یا ssl (به علت وجود احتمالی https) به دقت بررسی کنید. به عنوان مثال، خروجی دستور فوق به صورت خواهد بود:
Interesting ports on 192.168.1.100:
(The 65527 ports scanned but not shown below are in state: closed)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 3.5p1 (protocol 1.99)
80/tcp open http Apache httpd 2.0.40 ((Red Hat Linux))
443/tcp open ssl OpenSSL
901/tcp open http Samba SWAT administration server
1241/tcp open ssl Nessus security scanner
3690/tcp open unknown
8000/tcp open http-alt?
8080/tcp open http Apache Tomcat/Coyote JSP engine 1.1
ارزیاب امنیتی می‌تواند با بررسی خروجی فوق به نتایج ارزشمند زیر دست یابد:
• روی پورت 80 سرور http آپاچی در حال اجرا است.
• احتمال می‌رود که روی پورت 443، سرویس https اجرا می‌شود؛ اما بایستی با استفاده از روش‌هایی مانند مراجعه به آدرس https://192.168.1.100، این مورد تایید شود.
• روی پورت 901 رابط وب Samba SWAT در حال اجرا است.
• سرویس اجرا شده روی پورت 1241 سرویس https نیست؛ بلکه ssl-wrapped Nessus daemon است.
• روی پورت 3690 یک سرویس نامشخص اجرا می‌شود و اسکنر nmap قادر به شناسایی آن نبوده است.
• روی پورت 8000 نیز یک سرویس نامشخص در حال اجرا است. با این حال احتمال می‌رود که سرویس http باشد چرا که گاهی روی این پورت نیز سرور http اجرا می‌شود. برای اطمینان حاصل بیشتر، این پورت را بیشتر بررسی می‌کنیم:
$ telnet 192.168.10.100 8000
Trying 192.168.1.100…
Connected to 192.168.1.100.
Escape character is ‘^]’.
GET / HTTP/1.0
HTTP/1.0 200 OK
pragma: no-cache
Content-Type: text/html
Server: MX4J-HTTPD/1.0
expires: now
Cache-Control: no-cache
…
بررسی‌های فوق نشان می‌دهد که روی پورت 8000 سرور HTTP در حال اجرا است. البته ارزیاب امنیتی می‌تواند از روش‌های دیگری نیز مانند مراجعه آن آدرس توسط یک مرورگر، استفاده کند.
مرور متافایل‌های وب سرور برای یافتن نشتی اطلاعات
• روی پورت 8080 Apache Tomcat در حال اجرا است.
همین فرایند را می‌توانیم با استفاده یک اسکنر آسیب پذیری نیز انجام دهیم، به شرطی که اسکنر آسیب پذیری توانایی شناسایی سرویس‌های http[s] روی پورت‌های غیر استاندارد را داشته باشد.
به عنوان مثال، اسکنر Nessus قابلیت شناسایی سرویس‌های http[s] روی پورت‌های دلخواه دیگر را دارد و علاوه بر این، نتایج تست روی برخی آسیب پذیری‌های وب سرور و پیکربندی SSL سرویس‌های https را نیز ارائه خواهد داد. همانطور که قبلاً شرح داده شد، Nessus توانایی رصد اپلیکیشن‌های معروف یا رابط‌های وب که احتمالاً تشخیص داده نشده‌اند را دارد.
رویکردهایی برای حل مشکل هاست‌های مجازی
روش‌ها و تکنیک‌هایی وجود دارند که برای شناسایی نام‌های DNS مرتبط با آدرس IP تعریف شده x.y.z.t مورد استفاده قرار می‌گیرند.
DNS zone transfer
امروزه استفاده از این روش محدود شده است چرا که سرورهای DNS از این قابلیت استفاده نمی‌کنند. با این حال، ارزش امتحان را دارد! قبل از هر چیزی، ارزیاب امنیتی باید همه name serverهای x.y.z.t را پیدا کند. اگر نام شناخته شده مرتبط با آدرس x.y.z.t، www.example.com باشد، name serverهای آن را می‌توان با ابزارهایی مانند nslookup، host یا dig پیدا کرد.
در مثال زیر، با استفاده از دستور host، name serverهای www.owasp.org را شناسایی کرده‌ایم:
$ host -t ns www.owasp.org
www.owasp.org is an alias for owasp.org.
owasp.org name server ns1.secure.net.
owasp.org name server ns2.secure.net.
ممکن است از name serverها تقاضای zone transfer برای دامنه example.com شده باشد. اگر ارزیاب در این مرحله خوش شانس باشد، می‌تواند لیستی از محتویات DNS برای این دامنه را استخراج کند.
این اطلاعات شامل www.example.com و حتی سایر لینک‌های غیر آشکار همانند helpdesk.example.com و webmail.example.com می‌باشد.
تمامی اسامی که از zone transfer استخراج کرده‌اید را به دقت بررسی کنید. در مثال زیر سعی می‌کنیم که یک درخواست zone transfer به یکی از name serverهای owasp.org ارسال کنیم:
$ host -l www.owasp.org ns1.secure.net
Using domain server:
Name: ns1.secure.net
Address: 192.220.124.10#53
Aliases:
Host www.owasp.org not found: 5(REFUSED)
; Transfer failed.
DNS Inverse Queries
این فرایند بیشتر شبیه به فرایند قبلی است؛ با این تفاوت که وابسته به رکوردهای معکوس (PTR) است. به جای درخواست zone transfer، سعی کنید تا نوع رکورد را به PTR تغییر داده و کوئری را به آدرس IP هدف ارسال کنید.
اگر خوش شانس باشید، می‌توانید اطلاعات اسامی DNS را استخراج کنید. این تکنیک به نگاشت‌های IP به نام‌های نمادین، که ضمانت همیشگی ندارند، تکیه دارد.
Web-based DNS Searches
این نوع جست و جو همانند zone transfer است؛ اما وابسته به سرویس‌های تحت اینترنتی است که امکان جست و جوی اسامی روی DNS را می‌دهند. یکی از آن سرویس‌ها، Netcraft Search DNS واقع در http://searchdns.netcraft.com/?host است.
ارزیاب امنیتی می‌تواند لیستی از اسامی که مربوط به دامنه شما است را جست و جو کند. بعد از انجام این کار، از مرتبط بودن اسامی گرفته شده با هدف مورد ارزیابی اطمینان حاصل می‌کنند.
Reverse IP services
سرویس‌های معکوس IP شبیه به کوئری‌های معکوس DNS هستند؛ با این تفاوت که ارزیاب امنیتی به جای ارسال کوئری به name server، به اپلیکیشن تحت وب کوئری ارسال می‌کنند.
تعدادی از سرویس‌هایی از این قبیل موجود هستند. از آنجایی که نتایج این سرویس‌های با یکدیگر متفاوت هستند، توصیه می‌شود که از چند سرویس مجزا برای استخراج کامل‌ترین و جامع‌ترین اطلاعات استفاده کنید.
Domain tools reverse IP: http://www.domaintools.com/reverse-ip/
MSN search: http://search.msn.com
Webhosting info: http://whois.webhosting.info/
DNSstuff: http://www.dnsstuff.com/
Net Square: http://www.net-square.com/mspawn.html
tomDNS: http://www.tomdns.net/index.php
SEOlogs.com: http://www.seologs.com/ip-domains.html
مثال زیر، نتیجه و خروجی یکی از سرویس‌های معکوس IP فوق از آدرس 216.48.3.18 که آدرس IP سایت owasp.org است را نشان می‌دهد. سه مورد از نام‌های نمادین غیر آشکار که به آدرس IP داده شده اشاره می‌کنند، توسط این سرویس پیدا شدند.
Googling
در کنار روش‌های جمع آوری اطلاعات ذکر شده در تکنیک‌های فوق، ارزیاب امنیتی می‌تواند از موتورهای جست و جو برای بالا بردن دقت و بهینه کردن نتایج بررسی خود استفاده کند. این کار می‌تواند لینک‌ها و اپلیکیشن‌های غیر آشکار دیگری نیز نمایان کند.
برای نمونه، مثال قبل را در نظر بگیرید. ارزیاب امنیتی می‌توانست به گوگل و سایر موتورهای جست و جو یک کوئری بفرستد تا اطلاعات دامنه‌های کشف شده جدید را استخراج کند. تکنیک‌های گوگلینگ در بخش اسپایدرها، ربات‌ها و کرالرها توضیح داده شده است.
تست جعبه خاکستری
در واقع تست جعبه خاکستری غیر ممکن است چرا که این متدولوژی جعبه سیاه است و ارتباطی با میزان اطلاعات اولیه ارزیاب از پروژه و هدف ندارد.
ابزارها
• DNS lookup tools such as nslookup, dig and similar.
• Search engines (Google, Bing and other major search engines).
• Specialized DNS-related web-based search service: see text.
• Nmap – http://www.insecure.org
• Nessus Vulnerability Scanner – http://www.nessus.org
• Nikto – http://www.cirt.net/nikto2
مطالب این بخش توسط جناب آقای امیر ثروتی تهیه شده است.
