⭕️از مهم ترین اقدامات Pentest و Redteam تکنیک های Anti Forensic است، ابزاری اخیرا منتشر شده که تکنیک های زیر را در بر میگیرد:

Unloading Sysmon Driver.
Gutmann Method File Shredding.
USNJrnl Disabler.
Prefetch Disabler.
Log Eraser and Event log Disabler.
User Assist Update Time Disabler.
Access Time Disabler.
Clear Recent Items
Clear Shim Cache
Clear RecentFileCache
Clear ShellBag
File Melting Capabilities.

https://github.com/PaulNorman01/Forensia
#redteam #antiforensic
@securation

⭕️ ‏اگر به موضوعات kiosk breakout و atm hacking علاقه مند هستید پیشنهاد میکنم نظاره گر این مقاله باشید.
مقاله زیر حول محورهای مختلفی مانند:‏
‏ATM Internals
‏Insufficient physical security
‏Insufficient configuration of the system and peripheral devices
‏Insufficient network security
و توصیه های Hardening این حملات است.

https://blog.nviso.eu/2023/01/10/malware-based-attacks-on-atms-a-summary/
#redteam #kioskbreakout #atmhacking
@securation

⭕️ در پروسه تحلیل ترافیک و Network Forensic ما از ابزار های مختلفی استفاده میکنیم.
گاهی ابزار هایی تولید میشود که کار را راحت کرده و ترکیبی از ابزار های مختلف خواهد بود.
ابزار brim security یک ابزار تحلیل ترافیک تحتِ وب است که خروجی ترافیک wireshark که فایل های pcap هستند را به zeek داده و خروجی تحلیل را به ما نشان میدهد.
همچنین میتوان از ابزار های خوب مانند omnipeek نیز برای این کار استفاده کرد.
https://kifarunix.com/analyze-network-traffic-using-brim-security/
#Forensic #AnalyzeNetwork #blueteam
@securation

⭕️ آخر جولای 2022 FBI تونسته بود به زیرساخت باج افزار Hive نفوذ کنه و کلید رمزگشایی این باج افزار رو بدست بیاره که موجب جلوگیری از ۱۲۰ میلیون دلار باج گیری شد.
وبسایت باج افزار Hive الان لوگوی FBI روی اون هست و متوقف شده است.
همزمان با توقیف زیرساخت های باج افزار Hive توسط امریکا، وبسایت های پاداش برای عدالت وزارت دادگستری آمریکا، CIA، FBI و وزارت خارجه آمریکاو بخش روسی شرکت تلویزیون و رادیو ملی سوئیس در روسیه مسدود شد.
لینک خبر :
https://roskomsvoboda.org/post/block-cia-fbi-statdep/

1- https://reestr.rublacklist.net/ru/record/5368745/
2- https://reestr.rublacklist.net/ru/record/5368747/
3-
https://reestr.rublacklist.net/ru/record/5368354/
#ransomware #russia #FBI
@securation

⭕️Microsoft Exchange: OWASSRF + TabShell
(CVE-2022-41076)

The TabShell vulnerability its a form of Privilege Escalation which allows breaking out of the restricted Powershell Sandbox after you have successfully gained access through OWASSRF.

For a detailed write see research:
https://blog.viettelcybersecurity.com/tabshell-owassrf/

PoC:
https://gist.github.com/testanull/518871a2e2057caa2bc9c6ae6634103e

#owa #ssrf #tabshell #poc
@securation

⭕️اگر Sccm Current Branch Unleashed را کانفیگ کرده باشید در فرایند نصب سایت به نکته ای جالب بر خواهید خورد.
‏computer account مربوط به سایت اصلی باید عضو گروه local admin sql sever باشد.
حال این موضوع به این معنی است که:
متصل شدن سایت ها و push شدن کلاینت ها بصورت خودکار اتفاق می افتد.
بصورت پیشفرض مکانیزم احراز هویت به ntlm بازمیگردد،بصورت پیشفرض در احراز هویت کلاینت ها pki cert الزام نیست و ‏mssql در سرور دیتابیس سایت در دسترس است ، البته smb sign ملزوم نیست.
پس عملا با تصاحب سایت sccm که با اجبار کردن احراز هویت با ntlm و انقال آن به سرور پایگاه داده سایت و استفاده از عبارت هویت mssql منجر به full admin شده و به تمامی بخش های سایت مشرف بوده و میتوان آنها را کنترل کرد.

++ برای جلوگیری از این مشکل چه باید کرد:
- نصب hotfix
- فعال کردن extended protection بر روی mssql
- فعال کردن smb sign برای سرور های درون سایت
- بلاک کردن ارتباطات sql و smb از سیستم های غیر ضروری به سرور های سایت
- ملزوم کردن pki cert بر روی کلاینت ها
- در عوض نصب خودکار آپدیت ها از نصب مبتنی بر نرم افزار، group policy و دستی اقدام شود.

https://posts.specterops.io/sccm-site-takeover-via-automatic-client-push-installation-f567ec80d5b1#a2e2

#redteam #hardening #sccm #blueteam
@securation

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

تو این مقاله یک تکنیک جالب بایپس 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