⭕ تصاحب حساب کاربری

تو این مقاله یک تکنیک جالب بایپس 403 در API بررسی میشه
اندپوینت زیر در صورت ارسال درخواست کد 403 میده و میگه دسترسی ندارید
POST /<organizationID>/addEmail/<DemoUserID>/
تست نفوذگر اینجا با یک تکنیک ساده از traversal sequence استفاده کرده و در ادامه اش از UserID قربانی استفاده کرده
POST /<organizationID>/addEmail/<DemoUserID>/../<UserID>/

و در اینجا کد 200 گرفته و با موفقیت ایمیل قربانی رو تغییر داده

لینک مقاله:
https://gonzxph.medium.com/account-takeover-worth-of-2500-e643661f94e9

تحلیل:‌ به نظر میاد برنامه نویس اینجا اومده Requests URI رو گرفته و  چک کرده که آیا DemoUserID در organization وجود داره یا خیر؟ اگر وجود نداشت به کاربر بگه که شما دسترسی این کار رو ندارید و اگر وجود داشت بنظر میاد این درخواست برای سرویس دیگه ای که مسئول تغییر ایمیل بوده ارسال شده
در اینجا ما ۲ تا زبان مختلف پایتون و php رو در مواجه با این موضوع تست کردیم تا ببینم رفتار این ها با traversal sequence به چه صورت هست؟(‌ traversal sequence هم همون /.. هست). و آیا path normalization دارند؟ ( یعنی فانکشن با لایبرری بیاد traversal sequence هارو apply‌ کنه و مسیر یا path به اصطلاح normalize بشه
لینک مرتبط با path normalization اگر خواستید مطالعه کنید
https://en.wikipedia.org/wiki/URI_normalization

در اینجا یک سرور apache بالا آوردیم و بهش درخواست ارسال کردیم
درخواست اول با پایتون به این صورت
import requests
requests.get("http://server/a/b/../c")
درخواست دوم با php به این صورت
file_get_contents("http://server/a/b/../c");

نتایج جالب بود
لاگ سرور آپاچی:
"GET /a/c HTTP/1.1" 404 492 "-" "python-requests/2.28.1"
"GET /a/b/../c HTTP/1.1" 404 455 "-" "-"

این یعنی لایبرری requests پایتون اینجا path normalization رو اپلای کرده و php این کار رو نکرده
این تست هایی که انجام دادیم صرفا نشان دهنده این هستند که رفتار زبان و لایبرری و فریمورک های مختلف فرق میکنه.
حالا برگردیم به آسیب پذیری ای که داشتیم توضیحش میدادیم

گفتیم بعد از بررسی request uri برنامه نویس میاد این رو به سرویس دیگه ای ارسال میکنه حالا اگر این ارسال کردن با زبانی یا لایبرری اتفاق بیفته که path normalization انجام بده آسیب پذیری وجود داره و اگر انجام نده آسیب پذیری وجود نداره.

این ها صرفا یک فرض بود و ممکنه موضوع به طور کل چیز دیگه ای باشه ولی خب ما نیاز داشتیم یکم دیپ بشیم و ببینم موضوع از چه قرار هست

#ATO #bypass403
@securation

⭕️ Apache SCXML Remote Code Execution
POC :
https://pyn3rd.github.io/2023/02/06/Apache-SCXML-Remote-Code-Execution/
@securation

⭕️ بایپس جزئی rate limit در Login AWS Console

محققی از آزمایشگاه امنیتی datadog اومده و بر روی فانکشن authentication در AWS Console کار کرده. بهتر هست بگیم روی متد IAM user در بخش sign in کار کرده.
اگر به طور خلاصه و ساده بخوام بگم IAM user چی هست ابتدا باید بگم که وقتی شما یک اکانت AWS میسازید یه کاربر root به شما داده میشه. بقیه یوزر ها مثل IAM users یا AWS IAM Identity Center users توسط این اکانت روت ساخته میشن.
(مرجع)

این فانکشن طبیعتا از rate limit برخوردا بوده و هنگام authenticate درخواست http زیر رو به سرور ارسال میکرده:

POST /authenticate HTTP/2
Host: signin.aws.amazon.com
Content-Length: 257
Content-Type: application/x-www-form-urlencoded
Origin: https://signin.aws.amazon.com

action=iam-user-authentication
&account=884527801452
&username=christophe
&password=<your-password>
&client_id=arn%3Aaws%3Asignin%3A%3A%3Aconsole%2Fcanvas
&redirect_uri=https%3A%2F%2Fus-east-1.console.aws.amazon.com%2Fconsole

اگر credential داده شده نادرست بودند پاسخ زیر

{
  "state": "FAIL",
  "properties": {
  "result": "FAILURE",
  "text": "Your authentication information is incorrect. Please try again."
  }
}

و اگر درست بودند پاسخ زیر به کاربر نمایش داده میشد:

{
  "state": "SUCCESS",
  "properties": {
  "result": "SUCCESS",
  "redirectUrl": "https://us-east-1.console.aws.amazon.com/console?code\u003<token>"
  }
}

همچنین در صورتی که تعداد درخواست های ارسال از حد مجاز میگذشت اپلیکیشن پیام زیر رو به کاربر نمایش میداده:

Failed attempt for password batman: 'Too many invalid passwords have been used to attempt to sign-in to this account.  Please wait 4 seconds before your next attempt.'

محقق بعد از ارسال ۳۰ درخواست auth پشت سر هم که invalid credentials رو شامل میشده برای ۴ ثانیه از ارسال درخواست auth منع شده. تنها کاری که محقق انجام داده در اسکریپت brute force اش یک فانکشن sleep ساده بوده که در صورت برخورد با محدودیت به مدت 5 ثانیه هیچ درخواستی ارسال نشه و بعد از 5 ثانیه ارسال درخواست از سرگیری بشه.
همچنین اسکریپت بروت فورس اش رو باز نویسی کرده با 30 thread parallel این کار رو انجام داده که در نهایت منجر به ارسال 280 درخواست بر دقیقه یا بهتر هست بگیم 4.6 درخواست بر ثانیه شده.

در نهایت این موضوع و brute force کردن حساب کاربر در صورتی که top password داشته باشه و همچنین 2fa حساب کاربر فعال نبوده باشه،‌ میتونسته باعث تصاحب حساب کاربری بشه.

کاری که AWS Team برای جلوگیری انجام داده افزایش و سفت و سخت تر کردن rate limit هست.
طبیعتا اگر ما میخواستیم این جلوگیری رو انجام بدیم این کار هارو میتونستیم کنیم:
1) اضافه کردن محدودیت زمانی rate limit به طور افزایشی یعنی بار اول اگر 4 ثانیه هست بار دوم 8 ثانیه و بار سوم 12 ثانیه و ...
2) پیاده سازی مکانیزم Capctha به طور امن
3) مسدود کردن IP بعد از X بار تلاش نادرست ( این مسدود کردن باید موقتی باشه و نمیتونه دائمی باشه اصولا)
4) قفل کردن یا Lock کردن حسابی که داره brute force بر روش صورت میگیره:‌ حالا قابلیت unlock کردن اون حساب میتونه از یه چنل دیگه مثل email یا phone صورت بگیره.

