۱.۴) شمارش برنامه ها در وب سرور

Enumerate Applications on Webserver (fa-IR)

|WSTG-INFO-04|

خلاصه

یک مرحله مهم در آزمایش آسیب پذیری های برنامه های وب، این است که بفهمیم کدام برنامه های خاص روی سرور وب میزبانی می شوند. بسیاری از برنامه ها دارای آسیب پذیری ها و استراتژی های حمله شناخته شده هستند که می توانند برای به دست آوردن کنترل از راه دور یا سوء استفاده از داده ها مورد سوء استفاده قرار گیرند. علاوه بر این، بسیاری از برنامه ها اغلب به اشتباه پیکربندی می شوند یا بروزرسانی نمی شوند، زیرا این تصور وجود دارد که آنها فقط "داخلی" استفاده می شوند و بنابراین هیچ تهدیدی وجود ندارد. با گسترش وب سرورهای مجازی، رابطه سنتی نوع 1:1 بین یک آدرس IP و یک وب سرور در حال از دست دادن اهمیت اصلی خود است. غیر معمول نیست که چندین وب سا/یت یا برنامه داشته باشیم که نام نمادین آنها به آدرس IP یکسان منتقل شود. این سناریو به محیط های میزبانی محدود نمی شود، بلکه برای محیط های معمولی شرکت ها نیز اعمال می شود.

گاهی اوقات به متخصصان امنیتی مجموعه ای از آدرس های IP به عنوان هدف برای آزمایش داده می شود. می توان بحث کرد که این سناریو بیشتر شبیه یک درگیری از نوع آزمایش نفوذ است، اما در هر صورت انتظار می رود که چنین تخصیصی تمام برنامه های وب قابل دسترسی از طریق این هدف را آزمایش کند. مشکل این است که آدرس IP داده شده میزبان یک سرویس HTTP @در پورت 80 است، اما اگر آزمایش کننده باید با مشخص کردن آدرس IP به آن دسترسی پیدا کند (که تنها چیزی است که می دانند) "No web server configured at this address" یا پیامی مشابه را گزارش می کند. اما آن سیستم می تواند تعدادی از برنامه های وب مرتبط با نام های نمادین (DNS) نامرتبط را "پنهان کند". بدیهی است که میزان تجزیه و تحلیل عمیقاً تحت تأثیر این است که آزمایش کننده همه برنامه ها را آزمایش می کند یا فقط برنامه هایی را آزمایش می کند که از آنها آگاه است.

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

