[FD] [KIS-2016-01] CakePHP <= 3.2.0 "_method" CSRF Protection Bypass Vulnerability

[Egidio Romano]

---
CakePHP <= 3.2.0 "_method" CSRF Protection Bypass Vulnerability
---


[-] Software Link:

http://cakephp.org


[-] Affected Versions:

Version 3.2.0 RC1 and prior 3.x versions.
Version 2.8.0 RC1 and prior 2.x versions.   


[-] Vulnerability Description:

CakePHP provides some built-in security features including CSRF and Form 
Tampering protection.
Under certain circumstances it might be possible to bypass such security 
checks, since they are
performed only when the HTTP request is e.g. POST or PUT. CakePHP’s Router 
class uses a number
of different indicators to detect the HTTP method being used, like the 
"_method" POST parameter
and the "X_HTTP_METHOD_OVERRIDE" and "REQUEST_METHOD" headers. By abusing this 
behavior an
attacker might be able to carry out CSRF attacks against CakePHP applications 
which do not
check the HTTP method being used before executing side-effects. This is 
possible by overriding
the HTTP method with a web page like this:



http://[HOST]/user/add; method="POST">




document.forms[0].submit()




[-] Solution:

No official solution is currently available. The vendor updated the official 
documentation
stating that developers should always check the HTTP method before executing 
side-effects.

NOTE: version 3.1.5 includes a bugfix for this issue stating "CSRF validation 
is applied to
all HTTP methods that are not ‘GET’, ‘OPTIONS’ or ‘HEAD’. This prevents invalid 
HTTP methods
from bypassing CSRF validation.", however this is a partial fix which does not 
solve the
vulnerability, because the bypass might still work by using one of the 
unprotected HTTP methods.


[-] Disclosure Timeline:

[10/11/2015] - Vendor notified
[26/11/2015] - Vendor tried to mitigate the issue with the following commit: 
https://git.io/vzcda
[01/12/2015] - Vendor response stating this issue has been addressed in version 
3.1.5 and the documentation has been updated
[01/12/2015] - CVE number requested
[01/12/2015] - CVE number assigned
[12/01/2016] - Public disclosure


[-] CVE Reference:

The Common Vulnerabilities and Exposures project (cve.mitre.org)
has assigned the name CVE-2015-8379 to this vulnerability.


[-] Credits:

Vulnerability discovered by Egidio Romano of Minded Security.


[-] Original Advisory:

http://karmainsecurity.com/KIS-2016-01


[-] Other References:

http://blog.mindedsecurity.com/2016/01/request-parameter-method-may-lead-to.html

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

[FD] [TOOL] The Metabrik Platform

[GomoR]

Hi list,

I would like to introduce you to The Metabrik Platform, please find a 
complete description below.


For the impatient, you can see it in action at the following link:
http://www.metabrik.org/blog/2016/01/09/malware-analysis-with-vm-instrumentation-wmi-winexe-volatility-and-metabrik/

The Metabrik Platform bind togother a classic Shell with a Perl 
interpreter as a REPL (Read-Eval-Print-Loop) and a ton of small Briks. 
Briks are reusable components each performing a specific task. You chain 
Briks together using Perl variables, they are used to pass output of a 
Brik Command as input for another Brik Command.


By chaining Briks together, you easily create new powerful tools, just 
like the UNIX pipe.

Today, there is more than 170 Briks available.

Metabrik goals:

- Glue the Perl language with a shell
- Give a standardised API to write reusable Briks
- Self-documented Briks to make them easy to use
- Only 4 main shell commands to remember: use, set, get, run

Metabrik features:

- Completion on Brik names, Commands and Attributes
- Completion on file manipulation
- Completion on Perl variable names
- Command history and recalling
- Customization support with a .rc file
- Scripting support
- Multiple Brik repositories support

Metabrik helps you to concentrate on scenarios instead of wasting your 
time searching how to use a program.

You just have to reuse available Briks to perform your everyday job.