لینک مقاله برای مطالعه:
https://securitylabs.datadoghq.com/articles/aws-console-rate-limit-bypass/

#bruteforce #web_security #rate_limit #ATO #AWS
@securation

⭕️CVE-2023-23752
Joomla webservice endpoint access
PoC
httpx -l ip.txt -path '/api/index.php/v1/config/application?public=true'
#joomla #0day
@securation

⭕️ Bypassing Single Sign On via login without password feature | 0 Click account takeover

در این مقاله،‌ هانتر موفق به دور زدن Single Sign On با استفاده از ویژگی لاگین بدون استفاده از پسورد شده است.
این قابلیت با ارسال کردن OTP به ایمیل کاربر صورت می پذیرد.
در این اپلیکیشن قابلیت لینک کردن تعدادی اکانت به یک ایمیل وجود داشت. در قابلیت لاگین بدون پسورد ابتدا شما باید ایمیل خودتون رو وارد میکردید سپس اپلیکیشن لیست حساب های موجود و لینک شده به ایمیل را به شما نشان می دهد. و با کلیک کردن بر روی دکمه Login without password رو به روی حساب به حساب مدنظر لاگین صورت میگرفت.
درخواست زیر برای تایید OTP و لاگین اکانت مورد نظر به سمت سرور ارسال می شود