سایر مسائلی که بر دامنه ارزیابی تأثیر می گذارد توسط برنامه های وب منتشر شده در URL های غیر آشکار (به عنوان مثال، http://www.example.com/some-strange-URL) نشان داده می شود که در جای دیگری به آنها اشاره نمی شود. این ممکن است به اشتباه (به دلیل پیکربندی نادرست)، یا عمدی (به عنوان مثال، رابط های اداری تبلیغ نشده) اتفاق بیفتد.

برای رسیدگی به این مسائل، لازم است که برنامه وب را کشف کنید.

هداف آزمایش

• برنامه های در محدوده موجود در وب سرور را برشمارید.

چگونه آزمایش کنیم

کشف برنامه وب فرآیندی است با هدف شناسایی برنامه های وب در یک زیرساخت معین. بعدی معمولاً به عنوان مجموعه ای از آدرس های IP (شاید یک بلوک خالص) مشخص می شود، اما ممکن است شامل مجموعه ای از نام های نمادین DNS یا ترکیبی از این دو باشد. این اطلاعات قبل از اجرای یک ارزیابی (آزمایش)، خواه یک آزمون نفوذ به سبک کلاسیک باشد یا یک ارزیابی متمرکز بر برنامه، ارائه می شود. در هر دو مورد، مگر اینکه قوانین تعامل خلاف این را مشخص کند (به عنوان مثال، فقط برنامه واقع در URL را آزمایش کنید /http://www.example.com)، ارزیابی باید تلاش کند تا جامع ترین دامنه باشد، یعنی باید همه برنامه های قابل دسترسی از طریق هدف داده شده را شناسایی کند. مثال های زیر به بررسی چند تکنیک می پردازد که می توان برای دستیابی به این هدف به کار برد.

برخی از تکنیک های زیر برای وب سرورهای اینترنتی استفاده می شود، یعنی خدمات جستجوی مبتنی بر وب DNS و IP معکوس و استفاده از موتورهای جستجو. نمونه ها از آدرس های IP خصوصی (مانند 192.168.1.100) استفاده می کنند (مگر اینکه خلاف آن مشخص شده باشد) که نشان دهنده آدرس های IP عمومی هستند و فقط برای مقاصد ناشناس استفاده می شوند.

سه عامل وجود دارد که بر تعداد برنامه های مرتبط با یک نام DNS (یا یک آدرس IP) تأثیر می گذارد:

نقطه ورود واضح برای یک برنامه وب www.example.com است، به عنوان مثال، با این علامت کوتاه، ما به برنامه وب فکر می کنیم که منشا آن /http://www.example.com است (همین مورد برای HTTPS نیز صدق می کند). با این حال، حتی اگر این رایج ترین وضعیت است، هیچ چیز برنامه را مجبور به شروع در / نمیکند.

به عنوان مثال، یک نام نمادین ممکن است به سه برنامه وب مرتبط باشد. مانند:

http://www.example.com/url1 http://www.example.com/url2 http://www.example.com/url3

در این حالت، آدرس /http://www.example.com با یک صفحه معنادار مرتبط نمی شود و این سه برنامه پنهان می شوند، مگر اینکه آزمایش کننده صریحاً بداند چگونه به آنها دسترسی پیدا کند، یعنی آزمایش کننده url2 ،url1 یا url3 را بشناسد. معمولاً نیازی به انتشار برنامه های تحت وب به این روش نیست، مگر اینکه مالک بخواهد به صورت استاندارد در دسترس باشد و آماده باشد تا کاربران را از موقعیت مکانی دقیق آنها مطلع کند. این بدان معنا نیست که این برنامه ها مخفی هستند، فقط وجود و مکان آنها به صراحت تبلیغ نشده است.

2- پورت های غیر استاندارد (Non-standard Ports)

در حالی که برنامه های وب معمولاً روی پورت 80 (HTTP) و 443 (HTTPS) هستند، هیچ چیز جادویی در مورد این شماره پورت ها وجود ندارد. در واقع، برنامه های وب ممکن است با پورت های TCP دلخواه مرتبط باشند و می توان با تعیین شماره پورت به صورت زیر به آنها ارجاع داد: /http[s]://www.example.com:port. به عنوان مثال، /http://www.example.com:20000.

3- هاست (میزبان) های مجازی (Virtual Hosts)

ا DNS اجازه می دهد تا یک آدرس IP واحد با یک یا چند نام نمادین مرتبط شود. برای مثال، آی پی آدرس 192.168.1.100 ممکن است با DNS نام های www.example.com، helpdesk.example.com، webmail.example.com مرتبط باشد. لزومی ندارد که همه نام ها متعلق به یک دامنه DNS باشند. این رابطه 1 به N ممکن است برای ارائه محتوای مختلف با استفاده از به اصطلاح میزبان های مجازی منعکس شود. اطلاعاتی که میزبان مجازی مورد نظر ما را مشخص می کند در سربرگ میزبان HTTP 1.1 (Host header) تعبیه شده است.

کسی به وجود برنامه های وب دیگر علاوه بر www.example.com واضح مشکوک نیست، مگر اینکه از helpdesk.example.com و webmail.example.com اطلاع داشته باشد.

رویکردها به آدرس شماره 1 - URL های غیر استاندارد

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

اول، اگر وب سرور به درستی پیکربندی نشده باشد و امکان مرور فهرست را فراهم کند، ممکن است بتوان این برنامه ها را شناسایی کرد. اسکنرهای آسیب پذیری ممکن است در این زمینه کمک کنند.

دوم، این برنامه ها ممکن است توسط صفحات وب دیگر ارجاع داده شوند و این احتمال وجود دارد که توسط موتورهای جستجوی وب فهرست بندی و فهرست بندی شده باشند. اگر آزمایش کنندگان به وجود چنین برنامه های مخفی در www.example.com مشکوک شوند، می توانند با استفاده از اپراتور سایت جستجو کنند و نتیجه یک پرس و جو را برای site: www.example.com بررسی کنند. در میان URL های بازگردانده شده ممکن است یکی وجود داشته باشد که به چنین برنامه غیر آشکاری اشاره می کند.

گزینه دیگر این است که URL هایی را که احتمالاً کاندیدای برنامه های منتشر نشده باشند بررسی کنید. به عنوان مثال، ممکن است یک صفحه ایمیل وب از آدرس های اینترنتی مانند /https://www.example.com/webmail، https://webmail.example.com و یا /https://mail.example.com قابل دسترسی باشد. همین امر در مورد رابط های اداری نیز صدق می کند، که ممکن است در URL های مخفی (مثلاً یک رابط اداری Tomcat) منتشر شوند و در عین حال به جایی ارجاع داده نشده باشند. بنابراین انجام کمی جستجو به سبک فرهنگ لغت (یا "حدس زدن هوشمند") می تواند نتایجی را به همراه داشته باشد. اسکنرهای آسیب پذیری ممکن است در این زمینه کمک کنند.

رویکردها به آدرس شماره 2 - پورت های غیر استاندارد

بررسی وجود برنامه های وب در پورت های غیر استاندارد آسان است. یک اسکنر پورت مانند nmap می تواند با استفاده از sV- گزینه شناسایی سرویس را انجام دهد و سرویس های http[s] را در پورت های دلخواه شناسایی کند. آنچه مورد نیاز است اسکن کامل فضای آدرس پورت 64k TCP است.

برای مثال، دستور زیر با اسکن اتصال TCP، تمام پورت های آی پی 192.168.1.100 را باز می کند و سعی می کند مشخص کند که چه سرویس هایی به آن ها متصل هستند (فقط سوئیچ های ضروری نشان داده می شوند – nmap دارای مجموعه گسترده ای از گزینه ها است که بحث در مورد آنها خارج از محدوده است):

nmap –Pn –sT –sV –p0-65535 192.168.1.100

کافی است خروجی را بررسی کنید و به دنبال HTTP یا نشانه سرویس های پوشیده شده با TLS باشید (که باید برای تایید اینکه 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

از این مثال می توان دید که:

• یک سرور HTTP آپاچی روی پورت 80 اجرا می شود.
• به نظر می رسد یک سرور HTTPS در پورت 443 وجود دارد (اما این باید تأیید شود، مثلاً با مراجعه https://192.168.1.100 به مرورگر).
• در پورت 901 یک رابط وب Samba SWAT وجود دارد.
• سرویس در پورت 1241 HTTPS نیست، بلکه Nessus daemon با TLS پوشیده شده است.
• پورت 3690 دارای یک سرویس نامشخص است (nmap انگشت نگاری خود را - در اینجا برای وضوح حذف شده است - همراه با دستورالعمل هایی برای ارسال آن برای ادغام در پایگاه داده انگشت نگاری 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

<html>
...

این تایید می کند که در واقع یک سرور HTTP است. از طرف دیگر، آزمایش کنندگان می توانستند URL را با یک مرورگر وب بازدید کنند. یا از دستورات GET یا HEAD Perl استفاده کرد که تعاملات HTTP مانند آنچه در بالا داده شد را تقلید می کند (هر چند درخواست های HEAD ممکن است توسط همه سرورها رعایت نشود).

• آپاچی تامکت (Apache Tomcat) در پورت 8080 اجرا می شود.

همین کار ممکن است توسط اسکنرهای آسیب پذیری انجام شود، اما ابتدا بررسی کنید که اسکنر انتخابی قادر به شناسایی سرویس های HTTP[S] است که روی پورت های غیر استاندارد اجرا می شوند. به عنوان مثال، Nessus قادر است آنها را بر روی پورت های دلخواه شناسایی کند (به شرطی که دستور اسکن تمام پورت ها داده شود)، و با توجه به nmap، تعدادی آزمایش بر روی آسیب پذیری های وب سرور شناخته شده و همچنین پیکربندی TLS/SSL ارائه خواهد کرد. خدمات HTTPS همانطور که قبلا اشاره شد، Nessus همچنین می تواند برنامه های محبوب یا رابط های وب را که در غیر این صورت ممکن است مورد توجه قرار نگیرند (به عنوان مثال، یک رابط اداری Tomcat) شناسایی کند.

رویکردها به آدرس شماره 3 - میزبان های مجازی

تعدادی تکنیک وجود دارد که ممکن است برای شناسایی نام های DNS مرتبط با یک آدرس IP معین استفاده شود x.y.z.t.

انتقالات منطقه DNS ‫(DNS Zone Transfers)

این تکنیک امروزه استفاده محدودی دارد، با توجه به این واقعیت که انتقال منطقه تا حد زیادی توسط سرورهای DNS رعایت نمی شود. با این حال، ممکن است ارزش امتحان کردن را داشته باشد. اول از همه، آزمایش کننده ها باید سرورهای نام (name servers) سرویس دهنده x.y.z.t را تعیین کنند. اگر یک نام نمادین برای آن x.y.z.t شناخته شود (بگذارید باشد www.example.com)، سرورهای نام (name servers) آن را می توان با ابزارهایی مانند nslookup، host یا dig با درخواست رکوردهای DNS NS تعیین کرد.

اگر هیچ نام نمادینی برای آن x.y.z.t شناخته نشده باشد، اما تعریف هدف شامل حداقل یک نام نمادین باشد، آزمایش کنندگان ممکن است سعی کنند همان فرآیند را اعمال کنند و سرور نام (name server) آن نام را پرس و جو کنند (به این امید که x.y.z.t توسط آن سرور نام نیز ارائه شود). به عنوان مثال، اگر هدف شامل آدرس آی پی x.y.z.t و نام mail.example.com باشد، سرورهای نام دامنه example.com را تعیین کنید.

مثال زیر نحوه شناسایی سرورهای نام www.owasp.org را با استفاده از دستور host نشان می دهد:

$ 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.

اکنون ممکن است یک انتقال منطقه به سرورهای نام دامنه example.com درخواست شود. اگر آزمایش کننده خوش شانس باشد، لیستی از ورودی های DNS برای این دامنه را دریافت می کند. این شامل موارد بدیهی www.example.com و نه چندان آشکار helpdesk.example.com و webmail.example.com (و احتمالاً دیگران) خواهد بود. همه نام هایی را که با انتقال منطقه بازگردانده شده اند بررسی کنید و همه نام هایی را که مربوط به هدف مورد ارزیابی هستند در نظر بگیرید.

تلاش برای درخواست انتقال منطقه 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 ‫(DNS Inverse Queries)

این فرآیند مشابه فرآیند قبلی است، اما به رکوردهای DNS معکوس (PTR) متکی است. به جای درخواست انتقال منطقه، نوع رکورد را روی PTR تنظیم کنید و یک پرس و جو در آدرس IP داده شده صادر کنید. اگر آزمایش کننده ها خوش شانس باشند، ممکن است یک ورودی نام DNS را دریافت کنند. این تکنیک به وجود نقشه های نام نمادین IP ‫(IP-to-symbolic name maps) متکی است که تضمینی نیست.

جستجوهای DNS مبتنی بر وب (Web-based DNS Searches)

این نوع جستجو شبیه به انتقال منطقه DNS است، اما متکی به خدمات مبتنی بر وب است که جستجوهای مبتنی بر نام را در DNS امکان پذیر می کند. یکی از این خدمات، سرویس Netcraft Search DNS است. آزمایش کننده ممکن است فهرستی از نام های متعلق به دامنه انتخابی شما را جستجو کند، مانند example.com. سپس آنها بررسی خواهند کرد که آیا نام هایی که به دست آورده اند با هدف مورد بررسی مرتبط است یا خیر.

خدمات IP معکوس (Reverse-IP Services)

سرویس های IP معکوس مشابه پرس وجوهای معکوس DNS هستند، با این تفاوت که آزمایش کننده ها به جای سرور نام، یک برنامه مبتنی بر وب را درخواست می کنند. تعدادی از این خدمات در دسترس است. از آنجایی که آنها تمایل به بازگرداندن نتایج جزئی (و اغلب متفاوت) دارند، بهتر است از چندین سرویس برای به دست آوردن تجزیه و تحلیل جامع تر استفاده کنید.

• MxToolbox Reverse IP
• DNSstuff (خدمات متعدد در دسترس است)
• Net Square ‫(درخواست های متعدد در دامنه ها و آدرس های IP، نیاز به نصب دارد)

گوگل کردن (Googling)

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

برای مثال، با در نظر گرفتن مثال قبلی در مورد www.owasp.org، آزمایش کننده می تواند از گوگل و سایر موتورهای جستجو به دنبال اطلاعات (از این رو، نام های DNS) مربوط به دامنه های جدید کشف شده webgoat.org، webscarab.com و webscarab.net پرس و جو کند.

تکنیک های گوگل در تست: عنکبوت ها، ربات ها و خزنده ها توضیح داده شده است.

گواهی های دیجیتال (Digital Certificates)

اگر سرور اتصالات را از طریق HTTPS بپذیرد، نام مشترک (CN) و نام جایگزین موضوع (SAN) در گواهی ممکن است شامل یک یا چند نام میزبان (hostname) باشد. با این حال، اگر وب سرور گواهی قابل اعتمادی نداشته باشد، یا علامت های عام در حال استفاده باشد، ممکن است هیچ اطلاعات معتبری برنگردد.

ا CN و SAN را می توان با بازرسی دستی گواهی یا از طریق ابزارهای دیگر مانند OpenSSL به دست آورد:

openssl s_client -connect 93.184.216.34:443 </dev/null 2>/dev/null | openssl x509 -noout -text | grep -E 'DNS:|Subject:'

Subject: C = US, ST = California, L = Los Angeles, O = Internet Corporation for Assigned Names and Numbers, CN = www.example.org
DNS:www.example.org, DNS:example.com, DNS:example.edu, DNS:example.net, DNS:example.org, DNS:www.example.com, DNS:www.example.edu, DNS:www.example.net

ابزارها

• 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
• Nessus Vulnerability Scanner
• Nikto