Enumeration حرفه‌ای؛ از پورت باز تا شناخت سرویس

Professional Enumeration
0 دیدگاه
۱۴۰۵-۰۶-۲۸ ۱۰:۵۴:۴۵

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

اما یک سؤال مهم باقی می‌ماند:

وقتی یک پورت باز پیدا کردیم، قدم بعدی چیست؟

اینجا وارد مرحله‌ای می‌شویم که به آن Enumeration می‌گوییم.


۱. Enumeration چیست؟

در Recon معمولاً اطلاعات کلی درباره هدف جمع می‌کنیم.

اما در Enumeration تلاش می‌کنیم اطلاعات دقیق‌تری از سرویس‌ها و برنامه‌ها به دست بیاوریم.

به زبان ساده:

Recon
  ↓
چه چیزی وجود دارد؟
  ↓
Enumeration
  ↓
این چیز دقیقاً چیست و چگونه کار می‌کند؟

مثلاً:

3000/tcp
   ↓
Open
   ↓
HTTP
   ↓
Web Application
   ↓
Technology
   ↓
Endpoints
   ↓
Functionality

هدف ما این نیست که فقط «اطلاعات بیشتری» جمع کنیم.

هدف این است که اطلاعات مرتبط و قابل استفاده برای تحلیل امنیتی به دست بیاوریم.


۲. سناریوی آزمایشگاه

هدف ما همان آزمایشگاه قسمت قبل است:

Target:
localhost

Application:
OWASP Juice Shop

Port:
3000/tcp

اگر Juice Shop اجرا نیست، ابتدا آن را اجرا کن:

docker run --rm -p 3000:3000 bkimminich/juice-shop

سپس:

http://localhost:3000

را باز کن.


۳. اولین بررسی

ابتدا وضعیت پورت را بررسی می‌کنیم:

nmap -p 3000 localhost

هدف این دستور بسیار ساده است:

آیا TCP/3000 در دسترس است؟

حالا Service Detection را امتحان می‌کنیم:

nmap -sV -p 3000 localhost

گزینه -sV تلاش می‌کند نوع و نسخه سرویس را شناسایی کند.

اما یک نکته حرفه‌ای:

خروجی ابزار را «حقیقت مطلق» در نظر نگیر.

Nmap بر اساس پاسخ‌هایی که دریافت می‌کند حدس و شناسایی انجام می‌دهد. همیشه باید نتیجه را با روش‌های دیگر بررسی کنیم.


۴. بررسی HTTP

حالا مستقیماً با سرویس وب صحبت می‌کنیم.

curl -I http://localhost:3000

گزینه -I باعث می‌شود Headerهای HTTP Response را ببینیم.

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

HTTP/1.1 200 OK
Content-Type: text/html
...

عدد وضعیت HTTP بسیار مهم است.

مثلاً:

200 → درخواست با موفقیت پاسخ داده شده
301/302 → Redirect
401 → نیاز به احراز هویت
403 → دسترسی ممنوع
404 → منبع پیدا نشد
500 → خطای سمت سرور

اما به یک نکته دقت کن:

هر Status Code به‌تنهایی یک آسیب‌پذیری نیست.

ما فقط در حال جمع‌آوری شواهد هستیم.


۵. Response را مثل یک Pentester بخوان

وقتی Response دریافت می‌کنی، فقط Status Code را نگاه نکن.

سؤال‌های ما:

Status Code چیست؟
Content-Type چیست؟
Cookie ارسال شده؟
Redirect وجود دارد؟
Header امنیتی وجود دارد؟
اطلاعاتی درباره فناوری افشا شده؟

مثلاً:

Response
│
├── Status
├── Headers
├── Cookies
├── Body
└── Redirects

هر کدام می‌تواند یک سرنخ باشد.


۶. Cookie چیست؟

یکی از مهم‌ترین بخش‌های Web Pentesting، Session است.

برای مثال ممکن است سرور Cookieای ارسال کند:

Set-Cookie: session=...

Cookie می‌تواند برای نگهداری اطلاعات مربوط به Session استفاده شود.

اما اینجا نباید سریع نتیجه بگیریم:

«Cookie وجود دارد، پس آسیب‌پذیری داریم.»

خیر.

باید بررسی کنیم:

  • Cookie چگونه تولید می‌شود؟
  • آیا Secure است؟
  • آیا HttpOnly است؟
  • SameSite چگونه تنظیم شده؟
  • Session چگونه مدیریت می‌شود؟

این موضوع در بخش Web Security به‌صورت عمیق‌تر بررسی خواهد شد.


۷. مشاهده صفحه اصلی

حالا صفحه را در مرورگر باز کن:

http://localhost:3000

به جای اینکه فقط ظاهر سایت را ببینی، شروع به ساختن نقشه کن.

مثلاً:

Application
│
├── Home
├── Login
├── Register
├── Search
├── Products
├── Basket
└── Account

این نقشه هنوز کامل نیست.

ما باید آن را با اطلاعات بیشتری توسعه دهیم.


۸. Endpoint چیست؟

یک Endpoint را می‌توان به‌صورت یک نقطه قابل‌دسترسی در یک برنامه یا API در نظر گرفت.

برای مثال:

/api/products
/api/users
/api/login

این Endpointها می‌توانند عملکردهای مختلفی ارائه کنند.

در تست نفوذ، شناخت Endpointها اهمیت زیادی دارد، چون هر Endpoint می‌تواند منطق، ورودی و کنترل دسترسی مخصوص خودش را داشته باشد.


۹. DevTools؛ یک منبع مهم اطلاعات

مرورگر را باز کن و:

F12

را بزن.

سپس وارد بخش:

Network

شو.

حالا صفحه را Refresh کن.

در این قسمت درخواست‌هایی را می‌بینی که مرورگر به برنامه ارسال می‌کند.

ساختار ذهنی ما:

Browser
   ↓
HTTP Request
   ↓
Server
   ↓
HTTP Response
   ↓
Browser

در Web Pentesting، یادگیری همین رفت‌وبرگشت یکی از پایه‌ای‌ترین مهارت‌هاست.


۱۰. Request را تحلیل کنیم

یک Request معمولاً اطلاعاتی شبیه این دارد:

GET / HTTP/1.1
Host: localhost:3000
User-Agent: ...
Accept: ...
Cookie: ...

فعلاً روی چند بخش تمرکز کن:

Method

مثلاً:

GET
POST
PUT
DELETE

Path

مثلاً:

/

یا:

/api/...

Headers

اطلاعات جانبی Request.

Cookies

اطلاعات مربوط به Session یا تنظیمات سمت کاربر.


۱۱. تفاوت GET و POST

دو Method بسیار مهم:

GET

معمولاً برای دریافت اطلاعات استفاده می‌شود.

GET /products

POST

معمولاً برای ارسال داده به سرور استفاده می‌شود.

POST /login

این تفاوت در تست امنیتی اهمیت زیادی دارد، چون نوع Request روی نحوه پردازش ورودی‌ها تأثیر می‌گذارد.


۱۲. Enumeration یعنی ساختن تصویر

فرض کن تا اینجا این اطلاعات را داریم:

Target:
localhost

Port:
3000

Protocol:
HTTP

Application:
Web Application

Endpoints:
Multiple

Authentication:
Present

Session:
Cookie-based

API:
Present

حالا دیگر با یک «پورت 3000» مواجه نیستیم.

ما یک تصویر اولیه از برنامه داریم.

             Web Application
                    │
       ┌────────────┼────────────┐
       ↓            ↓            ↓
 Authentication   Products      API
       │            │            │
      Login       Search      Endpoints
      Register      │
                    ↓
                 Basket

این دقیقاً همان چیزی است که Enumeration باید برای ما ایجاد کند.


۱۳. یک اشتباه رایج

تازه‌کارها معمولاً می‌پرسند:

«چه ابزار دیگری اجرا کنم؟»

اما سؤال حرفه‌ای این است:

«الان چه چیزی را نمی‌دانم؟»

مثلاً اگر نمی‌دانیم:

چه سرویس‌هایی وجود دارند؟

از Service Detection کمک می‌گیریم.