Briks also share the same syntax so you don’t have to scratch your head 
each time you use yet-another-tool, and they also feature integrated 
help.


For more, visit http://www.metabrik.org/

Regards,

--
http://patriceauffret.com/ - @PatriceAuffret
http://www.metabrik.org/ - @metabrik

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

[FD] [CVE-2016-0014] Executable installers are vulnerable^WEVIL (case 1): Microsoft's IExpress resp. WExtract, SFXCab, BoxStub, ...

[Stefan Kanthak]

Hi @ll,

IExpress ()
creates executable installers [°] or self-extracting archives for
Windows by embedding a .CAB archive and some strings as resources
into a copy of the program %SystemRoot%\System32\WExtract.exe.

These self-extracting archives/executable installers, especially
those made by Microsoft ['] (available in the Microsoft download
center or distributed per Windows Update), are vulnerable:

1. If built with WExtract.exe of a system supporting the NTFS
   "encrypting file system", i.e. Windows NT5.x, Windows NT6.x or
   Windows 10, and run under these versions of Windows, they load
   and execute a rogue/bogus/malicious FEClient.dll [²] eventually
   found in the directory they are started from (the "application
   directory").

   For software downloaded with a web browser this is typically the
   "Downloads" directory: see
   
,
   
   and 

   If FEClient.dll gets planted in the "Downloads" directory per
   "drive-by download" this vulnerability becomes a remote code
   execution.

   Due to an application manifest embedded in the executable which
   specifies "requireAdministrator" or the "installer detection" (see
   )
   of Windows' "user account control" executable installers are
   typically started with administrative privileges ("protected"
   administrators are prompted for consent, unprivileged standard
   users are prompted for an administrator password); execution of
   FEClient.dll then results in an escalation of privilege!

2. They call CreateProcess() with command line(s) set during package
   creation.
   These command lines have to be specified with unqualified (simple)
   filenames since the absolute pathnames on the target system are
   unknown. Due to CreateProcess() process search order they will run
   rogue executables with the specified simple filename(s) eventually
   found in the directory they are started from.

   See .

   DON'T USE 
   (especially step 8. which uses simple filenames in the command
   line)!

   DON'T USE 
   (especially step 3.h. which uses simple filenames in the command
   line)!

3. They extract their payload to an unsafe temporary (sub)directory
   "%TEMP%\IXP<3_digits>.TMP\" and process or execute it from there [³].

   The files comprising the payload can be overwritten or compromised
   by an unprivileged user after extraction and before their later use.

4. Executable (un)installers distributed per software deployment system
   (for example WSUS) or wrapped into a .MSI for deployment per group
   policies are (typically) run under "LocalSystem" account.

   From :

   | The list of trusted root certificates is available as a self-
   | extracting IEXPRESS package in the Microsoft Download Center, the
   | Windows catalog, or by using Windows Server Update Services (WSUS).
   ...
   | The list of untrusted certificates comes as a self-extracting
   | IEXPRESS package in a mandatory security Windows Update.

   Processes running under "LocalSystem" account use the global
   %TEMP% directory %SystemRoot%\Temp where (unprivileged) users
   can create (or overwrite) files and conduct all these attacks.

   For a recent example of such a vulnerability see
   


Proof of concept/demonstration:
~~~

1. visit , download
    and save
   it as FEClient.dll in your "Downloads" directory;

2. download the AntiMalware Definition Updater MPAM-D.EXE or
   MPAM-FE[X64].EXE (see ,
    and
   )
   and save it in your "Downloads" directory;

3. execute MPAM-*.EXE from your "Downloads" directory;

4. notice the message box displayed from FEClient.dll placed in step 1.


Instead of MPAM-*.EXE you can use ALMOST ANY other executable installer
available from the Microsoft Download Center or via Windows Update!

Just to pick (pun intended.-) a few:

* Windows-KB890830-v*.exe, the malicious software removal tool,
  

  or
  


* ROOTSUPD-KB931125-*.exe, the root 

Re: [FD] Combining DLL hijacking with USB keyboard emulation

[Rodrigo Menezes]

While I agree that there is a lot you can do if you can plug a
malicious USB device into a computer and that you might not need
to take advantage of the DLL problem in order to successfully
complete the attack, my point is that it could help.

Consider that the attack could be carried out either by
convincing the user to plug in the USB device or by sneakly
plugging it into their computer while they're away. Therefore,
reducing the time it takes to complete and how much fuzz it
makes on the screen could be a great advantage in a lot of
situations.

In my own experiments, a payload that simply starts transfering
a DLL completes in about six seconds. You can unplug the device
in less time than that, right after it opens cmd and starts the
execution of the one line of commands. This is quicker than any
other I've seen before.

 On Sat, 09 Jan 2016 08:14:03 -0200  wrote  
 > On 2016-01-08 00:50:51 -0200, Rodrigo Menezes wrote: 
 >  
 >  > Many of us have now been long aware of the possibility of 
 >  > programming an USB device to emulate a keyboard and automatically 
 >  > send keystrokes in order to perform malicious actions on a 
 >  > computer. Some of the most interesting payloads that can be used 
 >  > with this technique are based around downloading or creating an 
 >  > executable file and then running it. 
 >  > I'd like to bring to light that this attack could be combined 
 >  > with DLL hijacking, with some benefits for the attacker. 
 >  > For instance, a payload which simply downloads a DLL to the 
 >  > current user's folder tends to complete faster and be more 
 >  > reliable than one which tries to transfer an executable 
 >  > AND immediately run it. The DLL would then most likely 
 >  > be found and executed by a vulnerable installer [...] This way, 
 >  > there would be no need for embeeding in the payload a complicated 
 >  > attempt of bypassing the active defense mechanisms. 
 >  
 > Once you can fool the user to plug the USB device, you don't need 
 > anything else. The device may appear as 
 > 1. A mass storage, and 
 > 2. A keyboard or any other HID, and 
 > 3. Some unknown hardware 
 >  
 > Once the W-ndows enumerates this hardware, it will try to find and 
 > automatically install drivers for it. With a mass storage and a 
 > keyboard it will succeed, thus immediately bringing them to use, 
 > and unknown hardware would bring up a "search for drivers" dialog, 
 > where the attacker may (after some delay) send keystrokes to choose 
 > "search removable devices for drivers". Obviously, the mass storage 
 > part of the USB device would contain suitable .inf file pointing to 
 > malicious binaries. 
 >  
 > The USB device capable of performing such attack may be as simple 
 > as ATtiny85 + 25Q64 chips (both are available in a 3*4 mm SOP8), 
 > with a total cost of 1 EUR. The 25Q64 offers 8 Mbyte of storage, 
 > which is well enough for almost anything. 
 >  
 >  
 > --  
 > Alexey V. Vissarionov aka Gremlin from Kremlin 
 > GPG: 8832FE9FA791F7968AC96E4E909DAC45EF3B1FA8 
 >  
 > ___ 
 > Sent through the Full Disclosure mailing list 
 > https://nmap.org/mailman/listinfo/fulldisclosure 
 > Web Archives & RSS: http://seclists.org/fulldisclosure/ 
 > 



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

[FD] CCA on CoreProc/crypto-guard and an Appeal to PHP Programmers

[Scott Arciszewski]

Hi Full Disclosure Readers,

Let's jump right into the vulnerability:

In May of last year, I reported to CryptoGuard that their cryptography
wasn't guarding against chosen-ciphertext attacks, which is the sort of
oversight that would allow me to intercept a ciphertext message then keep
feeding it back into the decryption process with slight alterations until I
recovered the plaintext.

https://github.com/CoreProc/crypto-guard/issues/1

And then several months passed, and I forgot it even existed. I got a
notification last night that they closed the issue, and eagerly tagged a
v1.0.0 release. So I looked again a bit more carefully and I discovered
that they were using their IV as an HMAC key.

https://github.com/CoreProc/crypto-guard/issues/3

Experienced infosec folks are probably expecting me to say, "Don't roll
your own crypto." And they're half right. You probably shouldn't write your
own crypto code, be it for encrypting text, storing passwords, or storing
all of your session state in a cookie (shudder). But I've come to realize
that telling programmers not to write crypto is like telling teenagers to
practice abstinence.

Instead, I implore you to follow the advice of Taylor Hornby (Defuse
Security, Crackstation, CryptoFails, etc.):

http://www.cryptofails.com/post/75204435608/write-crypto-code-dont-publish-it

Crypto Amateurs: Write Crypto Code! Don't Publish It!
-

Publishing crypto code means either publishing it online or deploying it in
production. There are risks associated with both.

* Deploying: You've just deployed vulnerable code to your company's server.
Well done.
* Publishing: You've left another land mine for other developers to
accidentally step on.

The above CryptoGuard library? People not only use it, they actively
recommend it to other developers.

* http://stackoverflow.com/a/27497122/2224584
* http://stackoverflow.com/a/27471590/2224584
* http://stackoverflow.com/q/28700653/2224584

Earlier this year I found a dubious attempt to port GnuPG to PHP:
https://github.com/jasonhinkle/php-gpg

To make a long story short, here's someone asking for advice on how to
integrate with it: https://twitter.com/Raed667/status/666037143224102912

I'd like to propose the following workflow (Pastebin:
http://pastebin.com/raw/1ap1dX4z)

  .---,
  | START |   .---,
  `---+---'   | OK, cool. |<,
  | .-,   '+--'  |
  '>+ Am I rolling my own +' |
|cryptography?|   No |
'--+--'  |
   | Yes |
   v |
   .---+---. | OK
   | Do I have enough money in my  |.+-,
   | project's budget allocated to +--->| You should do that then. |
   | hire a cryptography expert to |  Yes   `--'
   | review my implementation? |
   `---+---'
   | No
   v
.-,
| Don't publish or deploy it. |
`-'


I hope you find my proposal to be sane and reasonable enough to adhere to,
for the sake of your own applications.

Please share this flowchart with every (especially but necessarily PHP)
programmer you know until these mistakes are eradicated and/or sufficiently
discouraged.

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises 

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

Re: [FD] Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege

[Stefan Kanthak]

"Michel Arboi"  wrote:

> On 11 January 2016 at 15:37, Stefan Kanthak  wrote:
>> Which but does not mean/imply that everybody abandons TrueCrypt.
> 
> The project has been abruptly killed by the developers without any
> clear explanation. There's something fishy and it cannot be trusted
> anymore.
> Spend your time and energy on forks like CipherShed or VeraCrypt!

See  alias CVE-2016-1281

And see  again:

| almost all executable installers (and self-extractors as well
| as "portable" applications too) for Windows have a well-known
| (trivial, trivial to detect and trivial to exploit) vulnerability:

>> STOP posting on top, but DON'T stop reading on top, read that
>> page COMPLETELY and notice the download(s) offered at its end!
> 
> AFAIK, TrueCrypt 7.2 is only capable of decryption. It is provided so
> that users can migrate their data to another system.

and has a vulnerable installer, like all its predecessors and all
forks of TrueCrypt.

stay tuned
Stefan Kanthak

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

[FD] Defense in depth -- the Microsoft way (part 38): does Microsoft follow their own security guidance/advisories?

[Stefan Kanthak]

Hi @ll,

in 2009/2010, after beeing hit by "carpet bombing" and "binary
planting" alias "DLL hijacking/spoofing/preloading" (see

and )
Microsoft finally started to provide security guidance/advisories
for "safe library loading" to Windows developers:



| Applications can control the location from which a DLL is loaded by
| specifying a full path or using another mechanism such as a manifest.



| Wherever possible, specify a fully qualified path when using the
| LoadLibrary, LoadLibraryEx [...] functions.



| When an application loads a DLL without specifying a fully
| qualified path name, Windows will attempt to locate the DLL by
| searching a defined set of directories.
...
| Development best practices state that applications should call
| SetDllDirectory with a blank path before calling
| LoadLibrary("foo.dll") to ensure that foo.dll is not loaded from
| the current directory. We are investigating whether any of our
| own applications are affected by this class of vulnerability so
| that we can take appropriate action to protect customers.



| Use fully qualified paths for all calls to LoadLibrary, [...]
| where you can.



| This exploit may occur when applications do not directly specify
| the fully qualified path to a library it intends to load.



| Always specify the fully qualified path when the library location
| is constant.


Now the (obviously rhetorical) question: does Microsoft follow their
own guidance?

The (also obvious) answer: THEY DON'T, at least for existing code,
despite "trustworty computing" or the "secure development lifecycle"
Microsoft brags about since years.


Some examples for unsafe library loading recently published:

FEClient.dll (see CVE-2016-0014 and MS16-007):
  introduced in Windows 2000, loaded without fully qualified path
  by AdvAPI32.dll since then.

  FEClient.dll is loaded from the "application directory" of every
  program which uses EFS functions (see
  
  and ):
  all executable installers and self-extractors used by Microsoft
  allow^Wsupport "DLL hijacking" via FEClient.dll!