POST /api/sso/login-without-password/auth HTTP/2

{"track":006,"action":"login-without-password","code":"[OTP]","token":"22123w2DS4543jg23324e35SD==","username":"attacker1"}

همونطور که مشاهده میکنید پارامتری به نام username در اینجا استفاده شده است. که دلیل استفاده از این پارامتر قبل تر توضیح داده شده است ( هر ایمیل ممکن است چند اکانت متصل شده و username را دارا باشد)
در اینجا هانتر با تغییر مقدار پارامتر username به username قربانی ( شخصی که حسابش به ایمیل اتکر لینک نشده است) قادر به تصاحب حساب کاربری وی شده است.

در این فیچر توسعه دهنده، عمل بررسی اینکه آیا نام کاربری به ایمیل مدنظر لینک شده است یا نه را انجام نداده و این در نهایت موجب آسیب پذیری Account Takeover شده است.

لینک مقاله:
https://aidilarf.medium.com/bypassing-sso-authentication-from-the-login-without-password-feature-lead-to-account-takeover-d2322a33a208

#web_security #ATO #SSO
@securation

⭕️ Bypass Ban Time in Password Brute Force

در این سناریو هانتر زمانی که به Brute Force کردن فانکشن لاگین پرداخته به مدت 20 دقیقه محدودیت ارسال درخواست لاگین گرفته.
بعد به بررسی درخواست های Burp Suite میپردازه و سپس با اندپوینتی مواجه میشه که وقتی بازش میکنه اونجا لینکی مبنی بر Send password reset link میبینه و روش کلیک میکنه و وارد حسابش میشه و در واقع موفق به دورزدن Ban Time میشه.

https://medium.com/p/c3837e6bb8ed

#web_security
@securation

⭕️ در ماه فوریه گزارش شد که سرویس مارشال‌ ایالات متحده دچار حمله باج افزاری شده اما حالا کاربری در فروم روسی ظاهر شده که 350 گیگ از داده های این دفتر رو با قیمت 150 هزار دلار به فروش گزاشته.
به گزارش هکر یا فروشنده اطلاعات شامل:
- عکس ها و فیلم های هوایی از پایگاهای نظامی یا مختصات خاص
- اسناد شنود و نظارت بر شهروندان
-پرونده کارتل ها
-داده های مربوط به شهود یا افرادی که در برنامه حفاظت از شاهدان قرار دارند
-فایل های مربوط به بکدور اپل
و اسناد زیاد دیگه ای با علامت محرمانه و سری هست
http://xssforumv3isucukbxhdhwz67hoa5e2voakcfkuieq4ch257vsburuid.onion/threads/83828
#data
@securation

⭕️اگر بر روی شبکه Starknet که در لایه 2 ‏Ethereum کار میکند و با زبان محلی آن شبکه که ‏ Cairo است فعالیت میکنید
ابزاری برای FUZZING و Auditing آن که ویژگی هایی همچون:
اجرا بر روی قرارداد های ‏Cairo
اجرا بر روی قرارداد های Starknet
وجود دارد که میتواند کمک کننده باشد
https://github.com/FuzzingLabs/cairo-fuzzer

#web3 #blockchain #auditing #fuzzing
@securation

⭕️اگر داخل ایران فورتی وب استفاده میکنید بروزرسانی فوری انجام بدید.
آسیب پذیری RCE که امروز خبر فیکس شدنش منتشر شد, طبق بررسی ها در موتور جستجوی shodan در ایران تارگت های آسیب پذیری با تعداد بالا هنوز وجود دارد.

لینک خبر
#fortinet #fortiweb
@securation

