[FD] SwiftMailer <= 5.4.5-DEV Remote Code Execution (CVE-2016-10074)

[Dawid Golunski]

Vulnerability:
SwiftMailer <= 5.4.5-DEV Remote Code Execution (CVE-2016-10074)

Discovered by: Dawid Golunski (@dawid_golunski)
https://legalhackers.com

Severity: CRITICAL

Desc:

An independent research uncovered a critical vulnerability in SwiftMailer that
could potentially be used by (unauthenticated) remote attackers to achieve
remote arbitrary code execution in the context of the web server user and
remotely compromise the target web application.

To exploit the vulnerability an attacker could target common website
components such as contact/feedback forms, registration forms, password
email resets and others that send out emails with the help of a vulnerable
version of the SwiftMailer class.

Despite the significant efforts in responsibly disclosing the vulnerability
to the vendor (since 2nd December).
The vulnerability remains unfixed as of 28 December.


The full advisory at:

http://legalhackers.com/advisories/SwiftMailer-Exploit-Remote-Code-Exec-CVE-2016-10074-Vuln.html

The Video PoC will be very similar to:
http://legalhackers.com/advisories/PHPMailer-Exploit-Remote-Code-Exec-CVE-2016-10033-Vuln.html

The SwiftMailer PoC exploit:
https://legalhackers.com/exploits/CVE-2016-10074/SwiftMailer_PoC_RCE_Exploit.txt

More updates soon:
https://twitter.com/dawid_golunski



-- 
Regards,
Dawid Golunski
https://legalhackers.com
t: @dawid_golunski

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

Re: [FD] [RT-SA-2016-001] Padding Oracle in Apache mod_session_crypto

[Erik Auerswald]

Hi,

On Tue, Dec 27, 2016 at 09:01:49AM -0800, Tim wrote:
> [...]
> > 
> > But there still are people who use CBC...
> > [...]
> 
> All traditional modes that lack integrity protection are vulnerable to
> chosen-ciphertext attacks in these kinds of scenarios.
> [...]
> All traditional modes need a MAC or similar integrity protection.

That is correct.

> In light of that, there's
> nothing particularly wrong with using CBC, if it is implemented well.
> At least, using it is not *more* wrong than using OFB, CFB, or CTR

That is wrong. CBC mode allows attacks such as "Sweet32"
(https://sweet32.info/), which is not possible with CTR mode.

> without integrity protection.

Correct again, but too simple minded. Any encryption without integrity
protection does not provide confidentiality against an active attacker.
Using the wrong mode with a block cipher can render authentication
irrelevant in attacks on confidentiality.

> [...]
> We should instead be pointing developers in
> the direction of using something off-the-shelf [...].
> Much less room for error.

That is sound advice. In addition, broken ciphers, modes, and protocols
still implemented for backwards compatibility should not be used.

Thanks,
Erik
-- 
[A]pplied cryptography mostly sucks.
-- Green's law of applied cryptography

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

[FD] Executable installers are vulnerable^WEVIL (case 42): SoftMaker's FreeOffice installer allows escalation of privilege

[Stefan Kanthak]

Hi @ll,

the installers of SoftMaker's FreeOffice 2016, "freeoffice2016.exe",
available from ,
and its predecessor FreeOffice 2010, "freeofficewindows.exe",
available from ,
are (surprise.-) vulnerable!


1. They load CABINET.DLL, MSI.DLL, VERSION.DLL and WINSPOOL.DRV from
   their "application directory" instead of Windows' "system directory"
   %SystemRoot%\System32\, resulting in "arbitrary code execution".

   For this well-known vulnerability see
   ,
   ,
   
   ,
    and
    plus
   
,
   
,
    and
   :

   The "application directory" is typically the user's "Downloads"
   folder, where an attacker can place these DLLs for example per
   "drive-by download".

   Thanks to the embedded application manifest which specifies
   "requireAdministrator" the executable installer can only be run
   with administrative privileges, resulting in "arbitrary code
   execution" WITH "elevation of privilege".


2. The installer creates an UNPROTECTED directory "%TEMP%\\",
   writable by the unprivileged user, to extracts the files uinst.exe,
   SETUP_1.CAB and SETUP_2.CAB, then extracts an .MSI from the .CABs
   and calls "MSIEXEC.EXE /i ...MSI" to finally install FreeOffice.

   Thanks to the unprotected directory an attacker can modify the
   extracted files and is able to gain SYSTEM privilege.

   For this well-known vulnerability see
    and
   


The installers are built using dotNetinstaller from dblock.org.
STAY AWAY FROM THIS CRAP!


Mitigations:


* Don't use executable installers! NEVER!

  See  and
   plus
   alias
   for more
  information.

* Practice STRICT privilege separation: NEVER use the so-called
  "protected" administrator account(s) created during Windows
  setup.

* Add an ACE "(D;OIIO;WP;;;WD)" to the ACL of every "%USERPROFILE%";
  use  to
  decode it to "deny execution of files in this directory for
  everyone, inheritable to all files in all subdirectories".


stay tuned
Stefan Kanthak


Timeline:
~

2015-11-18sent vulnerability report for version 2010 to vendor

  received an auto-generated reply: we are busy

2015-12-27resent vulnerability report to vendor

2016-01-07vendor replies: fixed in latest release of
  FreeOffice 2010 from 2015-12-15

2016-01-07OUCH!
  The vulnerability is NOT fixed!

2016-01-19vendor replies: loading of CABINET.DLL and MSI.DLL
  should be fixed, but we can't fix WINSPOOL.DRV for now

2016-04-19sent vulnerability report for new version 2016 to
  vendor

  no reply, not even an acknowledgement of receipt

2016-12-12sent vulnerability report to vendor and author of
  installer

  no reply, not even an acknowledgement of receipt

2016-12-19resent vulnerability report to vendor and author of
  installer

  no reply, not even an acknowledgement of receipt

2016-12-29report published

___
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/