From natasa.jakec at gmail.com Fri Mar 21 08:18:42 2025 From: natasa.jakec at gmail.com (=?UTF-8?B?TmF0YcWhYSBLLiBBcmg=?=) Date: Fri, 21 Mar 2025 09:18:42 +0100 Subject: [dev] =?utf-8?q?Horde_v_5=2E2=2E22_vulnerability_=E2=80=93_obfus?= =?utf-8?q?cation_via_HTML_encoding_=E2=80=93_XSS_payload?= In-Reply-To: References: Message-ID: Hi. A vulnerability within Horde Web Client was discovered during our investigation. We have already seen this vulnerability being exploited in the wild. If an attacker crafts a specially prepared email, he/she can abuse this vulnerability to retrieve username, password and complete email database of a user mailbox. *Details* The content inside email header base64 encoded text/html boundary contains a specially crafted HTML. --===============boundary== Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Injecting a XSS payload inside an HTML attribute, namely the “onerror” event handler, the server-side checks does not sanitize the payload and does not detect HTML encoded characters. When the browser renders the page, it will decode and execute the injected payload. This is injected at the end of the legit HTML content. Example:

Hi...

Regards
*

*

*

* ** To evade detection Unicode characters can be used: For eval: - \u{065} represents the Unicode character for the letter "e." - \u{076} represents the Unicode character for the letter "v." - \141 (octal) or \x6C (hexadecimal) represents the letter "a." - \x6C represents the hexadecimal for the letter "l." For atob: - \u{61} represents the Unicode character for the letter "a." - \u{74} represents the Unicode character for the letter "t." - o is a regular character. - \142 (octal) represents the letter "b." Example:

Hi...

Regards
*

* The “nonexsisting.png” image is searched inside /imp, since it does not exist the “onerror” content is executed. A specially crafted JavaScript code inside the *'base64 encoded JavaScript'* is executed. This kind of crafted email is a zero-click attack, where no click is needed from a user side other then looking this email in the Horde web client. Since there are still Horde web clients used, it would be nice to fix this vulnerability. -- Regards. From natasa.jakec at gmail.com Fri Mar 21 09:04:40 2025 From: natasa.jakec at gmail.com (=?UTF-8?B?TmF0YcWhYSBLLiBBcmg=?=) Date: Fri, 21 Mar 2025 10:04:40 +0100 Subject: [dev] =?utf-8?q?Horde_v_5=2E2=2E22_vulnerability_=E2=80=93_obfus?= =?utf-8?q?cation_via_HTML_encoding_=E2=80=93_XSS_payload?= In-Reply-To: References:

Message-ID: Hi. I forgot to mention that currently the fastest way to mitigate the vulnerability is to disable HTML email view and enable only text/plain view of the email content. Regards, Tasha & Vito On Fri, Mar 21, 2025 at 9:18 AM Nataša K. Arh wrote: > Hi. > > A vulnerability within Horde Web Client was discovered during our > investigation. We have already seen this vulnerability being exploited in > the wild. > > If an attacker crafts a specially prepared email, he/she can abuse this > vulnerability to retrieve username, password and complete email database > of a user mailbox. > > > *Details* > > The content inside email header base64 encoded text/html boundary contains > a specially crafted HTML. > > > --===============boundary== > > Content-Type: text/html; charset="utf-8" > > Content-Transfer-Encoding: base64 > > MIME-Version: 1.0 > > > Injecting a XSS payload inside an HTML attribute, namely the “onerror” > event handler, the server-side checks does not sanitize the payload and > does not detect HTML encoded characters. > > When the browser renders the page, it will decode and execute the injected > payload. > > This is injected at the end of the legit HTML content. > > > Example: > > > > > >

Hi...

> > Regards
> > *

*
>
> *

onerror="window.parent.eval(window.parent.atob('base64 encoded > JavaScript'));">* > > ** > > > > > To evade detection Unicode characters can be used: > For eval: > - \u{065} represents the Unicode character for the letter "e." > - \u{076} represents the Unicode character for the letter "v." > - \141 (octal) or \x6C (hexadecimal) represents the letter "a." > - \x6C represents the hexadecimal for the letter "l." > > For atob: > - \u{61} represents the Unicode character for the letter "a." > - \u{74} represents the Unicode character for the letter "t." > - o is a regular character. > - \142 (octal) represents the letter "b." > > Example: > > > >

Hi...