OCIW32.dll, OCI.dll (see MS15-132):
  loaded without fully qualified path by MSDAORA.DLL since Windows NT4.


ELSEXT.dll (see MS15-132):
  loaded without fully qualified path by ELS.DLL since Windows Vista.


MQRT.dll (see MS15-132):
  loaded without fully qualified path by COMSVCS.DLL since Windows NT4.


EDBBCli.dll, ESEBCli2.dll (see MSKB275876):
  loaded without fully qualified path by NTBackup.exe since Windows NT4.

  Mitigation:
  ~~~

  [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File 
Execution Options\NTBackup.exe]
  "CWDIllegalInDLLSearch"=dword:

  [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\BackupRestore\DLLPaths]
  "EDBBCli"="C:\\Windows\\System32\\Kernel32.Dll"
  "ESEBCli2"="C:\\Windows\\System32\\Kernel32.Dll"


UXTheme.dll (see CVE-2012-4206, ...):
  introduced in Windows XP, loaded without fully qualified path by
  AppWiz.cpl, BrowseUI.dll, ComDlg32.dll, Dot3UI.dll, DUser.dll,
  Explorer.exe, HelpCtr.exe, Kernel32.dll, LogonUI.exe, MMC.exe,
  MSHTML.dll, Shell32.dll, ShlWAPI.dll, ThemeUI.dll, WSCUI.dll,
  WZCDlg.dll and MANY more since then.

  Almost all executables using the Windows GUI allow^Wsupport
  "DLL hijacking" via UXTheme.dll.

  Mitigation: 
  ~~~

  use SAFER alias Software Restriction Policies and deny execution
  everywhere except %SystemRoot% and below and %ProgramFiles% and
  below.

  See  and/or
   for instructions.


stay tuned
Stefan Kanthak

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

Re: [FD] Executable installers are vulnerable^WEVIL (case 20): TrueCrypt's installers allow arbitrary (remote) code execution and escalation of privilege

[Michel Arboi]

On 11 January 2016 at 15:37, Stefan Kanthak  wrote:
> Which but does not mean/imply that everybody abandons TrueCrypt.

The project has been abruptly killed by the developers without any
clear explanation. There's something fishy and it cannot be trusted
anymore.
Spend your time and energy on forks like CipherShed or VeraCrypt!

> STOP posting on top, but DON'T stop reading on top, read that
> page COMPLETELY and notice the download(s) offered at its end!

AFAIK, TrueCrypt 7.2 is only capable of decryption. It is provided so
that users can migrate their data to another system.

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