اولین ویدیو خیلی طولانی درباره آسیب پذیری Open Redirect رو آپلود کردم چنل یوتیوب
https://www.youtube.com/watch?v=qvqpRA0cfAc
اگر با این آسیب پذیری آشنایی ندارید یا میخواید توش دیپ بشید حتما این ویدیو رو ببینید که شامل کار عملی و Code Review و ... میشه
همچنین یه lab با flask نوشتم و گذاشتمش تو گیت هاب برای این آسیب پذیری
https://github.com/amir-h-fallahi/Open-Redirect-Lab
اگرم اشنایی دارید در انتهای اسلاید ها یه سری Offensive checklist و Developer checklist گذاشتم که هم مناسب پن تستر و هانتر ها هست هم دولوپر ها
https://t.me/secflaws/10

@secflaws

⭕️ دور زدن SSRF Protection از طریق Cross Protocol Redirect

یکی از راه هایی که حتما میدونید برای دور زدن SSRF Protection و دستیابی به internal asset مثل localhost و ... این هست که ما redirect انجام بدیم. برای مثال آدرس URL ای به اپ میدیم که تحت کنترل ماست و اون درخواست http رو ریدایرکت میکنه به یه asset inernal

محقق طی یه پروژه با تارگتی روبه رو میشه که هیچگونه جلوگیری ای برای ssrf نداشته و بعد از گزارش برنامه نویس از لایببری ssrf-req-filter توی node.js استفاده میکنه و محقق هنگام اولین retest متوجه میشه آسیب پذیری پچ شده اما زمانی که محقق Cross-Protocol Redirect رو تست میکنه دوباره با موفقیت به اون asset internal دسترسی میگیره

اما Cross-Protocol Redirect چیه؟ منظور اینه که پروتکل از http به https هنگام ریدایرکت تغییر پیدا کنه یا برعکس
در اینجا محقق URL ابتدایی که به App داده پروتکل https داشته اما در ریدایرکت گفته که به localhost ریدایرکت صورت بگیره روی پروتکل http
https://example.com/?redirect=http://localhost

اما چرا این اتفاق میفته؟ به طور خلاصه ما کد JS شبیه به کد زیر رو داریم که از ssrf جلوگیری کنه
request({
    uri: url,
    agent: ssrfFilter(url),
});
اما در لایبرری request در قسمت lib/redirect.js ما یه شرط جالب داریم:
if (request.uri.protocol !== uriPrev.protocol) {
  delete request.agent
}
بازم هم به طور خیلی خلاصه بخوام بگم این شرط بررسی میکنه که اگر هنگام ریدایرکت تغییر پروتکل داشتیم request.agent حذف بشه که در این کیس ما باعث میشه ssrf filter ای نداشته باشیم (‌ چون خود متد ssrfFilter اگر دقت کنید در قسمت agent کال شده)

https://blog.doyensec.com/2023/03/16/ssrf-remediation-bypass.html

#web_security #ssrf
@securation

⭕️ Telegram bug bounties | RCE, privacy issues, and more…

تو این مقاله محقق از آسیب پذیری هایی که روی تلگرام پیدا کرده میگه. آسیب پذیری هایی مثل RCE روی WebView , افشای IP کاربر در تلگرام وب و ...


https://davtur19.medium.com/telegram-bug-bounties-rce-privacy-issues-and-more-b1f06a641c1b

#web_security #rce
@securation

⭕ RCE through default configuration | Apache Superset

پیکربندی پیشفرض SECRET_KEY در Apache Superset کشف شده که میتونه منجر به RCE هم بشه.
میتونید آسیب پذیری رو با CVE-2023-27524 دنبال کنید.

آسیب پذیری در نسخه 2.1 فیکس شده.

https://thehackernews.com/2023/04/apache-superset-vulnerability-insecure.html?m=1

#default_config #rce
@securation

⭕ XSS in a million websites | CVE-2023-29489

تو این مقاله به بررسی نحوه پیدا شدن آسیب پذیری XSS در cPanel توسط assetnote پرداخته شده.

https://blog.assetnote.io/2023/04/26/xss-million-websites-cpanel

#web_security #xss #0day
@securation

⭕️ RADAR: How DevSecOps is Revolutionizing Security at Snapp

در این مقاله یکی از AppSec Engineer های Snapp به بررسی جزئیات DevSecOps توی اسنپ پرداخته.