> Regards
> *

* onerror="window.parent['\u{065}\u{076}\141\x6C'](window.parent['\u{61}\u{74}o\142']('base64 > encoded JavaScript'))">* > > > The “nonexsisting.png” image is searched inside /imp, since it does not > exist the “onerror” content is executed. > > A specially crafted JavaScript code inside the *'base64 encoded > JavaScript'* is executed. > > This kind of crafted email is a zero-click attack, where no click is > needed from a user side other then looking this email in the Horde web > client. > > Since there are still Horde web clients used, it would be nice to fix this > vulnerability. > > > > -- > Regards. > From natasa.jakec at gmail.com Fri Mar 21 11:53:27 2025 From: natasa.jakec at gmail.com (=?UTF-8?B?TmF0YcWhYSBLLiBBcmg=?=) Date: Fri, 21 Mar 2025 12:53:27 +0100 Subject: [dev] =?utf-8?q?Horde_v_5=2E2=2E22_vulnerability_=E2=80=93_obfus?= =?utf-8?q?cation_via_HTML_encoding_=E2=80=93_XSS_payload?= In-Reply-To: References:

Message-ID: The vulnerability was tested on latest version as stated here: https://www.horde.org/download/imp, but with applied patches: Horde 5.2.23 IMP 6.2.27 Regards. From jmstoorvogel at stoorvogelsoftware.nl Fri Mar 21 15:15:23 2025 From: jmstoorvogel at stoorvogelsoftware.nl (J.M. Stoorvogel) Date: Fri, 21 Mar 2025 15:15:23 +0000 Subject: [dev] =?utf-8?q?Horde_v_5=2E2=2E22_vulnerability_=E2=80=93_obfus?= =?utf-8?q?cation_via_HTML_encoding_=E2=80=93_XSS_payload?= In-Reply-To: References:

Message-ID: <20250321151523.Horde.twB53zuTzCykB8ftG6kA28s@horde.stoorvogelsoftware.nl> Citeren Nataša K. Arh : > Hi. > > I forgot to mention that currently the fastest way to mitigate the > vulnerability is to disable HTML email view and enable only text/plain view > of the email content. > > > Regards, Tasha & Vito > > On Fri, Mar 21, 2025 at 9:18 AM Nataša K. Arh > wrote: > >> Hi. >> >> A vulnerability within Horde Web Client was discovered during our >> investigation. We have already seen this vulnerability being exploited in >> the wild. >> >> If an attacker crafts a specially prepared email, he/she can abuse this >> vulnerability to retrieve username, password and complete email database >> of a user mailbox. >> >> >> *Details* >> >> The content inside email header base64 encoded text/html boundary contains >> a specially crafted HTML. >> >> >> --===============boundary== >> >> Content-Type: text/html; charset="utf-8" >> >> Content-Transfer-Encoding: base64 >> >> MIME-Version: 1.0 >> >> >> Injecting a XSS payload inside an HTML attribute, namely the “onerror” >> event handler, the server-side checks does not sanitize the payload and >> does not detect HTML encoded characters. >> >> When the browser renders the page, it will decode and execute the injected >> payload. >> >> This is injected at the end of the legit HTML content. >> >> >> Example: >> >> >> >> >> >>

Hi...

>> >> Regards
>> >> *

*
>>
>> *

> onerror="window.parent.eval(window.parent.atob('base64 encoded >> JavaScript'));">* >> >> ** >> >> >> >> >> To evade detection Unicode characters can be used: >> For eval: >> - \u{065} represents the Unicode character for the letter "e." >> - \u{076} represents the Unicode character for the letter "v." >> - \141 (octal) or \x6C (hexadecimal) represents the letter "a." >> - \x6C represents the hexadecimal for the letter "l." >> >> For atob: >> - \u{61} represents the Unicode character for the letter "a." >> - \u{74} represents the Unicode character for the letter "t." >> - o is a regular character. >> - \142 (octal) represents the letter "b." >> >> Example: >> >> >> >>

Hi...

>> Regards
>> *

