Recent searches
Search options
#ssrf
#AI: A year-old Server-Side Request Forgery (#SSRF) vulnerability in #ChatGPT pictureproxy.php file (CVE-2024-27564) is actively exploited against financial entities & government organisations;
https://www.securityweek.com/chatgpt-vulnerability-exploited-against-us-government-organizations/
ChatGPT SSRF bug quickly becomes a favorite attack vector – Source: securityaffairs.com https://ciso2ciso.com/chatgpt-ssrf-bug-quickly-becomes-a-favorite-attack-vector-source-securityaffairs-com/ #rssfeedpostgeneratorecho #informationsecuritynews #ITInformationSecurity #SecurityAffairscom #CyberSecurityNews #PierluigiPaganini #SecurityAffairs #SecurityAffairs #BreakingNews #SecurityNews #hackingnews #ChatGPT #hacking #SSRF
Since 2021, I hadn't used #hackthebox. Recently tackled the #Backfire machine, which required combining #SSRF and #RCE vulnerabilities.
To complete it, I used two AIs: #o1 and #DeepSeek R1. While helpful, In my opinion, AIs can only support about 20% or 30% of the process, the rest relies on expertise and experience, especially when the machine hasn't been retired yet and there's not much info available.
FedifyのWebFinger実装における脆弱性CVE-2025-23221に対するセキュリティアップデート（1.0.14、1.1.11、1.2.11、1.3.4）をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。
脆弱性の詳細
セキュリティ研究者により、FedifyのlookupWebFinger()関数において以下のセキュリティ上の問題が発見されました：
- 無限リダイレクトループによるサービス拒否攻撃（DoS）の可能性
- プライベートネットワークアドレスへのリダイレクトを利用したSSRF（サーバーサイドリクエストフォージェリ）攻撃の可能性
- リダイレクト操作による意図しないURLスキームへのアクセスの可能性
修正されたバージョン
変更内容
本セキュリティアップデートでは、以下の修正が実施されました：
- 無限リダイレクトループを防ぐため、最大リダイレクト回数（5回）の制限を導入
- 元のリクエストと同じスキーム（HTTP/HTTPS）のみにリダイレクトを制限
- SSRFを防止するため、プライベートネットワークアドレスへのリダイレクトをブロック
アップデート方法
以下のコマンドで最新のセキュアバージョンにアップデートできます：
# npmユーザーの場合
npm update @fedify/fedify
# Denoユーザーの場合
deno add jsr:@fedify/fedify
この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。
本脆弱性の詳細については、セキュリティ勧告をご参照ください。
ご質問やご懸念がございましたら、GitHub Discussions、Matrixチャットスペース、またはDiscordサーバーまでお気軽にご連絡ください。
#Fedify 프레임워크의 #WebFinger 구현에서 발견된 보안 취약점 CVE-2025-23221을 해결하기 위한 보안 업데이트(1.0.14, 1.1.11, 1.2.11, 1.3.4)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다.
취약점 내용
보안 연구자가 Fedify의 lookupWebFinger() 함수에서 다음과 같은 보안 문제점들을 발견했습니다:
- 무한 리다이렉트 루프를 통한 서비스 거부 공격 가능
- 내부 네트워크 주소로의 리다이렉트를 통한 SSRF (서버측 요청 위조) 공격 가능
- 리다이렉트 조작을 통한 의도하지 않은 URL 스킴 접근 가능
수정된 버전
변경 사항
이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다:
- 무한 리다이렉트 루프를 방지하기 위해 최대 리다이렉트 횟수 제한(5회) 도입
- 원래 요청과 동일한 스킴(HTTP/HTTPS)으로만 리다이렉트 허용하도록 제한
- SSRF 공격 방지를 위해 내부 네트워크 주소로의 리다이렉트 차단
업데이트 방법
다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다:
# npm 사용자의 경우
npm update @fedify/fedify
# Deno 사용자의 경우
deno add jsr:@fedify/fedify
이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다.
이 취약점에 대한 자세한 내용은 보안 권고문을 참고해 주시기 바랍니다.
문의 사항이나 우려 사항이 있으시다면 GitHub Discussions나 Matrix 채팅방, 또는 Discord 서버를 통해 언제든 연락해 주시기 바랍니다.
We have released #security updates (1.0.14, 1.1.11, 1.2.11, 1.3.4) to address CVE-2025-23221, a #vulnerability in #Fedify's #WebFinger implementation. We recommend all users update to the latest version of their respective release series immediately.
The Vulnerability
A security researcher identified multiple security issues in Fedify's lookupWebFinger() function that could be exploited to:
- Perform denial of service attacks through infinite redirect loops
- Execute server-side request forgery (#SSRF) attacks via redirects to private network addresses
- Access unintended URL schemes through redirect manipulation
Fixed Versions
- 1.3.x series: Update to 1.3.4
- 1.2.x series: Update to 1.2.11
- 1.1.x series: Update to 1.1.11
- 1.0.x series: Update to 1.0.14
Changes
The security updates implement the following fixes:
- Added a maximum redirect limit (5) to prevent infinite redirect loops
- Restricted redirects to only follow the same scheme as the original request (HTTP/HTTPS)
- Blocked redirects to private network addresses to prevent SSRF attacks
How to Update
To update to the latest secure version:
# For npm users
npm update @fedify/fedify
# For Deno users
deno add jsr:@fedify/fedify
We thank the security researcher who responsibly disclosed this vulnerability, allowing us to address these issues promptly.
For more details about this vulnerability, please refer to our security advisory.
If you have any questions or concerns, please don't hesitate to reach out through our GitHub Discussions, join our Matrix chat space, or our Discord server.
Today I performed a server side request forgery #ssrf attack in a lab. It was kind of easy and also straightforward. It wasn't even that hard to find (still took me a while as I'm quite new to doing this kind of stuff).
As a (mostly) WebApp developer it really helps me to perform attacks and analysis. It helps me think about #security issues when designing and implementing things. Only knowing of the attacks and possible countermeasures is way too passive for me.
https://owasp.org/www-community/attacks/Server_Side_Request_Forgery
To all you #developers implementing #SSRF protections in your #fediverse applications...
We are all in favor of those protections. But!
Have a setting that lets projects like #FediTest override it. Otherwise how can anybody test interop on anything other than on the public internet?
Mastodon has a ALLOWED_PRIVATE_ADDRESSES setting, which is one way of doing it. Or just have a setting with a default value of what's disabled, and let people override it. Or whatever.
But we need something ...
i've discovered #wiremock, which is a godsend for writing outside-in tests for my service that needs to accept urls and download what they point to.
HOWEVER - just downloading stuff that's on some port on #localhost leaves something to be desired when it comes to server-side-request-forgery #ssrf (https://owasp.org/www-community/attacks/Server_Side_Request_Forgery)
how do people do this? setting up a domain-name for the test seems difficult, and having a "currently testing, so allow localhost" environment variable also seems icky.
We released #Fedify 0.9.2, 0.10.1, and 0.11.1, which patched the last reported #vulnerability, CVE-2024-39687, but the vulnerability of SSRF attacks via DNS rebinding still exists, so we released Fedify 0.9.3, 0.10.2, and 0.11.2, which fixes it.
If you are using an earlier version, please update as soon as possible.
Thanks to @benaryorg for reporting the vulnerability!
Fuckin win of the week. Successfully wrote an SSRF filter as a Catalina servlet.
Now, kids, blacklisting is NOT a good way to guard against incoming attacks. Fix the underlying problem, use a whitelist, or both. BUT, if you are in the process of replacing an app, and less than a year out, and are just trying to protect ONE LITTLE THING that the vendor won't fix, you gotta do what you gotta do.
The request looks like this:
GET /nesp/app/?UniX:<<7701 random ASCII letters and numbers !symbols>>|http://localhost:22/ HTTP/1.1
Alright folks. I'm seeing something I have never seen before. It's a SSRF attack that adds app?UniX: to a web server GET request, and then passes in various things with an eventual payload. Makes a big, long URL.
The big long URL, the eventual payload, no problem. I get that, seen it before. My issue is the unix: like a protocol tag. Has anyone ever seen that? And do you know how hard it is to search for something with a colon at the end on today's web? Anyway.
Ron Bowes @iagox86 of @greynoise blogs about the Confusing History of F5 BIG-IP RCE Vulnerabilities, stemming from a unidentified shell-injection attack against the filePath parameter in the F5 BIG-IP login page. This turned out to be CVE-2021-23015, but the path to figuring that out is an interesting read.
https://www.labs.greynoise.io/grimoire/2024-01-14-f5-rce-explained/
Question for #selfhost #homelab #server folks: how do you handle the threat of #SSRF attacks meant to probe your internal network?
SSRF is usually mitigated by preventing any requests to an IP that is not publicly accessible [1]
But in a home / self hosted env, you probably want to allow your local services to talk to each-other. If you run an app that makes requests to arbitrary addresses (think fedi server!) you may now be exposed?
CLI for recon and write operations on Confluence and Jira instances 
https://github.com/werdhaihai/AtlasReaper
This tool is designed to help you find suitable SSRF candidates 
https://github.com/assetnote/surf
SSRF bypass list:
-------
Base-Url: 127.0.0.1
Client-IP: 127.0.0.1
Http-Url: 127.0.0.1
Proxy-Host: 127.0.0.1
Proxy-Url: 127.0.0.1
Real-Ip: 127.0.0.1
Redirect: 127.0.0.1
Referer: 127.0.0.1
Referrer: 127.0.0.1
Refferer: 127.0.0.1
Request-Uri: 127.0.0.1
Uri: 127.0.0.1
Url: 127.0.0.1
X-Client-IP: 127.0.0.1
X-Custom-IP-Authorization: 127.0.0.1
X-Forward-For: 127.0.0.1
X-Forwarded-By: 127.0.0.1
X-Forwarded-For-Original: 127.0.0.1
X-Forwarded-For: 127.0.0.1
X-Forwarded-Host: 127.0.0.1
X-Forwarded-Port: 443
X-Forwarded-Port: 4443
X-Forwarded-Port: 80
X-Forwarded-Port: 8080
X-Forwarded-Port: 8443
X-Forwarded-Scheme: http
X-Forwarded-Scheme: https
X-Forwarded-Server: 127.0.0.1
X-Forwarded: 127.0.0.1
X-Forwarder-For: 127.0.0.1
X-Host: 127.0.0.1
X-Http-Destinationurl: 127.0.0.1
X-Http-Host-Override: 127.0.0.1
X-Original-Remote-Addr: 127.0.0.1
X-Original-Url: 127.0.0.1
X-Originating-IP: 127.0.0.1
X-Proxy-Url: 127.0.0.1
X-Real-Ip: 127.0.0.1
X-Remote-Addr: 127.0.0.1
X-Remote-IP: 127.0.0.1
X-Rewrite-Url: 127.0.0.1
X-True-IP: 127.0.0.1
-----
https://twitter.com/0dayCTF/status/1556279777455386627?t=Z51UbhiolM5RuAww32v3Ww&s=19
Credit: @0dayCTF
SSRF vulnerabilities caused by SNI proxy misconfigurations
https://www.invicti.com/blog/web-security/ssrf-vulnerabilities-caused-by-sni-proxy-misconfigurations/
Awesome Server Side Request Forgery(SSRF) mind map by @hackerscrolls