به طور خیلی خلاصه فریمورک رادار اسنپ که ترکیب Security Testing در CI/CD هست شامل ابزار های زیر میشه:
1. SAST:‌ semgrep
2. SCA, SBOM: Grype, Syft
3. Secret Detection: Gitleaks
4. IaC: KICS
5. Container Scanning: Trivy
6. DAST: ZAP
7. Vulnerability Management: DefectDojo, OWASP Dependency-Track

مقاله:
https://medium.com/@mohammadkamrani7/radar-how-devsecops-is-revolutionizing-security-at-snapp-5f496fd08e79

#DevSecOps #AppSec #DAST #SAST
@securation

⭕️ Dangerous Regular Expressions

تو این پست Vickie Li از خطا های رایج در رجکس میگه و چندتا Best Practice برای رجکس های امن تر مثل اینکه:
- تا جایی که میشه برای چیزهایی مثل یوزرنیم و پسورد و ... خودتون رجکس ننویسید از رجکس های امن توی اینترنت استفاده کنید
- از Defense-in-depth استفاده کنید یعنی فقط به رجکس و اعتبار سنجی اش و ... اطمینان نکنید
- همچنین Fuzzing میتونه از اینکه رجکس شما داره درست کار میکنه یا نه اطمینان بیشتری حاصل کنه.

مطالعه بیشتر:
https://sec.okta.com/articles/2020/07/dangerous-regular-expressions

یه سری منابع هم معرفی شده برای امن تر کردن رجکس هاتون
https://owasp.org/www-community/OWASP_Validation_Regex_Repository
http://regexlib.com/DisplayPatterns.aspx
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html

#regex #security #AppSec
@securation

⭕️ Building a Red Team Infrastructure in 2023


https://www.securesystems.de/blog/building-a-red-team-infrastructure-in-2023/

#RedTeam
@securation

⭕️ Discovery of an XSS on Opera

هانتر تو این مقاله از متدولوژی خودش که باهاش تونسته رو Opera آسیب پذیری XSS پیدا کنه میگه.
https://infosecwriteups.com/discovery-of-an-xss-on-opera-f029f6522ec5

Quickly Subdomain Discovery
- https://subdomainfinder.c99.nl/
Subdomain Brute Force
- https://github.com/guelfoweb/knock
Content Discovery
- https://github.com/projectdiscovery/katana/
- https://github.com/tomnomnom/waybackurls


#BugBounty #XSS #Recon
@securation

⭕️ شبیه سازی IoT Firmware

اگر قصد تست امنیت یه hardware product رو دارید و اما نمی تونید physical device رو داشته باشید میتونید از یه شبیه ساز مثل QEMU استفاده کنید.

https://boschko.ca/qemu-emulating-firmware/

#IoT #emulator
@securation

⭕اگر با حملات لایه 2 و 3 شبکه درگیر شده باشید احتمالا با ابزار هایی مثل Yersina و Loki کار کردید
حال ابزار جدیدی اخیرا به وجود آمده که با تجمیع از این دو ابزار و ابزار های دیگر اقدام به بررسی امنیتی پروتکل های زیر را تا حد امکان بدون noisy بودن میکند:
MACSec
DTP
EDP
CDP
LLDP
MNDP
OSPF
EIGRP
VRRP
HSRP
ESRP
GLBP
STP
PVST
LLMNR
NBT-NS
MDNS
DHCPv6

https://github.com/c4s73r/Above
#RedTeam #Mitm
@securation

⭕️در پروسه Domain escalation از سرویس هایی که میتوان مورد هدف ما باشد ADDS یا همان Active Directory Certificate Services است.
ابزاری برای خودکار سازی پروسه کشف و ایجاد دسترسی با استفاده از misconfiguration های احتمالی نوشته شده که پروسه را برایمان راحت تر میکند.(البته باید موضوع شناسایی نشدن توسط مکانیزم های امنیتی را در نظر گرفت)
ویژگی های این ابزار را میتوان مثال زد:
جمع آوری Domain Admin ها توسط LDAP
جمع آوری DC ها توسط LDAP
جمع آوری Certificate Authorities توسط Certipy
و در آخر اکسپلویت کردن ESC1 و ESC8
البته چون اسکریپت پایتونی است میتوان مدل های دیگر اکسپلویت هم به آن اضافه کرد.

https://github.com/grimlockx/ADCSKiller
#RedTeam #ADCS
@securation