> * >> onerror="window.parent['\u{065}\u{076}\141\x6C'](window.parent['\u{61}\u{74}o\142']('base64 >> encoded JavaScript'))">* >> >> >> The “nonexsisting.png” image is searched inside /imp, since it does not >> exist the “onerror” content is executed. >> >> A specially crafted JavaScript code inside the *'base64 encoded >> JavaScript'* is executed. >> >> This kind of crafted email is a zero-click attack, where no click is >> needed from a user side other then looking this email in the Horde web >> client. >> >> Since there are still Horde web clients used, it would be nice to fix this >> vulnerability. >> >> >> >> -- >> Regards. >> > -- > dev mailing list > Frequently Asked Questions: http://wiki.horde.org/FAQ > To unsubscribe, mail: dev-unsubscribe at lists.horde.org in bundle/vendor/horde/text_filter/lib/Horde/Text/Filter: /** * This filter attempts to make HTML safe for viewing. IT IS NOT PERFECT. If * you enable HTML viewing, you are opening a security hole. So patching this one hole won't fill the other unknown ones... -- Met vriendelijke groet, J.M. Stoorvogel 06-23352273 From jmstoorvogel at stoorvogelsoftware.nl Fri Mar 21 15:09:25 2025 From: jmstoorvogel at stoorvogelsoftware.nl (J.M. Stoorvogel) Date: Fri, 21 Mar 2025 15:09:25 +0000 Subject: [dev] =?utf-8?q?Horde_v_5=2E2=2E22_vulnerability_=E2=80=93_obfus?= =?utf-8?q?cation_via_HTML_encoding_=E2=80=93_XSS_payload?= In-Reply-To: References:

Message-ID: <20250321150925.Horde.rgyN9Ft8xSVkbQqCwdsCReB@horde.stoorvogelsoftware.nl> Citeren Nataša K. Arh : > Hi. > > I forgot to mention that currently the fastest way to mitigate the > vulnerability is to disable HTML email view and enable only text/plain view > of the email content. > > > Regards, Tasha & Vito > > On Fri, Mar 21, 2025 at 9:18 AM Nataša K. Arh > wrote: > >> Hi. >> >> A vulnerability within Horde Web Client was discovered during our >> investigation. We have already seen this vulnerability being exploited in >> the wild. >> >> If an attacker crafts a specially prepared email, he/she can abuse this >> vulnerability to retrieve username, password and complete email database >> of a user mailbox. >> >> >> *Details* >> >> The content inside email header base64 encoded text/html boundary contains >> a specially crafted HTML. >> >> >> --===============boundary== >> >> Content-Type: text/html; charset="utf-8" >> >> Content-Transfer-Encoding: base64 >> >> MIME-Version: 1.0 >> >> >> Injecting a XSS payload inside an HTML attribute, namely the “onerror” >> event handler, the server-side checks does not sanitize the payload and >> does not detect HTML encoded characters. >> >> When the browser renders the page, it will decode and execute the injected >> payload. >> >> This is injected at the end of the legit HTML content. >> >> >> Example: >> >> >> >> >> >>

Hi...

>> >> Regards
>> >> *

*
>>
>> *

Hi...

>> Regards
>> *

> * >> onerror="window.parent['\u{065}\u{076}\141\x6C'](window.parent['\u{61}\u{74}o\142']('base64 >> encoded JavaScript'))">* >> >> >> The “nonexsisting.png” image is searched inside /imp, since it does not >> exist the “onerror” content is executed. >> >> A specially crafted JavaScript code inside the *'base64 encoded >> JavaScript'* is executed. >> >> This kind of crafted email is a zero-click attack, where no click is >> needed from a user side other then looking this email in the Horde web >> client. >> >> Since there are still Horde web clients used, it would be nice to fix this >> vulnerability. >> >> >> >> -- >> Regards. >> > -- > dev mailing listj > Frequently Asked Questions: http://wiki.horde.org/FAQ > To unsubscribe, mail: dev-unsubscribe at lists.horde.org I'm always very intrigued by those attacks. HTML + Javascript simply is an insecure mess, most likely exploits will always be found whenever HTML evolves. Disabling it is the safest way. However, apparently this testcase should be added to horde/text_filter/test/Horde/Text/Filter/XssTest.php Now I'm still searching because I cannot find anything in the Horde source because imho it lacks MVC or any other design pattern structures in the trees. Please enlighten me if I'm missing something... I've recently added a html filter because Word/Office formatting in mails completely f*cked up the layout (starting on a new page when printing, leaving only the inserted header on the first page). So when I've found the appropriate source, a regex should be inserted to discard the onload part within the tag. Any ideas or tips? -- Met vriendelijke groet, J.M. Stoorvogel 06-23352273