اگر نمی‌دانیم:

چه Endpointهایی وجود دارند؟

روی ساختار برنامه و HTTP Traffic تمرکز می‌کنیم.

اگر نمی‌دانیم:

چه فناوری‌هایی استفاده شده؟

Technology Identification انجام می‌دهیم.

یعنی:

Question
   ↓
Technique
   ↓
Tool
   ↓
Evidence
   ↓
Analysis

نه اینکه:

Tool
 ↓
Tool
 ↓
Tool
 ↓
Tool

۱۴. ساخت Recon Notebook

حالا اطلاعاتمان را مرتب می‌کنیم:

================================
TARGET
================================

Host:
localhost

Port:
3000/tcp

Protocol:
HTTP

Application:
OWASP Juice Shop


================================
SERVICES
================================

3000/tcp
Web Application


================================
APPLICATION SURFACE
================================

Authentication
Products
Search
Basket
Account
API


================================
OPEN QUESTIONS
================================

Technology Stack:
[بررسی شود]

API Endpoints:
[بررسی شود]

Authentication Flow:
[بررسی شود]

Authorization:
[بررسی شود]

Session Management:
[بررسی شود]

این قسمت آخر بسیار مهم است.

Open Questions

یعنی هنوز چه چیزهایی را نمی‌دانیم.


۱۵. Enumeration بدون هدف چه مشکلی دارد؟

اگر بدون برنامه اطلاعات جمع کنیم، خیلی سریع با حجم زیادی از داده مواجه می‌شویم.

مثلاً:

1000 Endpoints
500 Parameters
200 Headers
50 Technologies

اما کدام مهم است؟

اینجاست که تحلیل اهمیت پیدا می‌کند.

یک Pentester باید بتواند:

Raw Data
    ↓
Relevant Data
    ↓
Security Context
    ↓
Potential Finding

را انجام دهد.


۱۶. تمرین عملی

در آزمایشگاه خودت این مراحل را انجام بده:

مرحله ۱

nmap -sV -p 3000 localhost

نتیجه را ثبت کن.

مرحله ۲

curl -I http://localhost:3000

Headerهای مهم را یادداشت کن.

مرحله ۳

صفحه را در مرورگر باز کن.

مرحله ۴

با F12 وارد Network شو.

مرحله ۵

صفحه را Refresh کن.

مرحله ۶

چند Request را بررسی کن.

برای هر Request این موارد را ثبت کن:

Method:
Path:
Status:
Request Headers:
Response Headers:
Cookies:

۱۷. چالش قسمت سوم

بدون اینکه هنوز سراغ Exploit بروی، برای Juice Shop یک نقشه اولیه بساز.

حداقل این موارد را پیدا و دسته‌بندی کن:

Authentication
User Functions
Product Functions
Search
Basket
API
Static Resources

سپس برای هرکدام بنویس:

What do I know?
What don't I know?
What should I investigate next?

این سه سؤال یکی از مهم‌ترین عادت‌های یک Pentester حرفه‌ای هستند.


جمع‌بندی

تا اینجا مسیر ما:

Scope
  ↓
Recon
  ↓
Port Discovery
  ↓
Service Detection
  ↓
HTTP Analysis
  ↓
Application Enumeration
  ↓
Attack Surface Mapping

است.

اما هنوز هیچ Exploitی اجرا نکرده‌ایم.

چون هنوز زمانش نرسیده.

ابتدا باید بفهمیم برنامه چگونه کار می‌کند.

هرچه Target را بهتر بشناسی، فرضیه‌های امنیتی دقیق‌تری می‌سازی.


قسمت بعد

در قسمت ۰۴ وارد یکی از مهم‌ترین مباحث Web Pentesting می‌شویم:

HTTP را مثل یک Pentester ببین

یاد می‌گیریم:

Request → Response → Parameter → Cookie → Session → Authentication

و بعد کم‌کم به جایی می‌رسیم که بتوانیم یک Request واقعی را تحلیل کنیم و بفهمیم کدام بخش آن ارزش بررسی امنیتی دارد.

دسته بندی‌ها:

دیدگاه شما

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *