Med-Mastodon

Pyrzout :vm:ChatGPT SSRF bug quickly becomes a favorite attack vector – Source: securityaffairs.com <a href="https://ciso2ciso.com/chatgpt-ssrf-bug-quickly-becomes-a-favorite-attack-vector-source-securityaffairs-com/" rel="nofollow noopener" translate="no" target="_blank">https://ciso2ciso.com/chatgpt-ssrf-bug-quickly-becomes-a-favorite-attack-vector-source-securityaffairs-com/</a> <a href="https://social.skynetcloud.site/tags/rssfeedpostgeneratorecho" class="mention hashtag" rel="nofollow noopener" target="_blank">#rssfeedpostgeneratorecho</a> <a href="https://social.skynetcloud.site/tags/informationsecuritynews" class="mention hashtag" rel="nofollow noopener" target="_blank">#informationsecuritynews</a> <a href="https://social.skynetcloud.site/tags/ITInformationSecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#ITInformationSecurity</a> <a href="https://social.skynetcloud.site/tags/SecurityAffairscom" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityAffairscom</a> <a href="https://social.skynetcloud.site/tags/CyberSecurityNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#CyberSecurityNews</a> <a href="https://social.skynetcloud.site/tags/PierluigiPaganini" class="mention hashtag" rel="nofollow noopener" target="_blank">#PierluigiPaganini</a> <a href="https://social.skynetcloud.site/tags/SecurityAffairs" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityAffairs</a> <a href="https://social.skynetcloud.site/tags/SecurityAffairs" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityAffairs</a> <a href="https://social.skynetcloud.site/tags/BreakingNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#BreakingNews</a> <a href="https://social.skynetcloud.site/tags/SecurityNews" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityNews</a> <a href="https://social.skynetcloud.site/tags/hackingnews" class="mention hashtag" rel="nofollow noopener" target="_blank">#hackingnews</a> <a href="https://social.skynetcloud.site/tags/ChatGPT" class="mention hashtag" rel="nofollow noopener" target="_blank">#ChatGPT</a> <a href="https://social.skynetcloud.site/tags/hacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#hacking</a> <a href="https://social.skynetcloud.site/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a>

securityaffairs<a href="https://infosec.exchange/tags/ChatGPT" class="mention hashtag" rel="nofollow noopener" target="_blank">#ChatGPT</a> <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> bug quickly becomes a favorite attack vector <a href="https://securityaffairs.com/175560/hacking/chatgpt-ssrf-bug-quickly-becomes-a-favorite-attack-vector.html" rel="nofollow noopener" translate="no" target="_blank">https://securityaffairs.com/175560/hacking/chatgpt-ssrf-bug-quickly-becomes-a-favorite-attack-vector.html</a> <a href="https://infosec.exchange/tags/securityaffairs" class="mention hashtag" rel="nofollow noopener" target="_blank">#securityaffairs</a> <a href="https://infosec.exchange/tags/hacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#hacking</a> <a href="https://infosec.exchange/tags/malware" class="mention hashtag" rel="nofollow noopener" target="_blank">#malware</a>

securityaffairsExperts warn of a coordinated surge" in the exploitation attempts of <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> flaws <a href="https://securityaffairs.com/175344/hacking/coordinated-surge-exploitation-attempts-ssrf-vulnerabities.html" rel="nofollow noopener" translate="no" target="_blank">https://securityaffairs.com/175344/hacking/coordinated-surge-exploitation-attempts-ssrf-vulnerabities.html</a> <a href="https://infosec.exchange/tags/securityaffairs" class="mention hashtag" rel="nofollow noopener" target="_blank">#securityaffairs</a> <a href="https://infosec.exchange/tags/hacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#hacking</a>

Fedify: an ActivityPub server frameworkFedifyのWebFinger実装における脆弱性<a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">CVE-2025-23221</a>に対するセキュリティアップデート（<a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a>、<a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a>、<a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a>、<a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a>）をリリースいたしました。すべてのユーザー様におかれましては、お使いのバージョンに応じた最新版への速やかなアップデートを推奨いたします。 脆弱性の詳細 セキュリティ研究者により、Fedifyの<code>lookupWebFinger()</code>関数において以下のセキュリティ上の問題が発見されました： <ul> <li>無限リダイレクトループによるサービス拒否攻撃（DoS）の可能性</li> <li>プライベートネットワークアドレスへのリダイレクトを利用したSSRF（サーバーサイドリクエストフォージェリ）攻撃の可能性</li> <li>リダイレクト操作による意図しないURLスキームへのアクセスの可能性</li> </ul> 修正されたバージョン <ul> <li>1.3.xシリーズ：<a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a>へアップデート</li> <li>1.2.xシリーズ：<a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a>へアップデート</li> <li>1.1.xシリーズ：<a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a>へアップデート</li> <li>1.0.xシリーズ：<a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a>へアップデート</li> </ul> 変更内容 本セキュリティアップデートでは、以下の修正が実施されました： <ol> <li>無限リダイレクトループを防ぐため、最大リダイレクト回数（5回）の制限を導入</li> <li>元のリクエストと同じスキーム（HTTP/HTTPS）のみにリダイレクトを制限</li> <li>SSRFを防止するため、プライベートネットワークアドレスへのリダイレクトをブロック</li> </ol> アップデート方法 以下のコマンドで最新のセキュアバージョンにアップデートできます： <pre><code># npmユーザーの場合 npm update @fedify/fedify # Denoユーザーの場合 deno add jsr:@fedify/fedify </code></pre> この脆弱性を責任を持って報告していただいたセキュリティ研究者の方に感謝申し上げます。迅速な対応が可能となりました。 本脆弱性の詳細については、<a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">セキュリティ勧告</a>をご参照ください。 ご質問やご懸念がございましたら、<a href="https://github.com/dahlia/fedify/discussions" rel="nofollow noopener" target="_blank">GitHub Discussions</a>、<a href="https://matrix.to/#/#fedify:matrix.org" rel="nofollow noopener" target="_blank">Matrixチャットスペース</a>、または<a href="https://discord.gg/bhtwpzURwd" rel="nofollow noopener" target="_blank">Discordサーバー</a>までお気軽にご連絡ください。 <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/Fedify" target="_blank">#Fedify</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/WebFinger" target="_blank">#WebFinger</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3" target="_blank">#セキュリティ</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/%E8%84%86%E5%BC%B1%E6%80%A7" target="_blank">#脆弱性</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/DoS" target="_blank">#DoS</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/SSRF" target="_blank">#SSRF</a>

Fedify: an ActivityPub server framework<a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/Fedify" target="_blank">#Fedify</a> 프레임워크의 <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/WebFinger" target="_blank">#WebFinger</a> 구현에서 발견된 보안 취약점 <a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">CVE-2025-23221</a>을 해결하기 위한 보안 업데이트(<a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a>)를 배포했습니다. 모든 사용자께서는 각자 사용 중인 버전에 해당하는 최신 버전으로 즉시 업데이트하시기를 권장합니다. 취약점 내용 보안 연구자가 Fedify의 <code>lookupWebFinger()</code> 함수에서 다음과 같은 보안 문제점들을 발견했습니다: <ul> <li>무한 리다이렉트 루프를 통한 서비스 거부 공격 가능</li> <li>내부 네트워크 주소로의 리다이렉트를 통한 SSRF (서버측 요청 위조) 공격 가능</li> <li>리다이렉트 조작을 통한 의도하지 않은 URL 스킴 접근 가능</li> </ul> 수정된 버전 <ul> <li>1.3.x 시리즈: <a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a>로 업데이트</li> <li>1.2.x 시리즈: <a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a>로 업데이트</li> <li>1.1.x 시리즈: <a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a>로 업데이트</li> <li>1.0.x 시리즈: <a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a>로 업데이트</li> </ul> 변경 사항 이번 보안 업데이트에는 다음과 같은 수정 사항이 포함되어 있습니다: <ol> <li>무한 리다이렉트 루프를 방지하기 위해 최대 리다이렉트 횟수 제한(5회) 도입</li> <li>원래 요청과 동일한 스킴(HTTP/HTTPS)으로만 리다이렉트 허용하도록 제한</li> <li>SSRF 공격 방지를 위해 내부 네트워크 주소로의 리다이렉트 차단</li> </ol> 업데이트 방법 다음 명령어로 최신 보안 버전으로 업데이트하실 수 있습니다: <pre><code># npm 사용자의 경우 npm update @fedify/fedify # Deno 사용자의 경우 deno add jsr:@fedify/fedify </code></pre> 이 취약점을 책임감 있게 보고해 주신 보안 연구자께 감사드립니다. 덕분에 신속하게 문제를 해결할 수 있었습니다. 이 취약점에 대한 자세한 내용은 <a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">보안 권고문</a>을 참고해 주시기 바랍니다. 문의 사항이나 우려 사항이 있으시다면 <a href="https://github.com/dahlia/fedify/discussions" rel="nofollow noopener" target="_blank">GitHub Discussions</a>나 <a href="https://matrix.to/#/#fedify:matrix.org" rel="nofollow noopener" target="_blank">Matrix 채팅방</a>, 또는 <a href="https://discord.gg/bhtwpzURwd" rel="nofollow noopener" target="_blank">Discord 서버</a>를 통해 언제든 연락해 주시기 바랍니다. <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/%EB%B3%B4%EC%95%88" target="_blank">#보안</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/%EB%B3%B4%EC%95%88%ED%8C%A8%EC%B9%98" target="_blank">#보안패치</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/%EC%B7%A8%EC%95%BD%EC%A0%90" target="_blank">#취약점</a> <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/SSRF" target="_blank">#SSRF</a>

Fedify: an ActivityPub server frameworkWe have released <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/security" target="_blank">#security</a> updates (<a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a>, <a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a>) to address <a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">CVE-2025-23221</a>, a <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/vulnerability" target="_blank">#vulnerability</a> in <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/Fedify" target="_blank">#Fedify</a>'s <a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/WebFinger" target="_blank">#WebFinger</a> 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 <code>lookupWebFinger()</code> function that could be exploited to: <ul> <li>Perform denial of service attacks through infinite redirect loops</li> <li>Execute server-side request forgery (<a class="mention hashtag" rel="nofollow noopener" href="https://hollo.social/tags/SSRF" target="_blank">#SSRF</a>) attacks via redirects to private network addresses</li> <li>Access unintended URL schemes through redirect manipulation</li> </ul> Fixed Versions <ul> <li>1.3.x series: Update to <a href="https://github.com/dahlia/fedify/releases/tag/1.3.4" rel="nofollow noopener" target="_blank">1.3.4</a></li> <li>1.2.x series: Update to <a href="https://github.com/dahlia/fedify/releases/tag/1.2.11" rel="nofollow noopener" target="_blank">1.2.11</a></li> <li>1.1.x series: Update to <a href="https://github.com/dahlia/fedify/releases/tag/1.1.11" rel="nofollow noopener" target="_blank">1.1.11</a></li> <li>1.0.x series: Update to <a href="https://github.com/dahlia/fedify/releases/tag/1.0.14" rel="nofollow noopener" target="_blank">1.0.14</a></li> </ul> Changes The security updates implement the following fixes: <ol> <li>Added a maximum redirect limit (5) to prevent infinite redirect loops</li> <li>Restricted redirects to only follow the same scheme as the original request (HTTP/HTTPS)</li> <li>Blocked redirects to private network addresses to prevent SSRF attacks</li> </ol> How to Update To update to the latest secure version: <pre><code># For npm users npm update @fedify/fedify # For Deno users deno add jsr:@fedify/fedify </code></pre> 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 <a href="https://github.com/dahlia/fedify/security/advisories/GHSA-c59p-wq67-24wx" rel="nofollow noopener" target="_blank">security advisory</a>. If you have any questions or concerns, please don't hesitate to reach out through our <a href="https://github.com/dahlia/fedify/discussions" rel="nofollow noopener" target="_blank">GitHub Discussions</a>, join our <a href="https://matrix.to/#/#fedify:matrix.org" rel="nofollow noopener" target="_blank">Matrix chat space</a>, or our <a href="https://discord.gg/bhtwpzURwd" rel="nofollow noopener" target="_blank">Discord server</a>.

maschmiToday I performed a server side request forgery <a href="https://mastodon.social/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> 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 <a href="https://mastodon.social/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> issues when designing and implementing things. Only knowing of the attacks and possible countermeasures is way too passive for me.<a href="https://owasp.org/www-community/attacks/Server_Side_Request_Forgery" rel="nofollow noopener" translate="no" target="_blank">https://owasp.org/www-community/attacks/Server_Side_Request_Forgery</a>

FediTestTo all you <a href="https://mastodon.social/tags/developers" class="mention hashtag" rel="nofollow noopener" target="_blank">#developers</a> implementing <a href="https://mastodon.social/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> protections in your <a href="https://mastodon.social/tags/fediverse" class="mention hashtag" rel="nofollow noopener" target="_blank">#fediverse</a> applications...We are all in favor of those protections. But!Have a setting that lets projects like <a href="https://mastodon.social/tags/FediTest" class="mention hashtag" rel="nofollow noopener" target="_blank">#FediTest</a> 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 ...

🛡 H3lium@infosec.exchange/:~# :blinking_cursor:Security Bulletin: Atlassian June 2024Date: June 18, 2024 CVE: CVE-2024-22257 Vulnerability Type: Improper Authorization CWE: [[CWE-284]], [[CWE-918]], [[CWE-400]] Sources: <a href="https://confluence.atlassian.com/security/security-bulletin-june-18-2024-1409286211.html" rel="nofollow noopener" target="_blank">Atlassian Documentation</a>, <a href="https://nvd.nist.gov/vuln/detail/CVE-2024-22257" rel="nofollow noopener" target="_blank">NVD</a>SynopsisAtlassian has released a security bulletin addressing multiple high-severity vulnerabilities in its products. These vulnerabilities, discovered through the company's Bug Bounty program and third-party scans, have been fixed in recent versions.Issue SummaryNine high-severity vulnerabilities affecting various Atlassian products were disclosed. These vulnerabilities include issues such as improper authorization and server-side request forgery (SSRF) in dependencies like org.springframework.security:spring-security-core and org.springframework:spring-web. Confluence, Jira, and Fisheye/Crucible are among the affected products.Technical Key FindingsThe vulnerabilities primarily involve improper authorization and SSRF, which allow attackers to exploit insufficient validation of user inputs. For instance, CVE-2024-22257 involves improper authorization due to flaws in the org.springframework.security:spring-security-core dependency, potentially leading to unauthorized access.Vulnerable Products<ul><li>Confluence Data Center and Server: Versions 8.9.0 to 8.9.2, 8.8.0 to 8.8.1, 8.7.1 to 8.7.2, among others.</li><li>Fisheye/Crucible: Versions 4.8.10 to 4.8.14.</li><li>Jira Data Center and Server: Versions 9.12.0 to 9.12.7 (LTS), 9.4.0 to 9.4.20 (LTS).</li><li>Jira Service Management: Versions 5.15.2, 5.12.0 to 5.12.7 (LTS).</li></ul>Impact AssessmentExploiting these vulnerabilities could lead to unauthorized access, denial of service (DoS), or information disclosure, significantly impacting the confidentiality, integrity, and availability of the affected systems.Patches or WorkaroundPatches have been released for the affected products. Users are advised to update to the latest versions or apply the recommended fixed versions listed in the bulletin. No temporary mitigations are provided; hence, immediate patching is crucial.Tags<a href="https://infosec.exchange/tags/Atlassian" class="mention hashtag" rel="nofollow noopener" target="_blank">#Atlassian</a> <a href="https://infosec.exchange/tags/CVE" class="mention hashtag" rel="nofollow noopener" target="_blank">#CVE</a>-2024-22257 <a href="https://infosec.exchange/tags/ImproperAuthorization" class="mention hashtag" rel="nofollow noopener" target="_blank">#ImproperAuthorization</a> <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> <a href="https://infosec.exchange/tags/DoS" class="mention hashtag" rel="nofollow noopener" target="_blank">#DoS</a> <a href="https://infosec.exchange/tags/Confluence" class="mention hashtag" rel="nofollow noopener" target="_blank">#Confluence</a> <a href="https://infosec.exchange/tags/Jira" class="mention hashtag" rel="nofollow noopener" target="_blank">#Jira</a> <a href="https://infosec.exchange/tags/SecurityBulletin" class="mention hashtag" rel="nofollow noopener" target="_blank">#SecurityBulletin</a> <a href="https://infosec.exchange/tags/Vulnerability" class="mention hashtag" rel="nofollow noopener" target="_blank">#Vulnerability</a>

BillFuckin 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.<a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> <a href="https://infosec.exchange/tags/java" class="mention hashtag" rel="nofollow noopener" target="_blank">#java</a> <a href="https://infosec.exchange/tags/catalina" class="mention hashtag" rel="nofollow noopener" target="_blank">#catalina</a>

BillThe request looks like this: GET /nesp/app/?UniX:<<7701 random ASCII letters and numbers !symbols>>|http://localhost:22/ HTTP/1.1<a href="https://infosec.exchange/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#webdev</a> <a href="https://infosec.exchange/tags/linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#linux</a> <a href="https://infosec.exchange/tags/unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#unix</a> <a href="https://infosec.exchange/tags/windowsserver" class="mention hashtag" rel="nofollow noopener" target="_blank">#windowsserver</a> <a href="https://infosec.exchange/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> <a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a>

BillAlright 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.<a href="https://infosec.exchange/tags/webdev" class="mention hashtag" rel="nofollow noopener" target="_blank">#webdev</a> <a href="https://infosec.exchange/tags/linux" class="mention hashtag" rel="nofollow noopener" target="_blank">#linux</a> <a href="https://infosec.exchange/tags/unix" class="mention hashtag" rel="nofollow noopener" target="_blank">#unix</a> <a href="https://infosec.exchange/tags/windowsserver" class="mention hashtag" rel="nofollow noopener" target="_blank">#windowsserver</a> <a href="https://infosec.exchange/tags/security" class="mention hashtag" rel="nofollow noopener" target="_blank">#security</a> <a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a>

Karol MazurekI wrote a brief article on developing a black box fuzzer for assessing web applications that use a backend proxy that cannot be directly injected.The tool can also be used when you find an SSRF (Server Side Request Forgery) and want to find some incubated vulnerabilities.Enjoy reading! <a href="https://karol-mazurek.medium.com/proxy-fuzzing-4dc77968cfd8?sk=v2%2F5799b46b-6440-4d29-9aec-6736fa5eddc1" rel="nofollow noopener" translate="no" target="_blank">https://karol-mazurek.medium.com/proxy-fuzzing-4dc77968cfd8?sk=v2%2F5799b46b-6440-4d29-9aec-6736fa5eddc1</a><a href="https://infosec.exchange/tags/appsec" class="mention hashtag" rel="nofollow noopener" target="_blank">#appsec</a> <a href="https://infosec.exchange/tags/vulnerabilities" class="mention hashtag" rel="nofollow noopener" target="_blank">#vulnerabilities</a> <a href="https://infosec.exchange/tags/hacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#hacking</a> <a href="https://infosec.exchange/tags/fuzzing" class="mention hashtag" rel="nofollow noopener" target="_blank">#fuzzing</a> <a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> <a href="https://infosec.exchange/tags/webhooks" class="mention hashtag" rel="nofollow noopener" target="_blank">#webhooks</a>

securityaffairsExperts warn of a surge of attacks targeting <a href="https://infosec.exchange/tags/Ivanti" class="mention hashtag" rel="nofollow noopener" target="_blank">#Ivanti</a> <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> flaw  <a href="https://securityaffairs.com/158677/hacking/ivanti-ssrf-cve-2024-21893-under-attack.html" rel="nofollow noopener" translate="no" target="_blank">https://securityaffairs.com/158677/hacking/ivanti-ssrf-cve-2024-21893-under-attack.html</a> <a href="https://infosec.exchange/tags/securityaffairs" class="mention hashtag" rel="nofollow noopener" target="_blank">#securityaffairs</a> <a href="https://infosec.exchange/tags/hacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#hacking</a>

Marco IvaldiUnpatched Powerful <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> in <a href="https://infosec.exchange/tags/Exchange" class="mention hashtag" rel="nofollow noopener" target="_blank">#Exchange</a> <a href="https://infosec.exchange/tags/OWA" class="mention hashtag" rel="nofollow noopener" target="_blank">#OWA</a> – Getting Response Through Attachments <a href="https://www.zerodayinitiative.com/blog/2023/11/1/unpatched-powerful-ssrf-in-exchange-owa-getting-response-through-attachments" rel="nofollow noopener" translate="no" target="_blank">https://www.zerodayinitiative.com/blog/2023/11/1/unpatched-powerful-ssrf-in-exchange-owa-getting-response-through-attachments</a>

Olivier ForgetQuestion for <a href="https://social.tchncs.de/tags/selfhost" class="mention hashtag" rel="nofollow noopener" target="_blank">#selfhost</a> <a href="https://social.tchncs.de/tags/homelab" class="mention hashtag" rel="nofollow noopener" target="_blank">#homelab</a> <a href="https://social.tchncs.de/tags/server" class="mention hashtag" rel="nofollow noopener" target="_blank">#server</a> folks: how do you handle the threat of <a href="https://social.tchncs.de/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> 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? [1] <a href="https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html#case-2-application-can-send-requests-to-any-external-ip-address-or-domain-name" rel="nofollow noopener" translate="no" target="_blank">https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html#case-2-application-can-send-requests-to-any-external-ip-address-or-domain-name</a>

nopcornDuckDuckGo explicitly says they don’t care about bug reports involving SSRF on their image proxy. Weird. Anyone here know why? <a href="https://infosec.exchange/tags/bugbounty" class="mention hashtag" rel="nofollow noopener" target="_blank">#bugbounty</a> <a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> <a href="https://infosec.exchange/tags/proxy" class="mention hashtag" rel="nofollow noopener" target="_blank">#proxy</a> <a href="https://infosec.exchange/tags/duckduckgo" class="mention hashtag" rel="nofollow noopener" target="_blank">#duckduckgo</a> <a href="https://infosec.exchange/tags/ddg" class="mention hashtag" rel="nofollow noopener" target="_blank">#ddg</a>

r1cksecCLI for recon and write operations on Confluence and Jira instances 🔎 <a href="https://github.com/werdhaihai/AtlasReaper" rel="nofollow noopener" target="_blank">https://github.com/werdhaihai/AtlasReaper</a><a href="https://infosec.exchange/tags/jira" class="mention hashtag" rel="nofollow noopener" target="_blank">#jira</a> <a href="https://infosec.exchange/tags/confluence" class="mention hashtag" rel="nofollow noopener" target="_blank">#confluence</a> <a href="https://infosec.exchange/tags/loot" class="mention hashtag" rel="nofollow noopener" target="_blank">#loot</a> This tool is designed to help you find suitable SSRF candidates 🏄 <a href="https://github.com/assetnote/surf" rel="nofollow noopener" target="_blank">https://github.com/assetnote/surf</a><a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> <a href="https://infosec.exchange/tags/websecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#websecurity</a> <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosec</a>

.<a href="https://infosec.exchange/tags/100DaysOfHacking" class="mention hashtag" rel="nofollow noopener" target="_blank">#100DaysOfHacking</a> I'm going over the SSRF challenges again on Portswigger so I can screenshot for my next blog post on SSRF and I feel so much more confident going over them. It helps that I take notes for sure lol <a href="https://infosec.exchange/tags/infosec" class="mention hashtag" rel="nofollow noopener" target="_blank">#infosec</a> <a href="https://infosec.exchange/tags/burpsuite" class="mention hashtag" rel="nofollow noopener" target="_blank">#burpsuite</a> <a href="https://infosec.exchange/tags/ssrf" class="mention hashtag" rel="nofollow noopener" target="_blank">#ssrf</a> <a href="https://infosec.exchange/tags/cybersecurity" class="mention hashtag" rel="nofollow noopener" target="_blank">#cybersecurity</a> <a href="https://infosec.exchange/tags/learning" class="mention hashtag" rel="nofollow noopener" target="_blank">#learning</a> <a href="https://infosec.exchange/tags/study" class="mention hashtag" rel="nofollow noopener" target="_blank">#study</a>

Marco IvaldiMitigating <a href="https://infosec.exchange/tags/SSRF" class="mention hashtag" rel="nofollow noopener" target="_blank">#SSRF</a> in 2023// by Include Security<a href="https://blog.includesecurity.com/2023/03/mitigating-ssrf-in-2023/" rel="nofollow noopener" target="_blank">https://blog.includesecurity.com/2023/03/mitigating-ssrf-in-2023/</a>

Recent searches

Search options

Administered by:

Server stats:

#ssrf