Nytro

Your IoT security concerns are stupid Lots of government people are focused on IoT security, such as this recent effort. They are usually wrong. It's a typical cybersecurity policy effort which knows the answer without paying attention to the question. Government efforts focus on vulns and patching, ignoring more important issues. Patching has little to do with IoT security. For one thing, consumers will not patch vulns, because unlike your phone/laptop computer which is all "in your face", IoT devices, once installed, are quickly forgotten. For another thing, the average lifespan of a device on your network is at least twice the duration of support from the vendor making patches available. Naive solutions to the manual patching problem, like forcing autoupdates from vendors, increase rather than decrease the danger. Manual patches that don't get applied cause a small, but manageable constant hacking problem. Automatic patching causes rarer, but more catastrophic events when hackers hack the vendor and push out a bad patch. People are afraid of Mirai, a comparatively minor event that led to a quick cleansing of vulnerable devices from the Internet. They should be more afraid of notPetya, the most catastrophic event yet on the Internet that was launched by subverting an automated patch of accounting software. Vulns aren't even the problem. Mirai didn't happen because of accidental bugs, but because of conscious design decisions. Security cameras have unique requirements of being exposed to the Internet and needing a remote factory reset, leading to the worm. While notPetya did exploit a Microsoft vuln, it's primary vector of spreading (after the subverted update) was via misconfigured Windows networking, not that vuln. In other words, while Mirai and notPetya are the most important events people cite supporting their vuln/patching policy, neither was really about vuln/patching. Such technical analysis of events like Mirai and notPetya are ignored. Policymakers are only cherrypicking the superficial conclusions supporting their goals. They assiduously ignore in-depth analysis of such things because it inevitably fails to support their positions, or directly contradicts them. IoT security is going to be solved regardless of what government does. All this policy talk is premised on things being static unless government takes action. This is wrong. Government is still waffling on its response to Mirai, but the market quickly adapted. Those off-brand, poorly engineered security cameras you buy for $19 from Amazon.com shipped directly from Shenzen now look very different, having less Internet exposure, than the ones used in Mirai. Major Internet sites like Twitter now use multiple DNS providers so that a DDoS attack on one won't take down their services. In addition, technology is fundamentally changing. Mirai attacked IPv4 addresses outside the firewall. The 100-billion IoT devices going on the network in the next decade will not work this way, cannot work this way, because there are only 4-billion IPv4 addresses. Instead, they'll be behind NATs or accessed via IPv6, both of which prevent Mirai-style worms from functioning. Your fridge and toaster won't connect via your home WiFi anyway, but via a 5G chip unrelated to your home. Lastly, focusing on the vendor is a tired government cliche. Chronic internet security problems that go unsolved year after year, decade after decade, come from users failing, not vendors. Vendors quickly adapt, users don't. The most important solutions to today's IoT insecurities are to firewall and microsegment networks, something wholly within control of users, even home users. Yet government policy makers won't consider the most important solutions, because their goal is less cybersecurity itself and more how cybersecurity can further their political interests. The best government policy for IoT policy is to do nothing, or at least focus on more relevant solutions than patching vulns. The ideas propose above will add costs to devices while making insignificant benefits to security. Yes, we will have IoT security issues in the future, but they will be new and interesting ones, requiring different solutions than the ones proposed. Sursa: https://blog.erratasec.com/2018/07/your-iot-security-concerns-are-stupid.html#.W0ju6LhRWUk

Customized PSExec via Reflective DLL July 13, 2018 ~ cplsec Hey all, I’m back in the pocket after doing the deep dive into hack the box. I really enjoyed the bulk of the challenges and learned some new great tricks and techniques. One box I highly recommend is Reel. It’s a great challenge with domain privilege escalation techniques that you might see in a pentest. Anyways, after reaching Guru status I decided to take a step back for a while, it’s a part-time job working all the newly released boxes. Before I went dark I was testing Cobalt Strike’s built-in PSExec module against various Endpoint Protection Platform (EPP) products and was getting flagged. It was pretty clear that the EPPs weren’t detecting the binary but was instead flagging via heuristic analysis. It might have been the randomized filename of the binary, the timing, writing to the $ADMIN share, or some sort of combination. I wrote some skeleton code that can be further customized to help bypass heuristic analysis. The current flow of the reflective DLL and Aggressor script can be seen below. You can find the code at https://github.com/ThunderGunExpress/Reflective_PSExec The code and script is pretty crude and has the following limitations at the moment: Use an IP address as the target, not a hostname If running against a remote target ensure the session is in a medium integrity context If running against a local target ensure the session is a high integrity context Sursa: https://ijustwannared.team/2018/07/13/customized-psexec-via-reflective-dll/

Compatible with iOS 11.2 – 11.3.1 For all iPhones, iPods touch, iPads and Apple TVs Download (Dev Account) Uses multipath tcp exploit. Codesigning entitlements: Here SHA1: 4c6e34a40621de2cd59cb3ebdf650307f7ccda93 Mirror: Mega Download (Non Dev Account) Uses vfs exploit. SHA1: 8fa140a5a63377a44ff8ea4aa054605d261f270d Mirror: Mega Download (tvOS) Thanks to nitoTV and Jaywalker for the tvOS port! SHA1: cff12acb81396778d4da3d0f574599d355862863 Mirror: Mega Important: Make sure to delete 11.4 OTA update, install tvOS profile (only install tvOS profile on iOS) and reboot before using Electra! Sursa: https://coolstar.org/electra/

OWASP Juice Shop The most trustworthy online shop out there. (@dschadow) — The best juice shop on the whole internet! (@shehackspurple) — Actually the most bug-free vulnerable application in existence! (@vanderaj) OWASP Juice Shop is an intentionally insecure web application written entirely in JavaScript which encompasses the entire range of OWASP Top Ten and other severe security flaws. For a detailed introduction, full list of features and architecture overview please visit the official project page: http://owasp-juice.shop Setup Deploy on Heroku (free ($0/month) dyno) Sign up to Heroku and log in to your account Click the button below and follow the instructions This is the quickest way to get a running instance of Juice Shop! If you have forked this repository, the deploy button will automatically pick up your fork for deployment! As long as you do not perform any DDoS attacks you are free to use any tools or scripts to hack your Juice Shop instance on Heroku! From Sources Install node.js Run git clone https://github.com/bkimminich/juice-shop.git (or clone your own fork of the repository) Go into the cloned folder with cd juice-shop Run npm install (only has to be done before first start or when you change the source code) Run npm start Browse to http://localhost:3000 Packaged Distributions Install a 64bit node.js on your Windows (or Linux) machine Download juice-shop-<version>_<node-version>_<os>_x64.zip (or .tgz) attached to latest release Unpack and cd into the unpacked folder Run npm start Browse to http://localhost:3000 Each packaged distribution includes some binaries for SQLite bound to the OS and node.js version which npm install was executed on. Docker Container Install Docker Run docker pull bkimminich/juice-shop Run docker run --rm -p 3000:3000 bkimminich/juice-shop Browse to http://localhost:3000 (on macOS and Windows browse to http://192.168.99.100:3000 if you are using docker-machine instead of the native docker installation) If you want to run Juice Shop on a Raspberry Pi 3, there is an unofficial Docker image available at https://hub.docker.com/r/arclight/juice-shop_arm which is based on resin/rpi-raspbian and maintained by @battletux. Even easier: Run Docker Container from Docker Toolbox (Kitematic) Install and launch Docker Toolbox Search for juice-shop and click Create to download image and run container Click on the Open icon next to Web Preview to browse to OWASP Juice Shop Deploy to Docker Cloud (?) Click the button below and follow the instructions This (?) is an experimental deployment option! Your feedback is appreciated at https://gitter.im/bkimminich/juice-shop. Vagrant Install Vagrant and Virtualbox Run git clone https://github.com/bkimminich/juice-shop.git (or clone your own fork of the repository) Run cd vagrant && vagrant up Browse to 192.168.33.10 Amazon EC2 Instance Setup an Amazon Linux AMI instance In Step 3: Configure Instance Details unfold Advanced Details and copy the script below into User Data In Step 6: Configure Security Group add a Rule that opens port 80 for HTTP Launch instance Browse to your instance's public DNS #!/bin/bash yum update -y yum install -y docker service docker start docker pull bkimminich/juice-shop docker run -d -p 80:3000 bkimminich/juice-shop Technically Amazon could view hacking activity on any EC2 instance as an attack on their AWS infrastructure! We highly discourage aggressive scanning or automated brute force attacks! You have been warned! Azure Web App for Containers Open your Azure CLI or login to the Azure Portal, open the CloudShell and then choose Bash (not PowerShell). Create a resource group by running az group create --name <group name> --location <location name, e.g. "East US"> Create an app service plan by running az appservice plan create --name <plan name> --resource-group <group name> --sku S1 --is-linux Create a web app with the Juice Shop Docker image by running the following (on one line in the bash shell) az webapp create --resource-group <group name> --plan <plan name> --name <app name> --deployment-container-image-name bkimminich/juice-shop For more information please refer to the detailed walkthrough with screenshots by @JasonHaley. You can alternatively follow his guide to set up OWASP Juice Shop as an Azure Container Instance. Node.js version compatibility OWASP Juice Shop officially supports the following versions of node.js in line as close as possible with the official node.js LTS schedule. Docker images and packaged distributions are offered accordingly: node.js Docker image Packaged distributions 9.x latest (current official release), snapshot (preview from develop branch) juice-shop-<version>_node9_windows_x64.zip, juice-shop-<version>_node9_linux_x64.tgz 8.x juice-shop-<version>_node8_windows_x64.zip, juice-shop-<version>_node8_linux_x64.tgz Demo Feel free to have a look at the latest version of OWASP Juice Shop: http://demo.owasp-juice.shop This is a deployment-test and sneak-peek instance only! You are not supposed to use this instance for your own hacking endeavours! No guaranteed uptime! Guaranteed stern looks if you break it! Customization Via a YAML configuration file in /config, the OWASP Juice Shop can be customized in its content and look & feel. For detailed instructions and examples please refer to our Customization documentation. CTF-Extension If you want to run OWASP Juice Shop as a Capture-The-Flag event, we recommend you set it up along with a CTFd server conveniently using the official juice-shop-ctf-cli tool. For step-by-step instructions and examples please refer to the Hosting a CTF event chapter of our companion guide ebook. XSS Demo To show the possible impact of XSS, you can download this docker-compose-file and run docker-compose up to start the juice-shop and the shake-logger. Assume you received and (of course) clicked this inconspicuous phishing link and login. Apart from the visual/audible effect, the attacker also installed an input logger to grab credentials! This could easily run on a 3rd party server in real life! You can also find a recording of this attack in action on YouTube: ? Additional Documentation Pwning OWASP Juice Shop This is the official companion guide to the OWASP Juice Shop. It will give you a complete overview of the vulnerabilities found in the application including hints how to spot and exploit them. In the appendix you will even find complete step-by-step solutions to every challenge. Pwning OWASP Juice Shop is published with GitBook under CC BY-NC-ND 4.0 and is available for free in PDF, Kindle and ePub format. You can also browse the full content online! Slide Decks Introduction Slide Deck in HTML5 PDF of the Intro Slide Deck on Slideshare Troubleshooting If you need help with the application setup please check the TROUBLESHOOTING.md or post your specific problem or question in the official Gitter Chat. Contributing We are always happy to get new contributors on board! Please check the following table for possible ways to do so: ❓ ? Found a bug? Crashed the app? Broken challenge? Found a vulnerability that is not on the Score Board? Create an issue or post your ideas in the chat Want to help with development? Pull requests are highly welcome! Please refer to the Contribute to development and Codebase 101 chapters of our companion guide ebook Want to help with internationalization? Find out how to join our Crowdin project in the Helping with translations documentation Anything else you would like to contribute? Write an email to owasp_juice_shop_project@lists.owasp.org or bjoern.kimminich@owasp.org References Did you write a blog post, magazine article or do a podcast about or mentioning OWASP Juice Shop? Or maybe you held or joined a conference talk or meetup session, a hacking workshop or public training where this project was mentioned? Add it to our ever-growing list of REFERENCES.md by forking and opening a Pull Request! Merchandise On Spreadshirt.com and Spreadshirt.de you can get some swag (Shirts, Hoodies, Mugs) with the official OWASP Juice Shop logo On StickerYou.com you can get variants of the OWASP Juice Shop logo as single stickers to decorate your laptop with. They can also print magnets, iron-ons, sticker sheets and temporary tattoos. The most honorable way to get some stickers is to contribute to the project by fixing an issue, finding a serious bug or submitting a good idea for a new challenge! We're also happy to supply you with stickers if you organize a meetup or conference talk where you use or talk about or hack the OWASP Juice Shop! Just contact the mailing list or the project leader to discuss your plans! ! Donations PayPal PayPal donations via above button go to the OWASP Foundations and are earmarked for "Juice Shop". This is the preferred and most convenient way to support the project. Credit Card (through RegOnline) OWASP hosts a donation form on RegOnline. Refer to the Credit card donation step-by-step guide for help with filling out the donation form correctly. Crypto Currency Contributors The OWASP Juice Shop core project team are: Björn Kimminich aka bkimminich (Project Leader) Jannik Hollenbach aka J12934 Timo Pagel aka wurstbrot For a list of all contributors to the OWASP Juice Shop please visit our HALL_OF_FAME.md. Licensing This program is free software: you can redistribute it and/or modify it under the terms of the MIT license. OWASP Juice Shop and any contributions are Copyright © by Bjoern Kimminich 2014-2018. Sursa: https://github.com/bkimminich/juice-shop

RFID Thief v2.0 12 Jul 2018 » all, rfid, tutorial Table of Contents Overview Proxmark 3 Long Range Readers Wiegotcha Raspberry Pi Setup Wiring Raspberry Pi HID iClass R90 HID Indala ASR620 HID MaxiProx 5375 Controller (Optional) Tutorial iClass R90 Indala ASR620 MaxiProx 5375 Components References Overview This post will outline how to build and use long range RFID readers to clone iClass, Indala & Prox cards used for Access Control. Proxmark 3 If you are unfamiliar with the Proxmark 3, it is a general purpose RFID Cloning tool, equipped with a high and low frequency antenna to snoop, listen, clone and emulate RFID cards. There are currently 4 versions of the Proxmark 3, all use the same firmware and software however some have more/less hardware features. Version Picture RDV1 RDV2 RDV3 RDV4 Long Range Readers There are 3 main types of long range readers HID sell, the R90, ASR-620 and MaxiProx 5375. Each reader supports a different type of card: Reader Card Type Picture HID iClass R90 iClass Legacy (13.56 MHz) HID Indala ASR-620 Indala 26bit (125 kHz) HID MaxiProx 5375 ProxCard II (125 kHz) Wiegotcha Wiegotcha is the awesome software for the Raspberry Pi developed by Mike Kelly that improves upon the Tastic RFID Thief in the following areas: Acts as a wireless AP with a simple web page to display captured credentials. Automatically calculates the iClass Block 7 data for cloning. Uses a hardware clock for accurate timestamps. AIO solution, eliminates the need for custom PCB’s and multiple breakout boards. Utilizes an external rechargeable battery. Raspberry Pi Setup This build will make use of the Raspberry Pi 3 to receive the raw Wiegand data from the long range readers and provide an access point to view/save the collected data. MicroSD Card Setup 1. Download and extract Raspbian Stretch. 2. Download ethcher or any disk writer you prefer. 3. Write the Raspbian Strech .img file to the MicroSD card using a USB adapter. 4. Unplug and replug the USB adapter to see ‘boot’ drive. 5. Edit cmdline.txt and add modules-load=dwc2,g_ether after the word rootwait so that so that it looks like this: dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=PARTUUID=9cba179a-02 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait modules-load=dwc2,g_ether quiet init=/usr/lib/raspi-config/init_resize.sh splash plymouth.ignore-serial-consoles 6. Edit config.txt and append dtoverlay=dwc2 to the end of the file. 7. Create a blank file within the ‘boot’ directory called ssh. Raspberry Pi Configuration 1. Connect the RPi to your local network and ssh to it using the default password raspberry. 2. Run sudo su to become the root user. 3. Clone the Wiegotcha repository to the /root directory. cd /root git clone https://github.com/lixmk/Wiegotcha 4. Run the install script in the Wiegotcha directory. cd Wiegotcha ./install.sh 5. Follow the prompts as requested, the RPi will reboot once completed. Be patient, this process can take some time. 6. After reboot, reconnect to the RPi using ssh and enter the following: sudo su screen -dr install 7. RPi will reboot and the installation is completed. The RPi will now broadcast with the ESSID: Wiegotcha, you can connect to it using the passphrase Wiegotcha. Wiegotcha assigns the static IP 192.168.150.1 to the RPi. Wiring Each reader will require a Bi-Directional Logic Level Converter, this is used to convert the 5v Wiegand output from the readers to the 3.3v RPi GPIOs. For quality of life, I have added JST SM connectors allowing quick interchangeability between the different long range readers. You may choose to add another external controller with switches to power the readers on/off, enable/disable sound or vibration, however this is optional. The following is a general overview of how the components are connected together: RPi GPIO Pins 1,3,5,7,9 -> Hardware RTC RPi to Logic Level Converter GPIO Pin 4 -> LLC HV GPIO Pin 6 -> LLC LV GND GPIO Pin 11 -> LLC LV 1 GPIO Pin 12 -> LLC LV 4 GPIO Pin 17 -> LLC LV Long Range Reader to Logic Level Converter LRR DATA 0 (Green) -> LLC HV 1 LRR DATA 1 (White) -> LLC HV 4 LRR SHIELD -> LLC HV GND Raspberry Pi 1. Connect the Hardware RTC to GPIO pins 1,3,5,7,9. 2. Solder female jumper wires to a male JST SM connector according to the table below and connect to the RPi. RPi JST SM Connector GPIO Pin 4 Blue GPIO Pin 6 Black GPIO Pin 11 Green GPIO Pin 12 White GPIO Pin 17 Red HID iClass R90 1. Join wires from the HID R90 to the logic level converter according to the table below. HID R90 Logic Level Converter P1-6 (DATA 0) HV 1 P1-7 (DATA 1) HV 4 P2-2 (GROUND/SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the HID R90 to a DC connector/adapter. HID R90 DC Connector/Adapter P2-1 Positive (+) P1-5 Negative (-) HID Indala ASR620 The Indala ASR620 will have a wiring harness from factory that you can utilize, the shield wire is within the harness itself so you need to slice a portion of the harness to expose. 1. Splice and solder wires from the Indala ASR620 to the logic level converter according to the table below. Indala ASR620 Logic Level Converter Green (DATA 0) HV 1 White (DATA 1) HV 4 Shield HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the Indala ASR620 to a DC connector/adapter. Indala ASR620 DC Connector/Adapter Red Positive (+) Black Negative (-) HID MaxiProx 5375 1. Join wires from MaxiProx 5375 to the logic level converter according to the table below. MaxiProx 5375 Logic Level Converter TB2-1(DATA 0) HV 1 TB2-2 (DATA 1) HV 4 TB1-2 (SHIELD) HV GND 2. Solder female jumper wires from the logic level converter to a female JST SM connector according to the table below. Logic Level Converter JST SM Connector LV Red LV GND Black LV 1 Green LV 4 White HV Blue 3. Join Positive and Negative cables from the MaxiProx 5375 to a DC connector/adapter. MaxiProx 5375 DC Connector/Adapter TB1-1 Positive (+) TB1-3 Negative (-) Controller Hearing a loud beep from your backpack when you intercept a card is probably not good, to avoid this, I made a makeshift controller, to easily power on/off and switch between sound or vibration or both. Each long range reader contains a sound buzzer either soldered or wired to the board, you can de-solder and replace this with extended wires to the controller. Within the makeshift controller you can splice/solder a sound buzzer (reuse the readers), vibrating mini motor disc, switches and a voltage display. Reader Sound buzzer Location HID iClass R90 HID MaxiProx 5375 HID Indala ASR-620 N/A - External Tutorial This section will show you how to clone the intercepted cards from the long range readers using the Proxmark 3. iClass R90 iClass legacy cards are encrypted using a master authentication key and TDES keys. The master authentication key allows you to read and write the encrypted blocks of the card however you will require the TDES keys to encrypt or decrypt each block. You can find the master authentication key in my Proxmark 3 Cheat Sheet post & step 6 of this tutorial. The TDES keys are not publicly available, you will have to source them yourself using the Heart of Darkness paper. The R90 will read the card, decrypt it and send the Wiegand data to Wiegotcha. 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a iClass Legacy card on the long range reader. 4. Copy the data from the Block 7 column into clipboard. 5. Encrypt the Block 7 data using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Encrypt Block 7 data hf iclass encryptblk 0000000b2aa3dd88 6. Write the encrypted Block 7 data to a writable iClass card. hf iclass writeblk b 07 d 26971075da43c659 k AFA785A7DAB33378 7. Done! if it all worked correctly, your cloned card will have the same Block 7 data as the original. You can confirm with the following: hf iclass dump k AFA785A7DAB33378 Indala ASR620 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a Indala card on the long range reader. MaxiProx 5375 1. Assemble/Power on the components and connect to the RPi Access Point Wiegotcha. 2. Navigate to http://192.168.150.1 via browser. 3. Place/Intercept a ProxCard II card on the long range reader. 4. Copy the data from the Proxmark Hex column into clipboard. 5. Clone the Proxmark Hex data to a T5577 card using the Proxmark 3. # Connect to the Proxmark 3 ./proxmark3 /dev/ttyACM0 # Clone Proxmark Hex data lf hid clone 2004060a73 7. Done! if it all worked correctly, your cloned card will have the same Proxmark Hex, FC & SC data as the original. You can confirm with the following: lf search Components Most of the components can be found cheaply on eBay or your local electronics store, the most expensive components are the long range readers and the Proxmark 3. Raspberry Pi 3 Proxmark 3 RDV2 12v USB Power Bank HID iClass R90 HID Indala ASR-620 HID MaxiProx 5375 Bi-Directional Logic Level Converter DS3231 RTC Real Time Clock Vibrating Mini Motor Disc 32GB MicroSD Card JST SM 5 Pin Connectors JST SM 4 Pin Connectors References Official Proxmark 3 Repository Official Proxmark 3 Forums Mike Kelly’s Blog Wiegotcha Github Tastic RFID Thief Share this on → Sursa: https://scund00r.com/all/rfid/tutorial/2018/07/12/rfid-theif-v2.html

PEframe 5.0.1 PEframe is a open source tool to perform static analysis on Portable Executable malware and generic suspicious file. It can help malware researchers to detect packer, xor, digital signature, mutex, anti debug, anti virtual machine, suspicious sections and functions, and much more information about the suspicious files. Documentation will be available soon. Usage $ peframe <filename> Short output analysis $ peframe --json <filename> Full output analysis JSON format $ peframe --strings <filename> Strings output You can edit stringsmatch.json file to configure your fuzzer and virustotal apikey. Output example Short data example | Full data (JSON) example Install Prerequisites Python 2.7.x How to To install from PyPI: # pip install https://github.com/guelfoweb/peframe/archive/master.zip To install from source: $ git clone https://github.com/guelfoweb/peframe.git $ cd peframe # python setup.py install Sursa: https://github.com/guelfoweb/peframe

New Spectre variants earn $100,000 bounty from Intel Researchers discovered two new Spectre variants that can be used to bypass protections and attack systems and earned $100,000 in bug bounties from Intel. Michael Heller Senior Reporter 13 Jul 2018 Researchers found new speculative execution attacks against Intel and ARM chips, and the findings earned them a $100,000 reward under Intel's bug bounty. The new methods are themselves variations on Spectre v1 -- the bounds check bypass version of Spectre attacks -- and are being tracked as Spectre variants 1.1 and 1.2. The new Spectre 1.1 has also earned a new Common Vulnerabilities and Exposures (CVE) number, CVE-2018-3693, because it "leverages speculative stores to create speculative buffer overflows" according to Vladimir Kiriansky, a doctoral candidate in electrical engineering and computer science at MIT, and Carl Waldspurger of Carl Waldspurger Consulting. "Much like classic buffer overflows, speculative out-of-bounds stores can modify data and code pointers. Data-value attacks can bypass some Spectre v1 mitigations, either directly or by redirecting control flow. Control-flow attacks enable arbitrary speculative code execution, which can bypass fence instructions and all other software mitigations for previous speculative-execution attacks. It is easy to construct return-oriented-programming gadgets that can be used to build alternative attack payloads," Kiriansky and Waldspurger wrote in their research paper. "In a speculative data attack, an attacker can (temporarily) overwrite data used by a subsequent Spectre 1.0 gadget." Spectre 1.2 does not have a new CVE because it "relies on lazy enforcement" of read/write protections. "Spectre 1.2 [is] a minor variant of Spectre v1, which depends on lazy PTE enforcement, similar to Spectre v3," the researchers wrote. "In a Spectre 1.2 attack, speculative stores are allowed to overwrite read-only data, code pointers and code metadata, including v-tables [virtual tables], GOT/IAT [global offset table/import address table] and control-flow mitigation metadata. As a result, sandboxing that depends on hardware enforcement of read-only memory is rendered ineffective." As the research paper from Kiriansky and Waldspurger went live, Intel paid them a $100,000 bug bounty for the new Spectre variants. After the initial announcement of the Spectre and Meltdown vulnerabilities in January 2018, Intel expanded its bug bounty program to include rewards of up to $250,000 for similar side-channel attacks. I expect that more variants of Spectre and/or Meltdown will continue to be discovered in the future. Nick BilogorskiyCybersecurity strategist, Juniper Networks “When implemented properly, bug bounties help both businesses and the research community, as well as encourage more security specialists to participate in the audit and allow CISOs to optimize their security budgets for wider security coverage," Bilogorskiy wrote via email. "These bugs are new minor variants of the original Spectre variant one vulnerability and have similar impact. They exploit speculative execution and allow speculative buffer overflows. I expect that more variants of Spectre and/or Meltdown will continue to be discovered in the future." ARM and Intel did not respond to requests for comment at the time of this post. ARM did update its FAQ about speculative processor vulnerabilities to reflect the new Spectre variants. And Intel published a white paper regarding bounds check bypass vulnerabilities at the same time as the disclosure of the new Spectre variants. In it, Intel did not mention plans for a new patch but gave guidance to developers to ensure bounds checks are implemented properly in software as a way to mitigate the new issues. Advanced Micro Devices was not directly mentioned by the researchers in connection with the new Spectre variants, but Spectre v1 did affect AMD chips. AMD has not made a public statement about the new research. Sursa: https://searchsecurity.techtarget.com/news/252444914/New-Spectre-variants-earn-100000-bounty-from-Intel?utm_campaign=ssec_security&amp;utm_medium=social&amp;utm_source=twitter&amp;utm_content=1531504414

DiskShadow: The Return of VSS Evasion, Persistence, and Active Directory Database Extraction March 26, 2018 ~ bohops [Source: blog.microsoft.com] Introduction Not long ago, I blogged about Vshadow: Abusing the Volume Shadow Service for Evasion, Persistence, and Active Directory Database Extraction. This tool was quite interesting because it was yet another utility to perform volume shadow copy operations, and it had a few other features that could potentially support other offensive use cases. In fairness, evasion and persistence are probably not the strong suits of Vshadow.exe, but some of those use cases may have more relevance in its replacement – DiskShadow.exe. In this post, we will discuss DiskShadow, present relevant features and capabilities for offensive opportunities, and highlight IOCs for defensive considerations. *Don’t mind the ridiculous title – it just seemed thematic ? What is DiskShadow? “DiskShadow.exe is a tool that exposes the functionality offered by the Volume Shadow Copy Service (VSS). By default, DiskShadow uses an interactive command interpreter similar to that of DiskRaid or DiskPart. DiskShadow also includes a scriptable mode.“ – Microsoft Docs DiskShadow is included in Windows Server 2008, Windows Server 2012, and Windows Server 2016 and is a Windows signed binary. The VSS features of DiskShadow require privileged-level access (with UAC elevation), however, several command utilities can be invoked by a non-privileged user. This makes DiskShadow a very interesting candidate for command execution and evasive persistence. DiskShadow Command Execution As a feature, the interactive command interpreter and script mode support the EXEC command. As a privileged or an unprivileged user, commands and batch scripts can be invoked within Interactive Mode or via a script file. Let’s demonstrate each of these capabilities: Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. Interactive Mode In the following example, a normal user invokes calc.exe: Script Mode In the following example, a normal user invokes calc.exe and notepad.exe by calling the script option with diskshadow.txt: diskshadow.exe /s c:\test\diskshadow.txt Like Vshadow, take note that the DiskShadow.exe is the parent process of the spawned executable. Additionally, DiskShadow will continue to run until its child processes are finished executing. Auto-Start Persistence & Evasion Since DiskShadow is a Windows signed binary, let’s take a look at a few AutoRuns implications for persistence and evasion. In the proceeding examples, we will update our script then create a RunKey and Scheduled Task. Preparation Since DiskShadow is “window forward” (e.g. pops a command window), we will need to modify our script in a way to invoke proof-of-concept pass-thru execution and close the parent DiskShadow and subsequent payloads as quickly as possible. In some cases, this technique may not be considered very stealthy if the window is opened for a lengthy period of time (which is good for defenders if this activity is noted and reported by users). However, this may be overlooked if users are conditioned to see such prompts at logon time. Note: The proceeding example is carried out under the context of a non-privileged/non-admin user account on a recently installed/updated Windows Server 2016 instance. Depending on the OS version and/or configuration, running this utility at a medium process integrity may fail. First, let’s modify our script (diskshadow.txt) to demonstrate this basic technique: EXEC "cmd.exe" /c c:\test\evil.exe *In order to support command switches, we must quote the initial binary with EXEC. This also works under Interactive Mode. Second, let’s add persistence with the following commands: - Run Key Value - reg add HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run /v VSSRun /t REG_EXPAND_SZ /d "diskshadow.exe /s c:\test\diskshadow.txt" - User Level Scheduled Task - schtasks /create /sc hourly /tn VSSTask /tr "diskshadow.exe /s c:\test\diskshadow.txt" Let’s take a further look at these… AutoRuns – Run Key Value After creating the key value, we can see that our key is hidden when we open up AutoRuns and select the Logon tab. By default, Windows signed executables are hidden from view (with a few notable exceptions) as demonstrated in this screenshot: After de-selecting “Hide Windows Entries”, we can see the AutoRuns entry: AutoRuns – Scheduled Tasks Like the Run Key method, we can see that our entry is hidden in the default AutoRuns view: After de-selecting “Hide Windows Entries”, we can see AutoRuns entry: Extracting the Active Directory Database Since we are discussing the usage of a shadow copy tool, let’s move forward to showcase (yet another) VSS method for extracting the Active Directory (AD) database – ntds.dit. In the following walk-through, we will assume successful compromise of an Active Directory Domain Controller (Win2k12) and are running DiskShadow under a privileged context in Script Mode. First, let’s prepare our script. We have performed some initial recon to determine our target drive letter (for the logical drive that ‘contains’ the AD database) to shadow as well as discovered a logical drive letter that is not in use on the system. Here is the DiskShadow script (diskshadow.txt): set context persistent nowriters add volume c: alias someAlias create expose %someAlias% z: exec "cmd.exe" /c copy z:\windows\ntds\ntds.dit c:\exfil\ntds.dit delete shadows volume %someAlias% reset [Helpful Source: DataCore] In this script, we create a persistent shadow copy so that we can perform copy operations to capture the sensitive target file. By mounting a (unique) logical drive, we can guarantee a copy path for our target file, which we will extract to the ‘exfil’ directory before deleting our shadow copy identified by someAlias. *Note: We can attempt to copy out the target file by specifying a shadow device name /unique identifier. This is slightly stealthier, but it is important to ensure that labels/UUIDs are correct (via initial recon) or else the script will fail to run. This use case may be more suitable for Interactive Mode. The commands and results of the DiskShadow operation are presented in this screenshot: type c:\diskshadow.txt diskshadow.exe /s c:\diskshadow.txt dir c:\exfil In addition to the AD database, we will also need to extract the SYSTEM registry hive: reg.exe save hklm\system c:\exfil\system.bak After transferring these files from the target machine, we use SecretsDump.py to extract the NTLM Hashes: secretsdump.py -ntds ntds.dit -system system.bak LOCAL Success! We have used another method to extract the AD database and hashes. Now, let’s compare and contrast DiskShadow and Vshadow… DiskShadow vs. Vshadow DiskShadow.exe and VShadow.exe have very similar capabilities. However, there are a few differences between these applications that may justify which one is the better choice for the intended operational use case. Let’s explore some of these in greater detail: Operating System Inclusion DiskShadow.exe is included with the Windows Server operating system since 2008. Vshadow.exe is included with the Windows SDK. Unless the target machine has the Windows SDK installed, Vshadow.exe must be uploaded to the target machine. In a “living off the land” scenario, DiskShadow.exe has the clear advantage. Utility & Usage Under the context of a normal user in our test case, we can use several DiskShadow features without privilege (UAC) implications. In my previous testing, Vshadow had privilege constraints (e.g. external command execution could only be invoked after running a VSS operation). Additionally, DiskShadow is flexible with command switch support as previously described. DiskShadow.exe has the advantage here. Command Line Orientation Vshadow is “command line friendly” while DiskShadow requires use by interactive prompt or script file. Unless you have (remote) “TTY” access to a target machine, DiskShadow’s interactive prompt may not be suitable (e.g. for some backdoor shells). Additionally, there is an increased risk for detection when creating files or uploading files to a target machine. In the strict confines of this scenario, Vshadow has the advantage (although, creating a text file will likely have less impact than uploading a binary – refer to the previous section). AutoRuns Persistence & Evasion In the previous Vshadow blog post, you may recall that Vshadow is signed with the Microsoft signing certificate. This has AutoRuns implications such that it will appear within the Default View since Microsoft signed binaries are not hidden. Since DiskShadow is signed with the Windows certificate, it is hidden from the default view. In this scenario, DiskShadow has the advantage. Active Directory Database Extraction If script mode is the only option for DiskShadow usage, extracting the AD database may require additional operations if assumed defaults are not valid (e.g. Shadow Volume disk name is not what we expected). Aside from crafting and running the script, a logical drive may have to be mapped on the target machine to copy out ntds.dit. This does add an additional level of noise to the shadow copy operation. Vshadow has the advantage here. Conclusion All things considered, DiskShadow seems to be more compelling for operational use. However, that does not discount Vshadow (and other VSS methods for that matter) as a prospective tool used by threat agents. Vshadow has been used maliciously in the past for other reasons. For DiskShadow, Blue Teams and Network Defenders should consider the following: Monitor the Volume Shadow Service (VSS) for random shadow creations/deletions and any activity that involves the AD database file (ntds.dit). Monitor for suspicious instances of System Event ID 7036 (“The Volume Shadow Copy service entered the running state”) and invocation of the VSSVC.exe process. Monitor process creation events for diskshadow.exe and spawned child processes. Monitor for process integrity. If diskshadow.exe runs at a medium integrity, that is likely a red flag. Monitor for instances of diskshadow.exe on client endpoints. Unless there is a business need, diskshadow.exe *should* not be present on client Windows operating systems. Monitor for new and interesting logical drive mappings. Inspect suspicious “AutoRuns” entries. Scrutinize signed binaries and inspect script files. Enforce Application Whitelisting. Strict policies may prevent DiskShadow pass-thru applications from executing. Fight the good fight, and train your users. If they see something (e.g. a weird pop up window), they should say something! As always, if you have questions or comments, feel free to reach out to me here or on Twitter. Thank you for taking the time to read about DiskShadow! Sursa: https://bohops.com/2018/03/26/diskshadow-the-return-of-vss-evasion-persistence-and-active-directory-database-extraction/

deen An application that allows to apply encoding, compression and hashing to generic input data. It is meant to be a handy tool for quick encoding/decoding tasks for data to be used in other applications. It aims to be a lightweight alternative to other tools that might take a long time to startup and should not have too many dependencies. It includes a GUI for easy interaction and integration in common workflows as well as a CLI that might be usefule for automation tasks. Usage See the wiki for basic and more advanced usage examples. Installation Install via pip: pip3 install -r requirements.txt pip3 install . After installation, just run: deen Note: If the installation fails with an error like "Could not find a version that satisfies the requirement PyQt5", then you are trying to install deen via pip on a version of Python < 3.5. In this case, you cannot install PyQt5 via pip. You have to install PyQt5 separately, e.g. via your package manager (e.g. pacman -S python2-pyqt5 on Arch Linux for Python 2). Packages There is a deen-git package available in the Arch User Repository (AUR). Compatibility The code should be compatible with Python 2 (at least 2.7.x) and Python 3. However, deen is mainly developed for Python 3 and some features may be temporarily broken in Python 2. It is strongly recommended to use deen with Python 3. The GUI should run on most operating systems supported by Python. It was tested on Linux and Windows. Hopefully compatibility for different Python versions and operating systems will improve in the future. Feel free to test it and create issues! Some transformers will only be available in more recent versions of Python. This includes e.g. Base85 (Python 3.4 or newer) or the BLAKE2b and BLAKE2s hash algorithms (Python 3.6 or newer). Sursa: https://github.com/takeshixx/deen

<Registration Deadline> < !-- JUL 28 10：00 AM, 2018 -- > <Qualification> Online Jeopardy (All challenges are built on top of real world applications) JUL 28 10:00 AM ~ JUL 30 10:00 AM, 2018(GMT+8, 48 hours) <Final> Onsite Jeopardy (All challenges are built on top of real world applications) SEP 15 ~ SEP 18, 2018 (GMT+8, 48 hours) Venue: TBC, China Top 20 international teams (5 players per team) from the qualification round will be invited to participate in the on-site CTF Finals. We will see the world's best teams competing for the 2018 REAL WORLD CTF Championship. Link: https://realworldctf.com/

Misto, de unde le scoti?

"Challenge accepted"

NetRipper - Added support for cross-compilation on Linux - https://github.com/NytroRST/NetRipper

NetRipper - Added support for Chrome 67 (32 and 64 bits) https://github.com/NytroRST/NetRipper

Added support for PCAP files: https://github.com/NytroRST/NetRipper

Din cate am inteles, nu e tocmai ceva nou, dar a fost "redescoperit". Se pare ca astfel de probleme exista de prin '90.

La Linkedin s-a schimbat ceva dupa ce a fost cumparat? Mai exact, de exemplu pe mine, utilizator de rand cu repo-uri publice, ma va afecta cu ceva aceasta schimbare? Pareri?

Se pare ca s-au deschis inregistrarile pentru Defcamp 2018: https://def.camp/tickets/ De asemenea, va puteti inscrie la Call for Papers, daca doriti sa prezentati. https://def.camp/call-for-papers/ Daca sunt intrebari, va poate ajuta @Andrei

Cui ii pasa de el... Ia zi-ne, tonomatul de cafea e bine?

Understanding Java deserialization Some time ago I detailed PHP Object Injection vulnerabilities and this post will get into details of Java deserialization vulnerabilities. The concept is simple: developers use a feature of the programming language, serialization, to simplify their job, but they are not aware about the risks. Java deserialization is a vulnerability similar to deserialization vulnerabilities in other programming languages. This class of vulnerabilities came to life in 2006, it become more common and more exploited and it is now part of the OWASP Top 10 2017. Sursa: https://nytrosecurity.com/2018/05/30/understanding-java-deserialization/

Buhuuuuu, aici... pe RSTTTT, sunteti controlati de catre noooooi. O sa faceti tot ce spunem nooooi! Buhuhu.

E am un Asus RoG de cativa ani si inca e super OK. - i7 (seria de atunci) - 256 SSD - Trebuie sa iei ceva neaparat cu SSD - 756 HDD (7200rpm) - GTX 770M - Nu e tocmai cine stie ce, dar nici nu am nevoie Ia mai bine nou. La 4000-5000 RON gasesti multe bune.

Websocket Fuzzer A simple websocket fuzzer for application penetration testing. Two tools are provided: websocket-fuzzer.py: Receives a websocket message, modifies it, and then sends it in different connections. The response is analyzed to find potential vulnerabilities. send-one-message.py: Sends a websocket message using a new connection Both tools require considerable customization to be used. Please read the source code comments in both files to better understand all the parameters. Installation and usage pip install -r requirements.txt # edit send-one-message.py python send-one-message.py In most cases you'll want to use a proxy, such as OWASP ZAP or Burp Suite, to analyze the websocket traffic generated by these tools. Both tools support proxying the websocket traffic. The workflow for these tools is fairly simple: Use send-one-message.py to define most of the variables, make sure that authentication is working, etc. Confirm all this with the logs and traffic seen in the local proxy. Move the send-one-message.py configuration to websocket-fuzzer.py and customize the remaining parameters. Start the process and confirm that the fuzzer is sending what you expect. Customize the payloads which are sent to the target using payloads/payloads.txt Analyze the logs using grep to find specific things you're looking for. The tool will try to identify issues for you and log them with Potential issue found in connection with ID Authentication The tools support authenticating using user-defined websocket messages. These messages are sent before the ones with the payloads. Logging All messages are logged to a user-defined directory. Each connection is logged to a different file. Detailed logging is very important for this tool, since it allows the user to run grep on the output to find interesting things. Fuzzing The tool was developed for fuzzing websocket applications which use JSON as a serialization method. If this is not the case for you, please customize the following functions: * `create_tokenized_messages` * `replace_token_in_json` Sursa: https://github.com/andresriancho/websocket-fuzzer

1. Introduction ................................................................................................................................. 1 2. Research Description .................................................................................................................. 2 2.1 Infotainment System ......................................................................................................... 3 2.1.1 USB Interface......................................................................................................... 5 2.1.2 E-NET over OBD-II .............................................................................................. 6 2.1.3 Bluetooth Stack ...................................................................................................... 7 2.1.4 ConnectedDrive Service ........................................................................................ 8 2.1.5 K-CAN Bus ............................................................................................................ 9 2.2 Telematics Control Unit .................................................................................................... 9 2.2.1 Remote Service with NGTP................................................................................. 12 2.2.2 Remote Diagnosis ................................................................................................ 12 2.3 Central Gateway Module ................................................................................................ 12 2.3.1 Cross-Domain Diagnostic Messages ................................................................... 14 2.3.2 Lack of High Speed Limit on UDS...................................................................... 14 3. Vulnerability Findings .............................................................................................................. 15 4. Attack Chains ............................................................................................................................ 16 4.1 Contacted Attack ............................................................................................................. 17 4.2 Contactless Attack .......................................................................................................... 17 4.2.1 Bluetooth Channel ............................................................................................... 17 4.2.2 Cellular Network .................................................................................................. 18 5. Vulnerable BMW Models ......................................................................................................... 19 6. Disclosure Process .................................................................................................................... 21 7. Conclusion ................................................................................................................................ 22 Download: https://keenlab.tencent.com/en/Experimental_Security_Assessment_of_BMW_Cars_by_KeenLab.pdf

Analysis and mitigation of speculative store bypass (CVE-2018-3639) swiat May 21, 2018 In January, 2018, Microsoft published an advisory and security updates for a new class of hardware vulnerabilities involving speculative execution side channels (known as Spectre and Meltdown). In this blog post, we will provide a technical analysis of an additional subclass of speculative execution side channel vulnerability known as Speculative Store Bypass (SSB) which has been assigned CVE-2018-3639. SSB was independently discovered by Ken Johnson of the Microsoft Security Response Center (MSRC) and Jann Horn (@tehjh) of Google Project Zero (GPZ). This post is primarily geared toward security researchers and engineers who are interested in a technical analysis of SSB and the mitigations that are relevant to it. If you are interested in more general guidance, please refer to our advisory for Speculative Store Bypass and our knowledge base articles for Windows Server, Windows Client, and Microsoft cloud services. Please note that the information in this post is current as of the date of this post. TL;DR Before diving into the technical details, below is a brief summary of the CPUs that are affected by SSB, Microsoft’s assessment of the risk, and the mitigations identified to date. What is affected? AMD, ARM, and Intel CPUs are affected by CVE-2018-3639 to varying degrees. What is the risk? Microsoft currently assesses the risk posed by CVE-2018-3639 to our customers as low. We are not aware of any exploitable instances of this vulnerability class in our software at this time, but we are continuing to investigate and we encourage researchers to find and report any exploitable instances of CVE-2018-3639 as part of our Speculative Execution Side Channel Bounty program. We will adapt our mitigation strategy for CVE-2018-3639 as our understanding of the risk evolves. What is the mitigation? Microsoft has already released mitigations as part of our response to Spectre and Meltdown that are applicable to CVE-2018-3639 in certain scenarios, such as reducing timer precision in Microsoft Edge and Internet Explorer. Software developers can address individual instances of CVE-2018-3639 if they are discovered by introducing a speculation barrier instruction as described in Microsoft’s C++ developer guidance for speculative execution side channels. Microsoft is working with CPU manufacturers to assess the availability and readiness of new hardware features that can be used to resolve CVE-2018-3639. In some cases, these features will require a microcode or firmware update to be installed. Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows update. Speculative Store Bypass (SSB) overview In our blog post on mitigating speculative execution side channel hardware vulnerabilities, we described three speculation primitives that can be used to create the conditions for a speculative execution side channel. These three primitives provide the fundamental methods for entering speculative execution along a non-architectural path and consist of conditional branch misprediction, indirect branch misprediction, and exception delivery or deferral. Speculative Store Bypass (SSB) belongs to a new category of speculation primitive that we refer to as memory access misprediction. SSB arises due to a CPU optimization that can allow a potentially dependent load instruction to be speculatively executed ahead of an older store. Specifically, if a load is predicted as not being dependent on a prior store, then the load can be speculatively executed before the store. If the prediction is incorrect, this can result in the load reading stale data and possibly forwarding that data onto other dependent micro-operations during speculation. This can potentially give rise to a speculative execution side channel and the disclosure of sensitive information. To illustrate how this might occur, it may help to consider the following simple example. In this example, RDI and RSI are assumed to be equal to the same address on the architectural path. 01: 88040F mov [rdi+rcx],al 02: 4C0FB6040E movzx r8,byte [rsi+rcx] 03: 49C1E00C shl r8,byte 0xc 04: 428B0402 mov eax,[rdx+r8] In this example, the MOV instruction on line 1 may take additional time to execute (e.g. if the computation of the address expression for RDI+RCX is waiting on prior instructions to execute). If this occurs, the CPU may predict that the MOVZX is not dependent on the MOV and may speculatively execute it ahead of the MOV that performs the store. This can result in stale data from the memory located at RSI+RCX being loaded into R8 and fed to a dependent load on line 4. If the byte value in R8 is sensitive, then it may be observed through a side channel by leveraging a cache-based disclosure primitive such as FLUSH+RELOAD (if RDX refers to shared memory) or PRIME+PROBE. The CPU will eventually detect the misprediction and discard that state that was computed, but the data that was accessed during speculation may have created residual side effects in the cache by this point that can then be measured to infer the value that was loaded into R8. This example is simplified for the purposes of explaining the issue, but it is possible to imagine generalizations of this concept that could occur. For example, it may be possible for similar sequences to exist where SSB could give rise to a speculative out-of-bounds read, type confusion, indirect branch, and so on. We have revised our C++ Developer Guidance for Speculative Execution Side Channels to include additional examples of code patterns and conditions that could give rise to an instance of CVE-2018-3639. In practice, finding an exploitable instance of CVE-2018-3639 will require an attacker to identify an instruction sequence where: The sequence is reachable across a trust boundary, e.g. an attacker in user mode can trigger the sequence in kernel mode through a system call. The sequence contains a load instruction that is architecturally dependent on a prior store. The stale data that is read by the load instruction is sensitive and is used in a way that can create a side channel on the non-architectural path, e.g. the data feeds a disclosure gadget. The store instruction does not execute before the load and the dependent instructions that compose the disclosure gadget are speculatively executed. While our research into this new vulnerability class is ongoing, we have not identified instruction sequences that satisfy all of the above criteria and we are currently not aware of any exploitable instances of CVE-2018-3639 in our software. In the case of Just-in-Time (JIT) compilers, such as JavaScript JIT employed by modern web browsers, it may be possible for an attacker to supply JavaScript that produces native code that satisfies the criteria above. However, Microsoft Edge, Internet Explorer, and other major browsers have taken steps to reduce the precision of timers to increase the difficulty of successfully creating a side channel. Mitigations for Speculative Store Bypass (SSB) There are multiple mitigations that are applicable to SSB. In our previous blog post on mitigating speculative execution side channels, we characterized the software security models that can generally be at risk and the various tactics for mitigating speculative execution side channels. We will reuse the previously established terminology from that post to frame the mitigation options available for SSB. Relevance to software security models The following table summarizes the potential relevance of SSB to the various intra-device attack scenarios that software security models are typically concerned with. As with CVE-2017-5753 (Spectre variant 1), SSB is theoretically applicable to each attack scenario as indicated by the orange cells (grey cells indicate not applicable). Attack Category Attack Scenario Conditional branch misprediction Indirect branch misprediction Exception delivery or deferral CVE-2018-3639 (SSB) Inter-VM Hypervisor-to-guest Host-to-guest Guest-to-guest Intra-OS Kernel-to-user Process-to-process Intra-process Enclave Enclave-to-any Preventing speculation techniques involving SSB As we’ve noted in the past, one of the best ways to mitigate a vulnerability is by addressing the issue as close to the root cause as possible. In the case of SSB, there are a few techniques that can be used to prevent speculation techniques that rely on SSB as the speculation primitive. Speculation barrier via serializing instruction As with CVE-2017-5753 (Spectre variant 1), it is possible to mitigate SSB by using an instruction which is architecturally defined to serialize execution, thus acting as a speculation barrier. In the case of SSB, a serializing instruction (such as an LFENCE on x86/x64 and SSBB on ARM) can be inserted between the store instruction and the load that could be speculatively executed ahead of the store. For example, inserting an LFENCE on line 2 mitigates the simplified example from this post. Additional information can be found in the C++ Developer Guidance for Speculative Execution Side Channels. 01: 88040F mov [rdi+rcx],al 02: 0FAEE8 lfence 03: 4C0FB6040E movzx r8,byte [rsi+rcx] 04: 49C1E00C shl r8,byte 0xc 05: 428B0402 mov eax,[rdx+r8] Speculative store bypass disable (SSBD) In some cases, CPUs can provide facilities for inhibiting a speculative store bypass from occurring and can therefore offer a categorical mitigation for SSB. AMD, ARM, and Intel have documented new hardware features that can be used by software to accomplish this. Microsoft is working with AMD, ARM, and Intel to assess the availability and readiness of these features. In some cases, these features will require a microcode or firmware update to be installed. Microsoft plans to provide a mitigation that leverages the new hardware features in a future Windows update. Generally applicable mitigations for SSB There are a number of previously described mitigations that are also generally applicable to SSB. These include mitigations that involve removing sensitive content from memory or removing observation channels. Generally speaking, the mitigation techniques for these two tactics that are effective against CVE-2017-5753 (Spectre variant 1) are also applicable to SSB. Applicability of mitigations The complex nature of these issues makes it difficult to understand the relationship between mitigations, speculation techniques, and the attack scenarios to which they apply. This section provides tables to help describe these relationships. Some of the mitigation techniques mentioned in the tables below are described in our previous blog post on this subject. The legend for the tables that follow is: Applicable Not applicable Mitigation relationship to attack scenarios The following table summarizes the relationship between attack scenarios and applicable mitigations. Mitigation Tactic Mitigation Name Inter-VM Intra-OS Enclave Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Speculative Store Bypass Disable (SSBD) Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision Mitigation relationship to variants The following table summarizes the relationship among SSB and the Spectre and Meltdown variants, and applicable mitigations. Mitigation Tactic Mitigation Name CVE-2017-5753 (variant 1) CVE-2017-5715 (variant 2) CVE-2017-5754 (variant 3) CVE-2018-3639 (SSB) Prevent speculation techniques Speculation barrier via execution serializing instruction Security domain CPU core isolation Indirect branch speculation barrier on demand and mode change Non-speculated or safely-speculated indirect branches Speculative Store Bypass Disable (SSBD) Remove sensitive content from memory Hypervisor address space segregation Split user and kernel page tables (“KVA Shadow”) Remove observation channels Map guest memory as noncacheable in root extended page tables Do not share physical pages across guests Decrease browser timer precision Wrapping up In this post, we analyzed a new class of speculative execution side channel hardware vulnerabilities known as Speculative Store Bypass (SSB). This analysis provided the basis for evaluating the risk associated with this class of vulnerability and the mitigation options that exist. As we noted in our previous post, research into speculative execution side channels is ongoing and we will continue to evolve our response and mitigations as we learn more. While we currently assess the risk of SSB as low, we encourage researchers to help further our understanding of the true risk and to report any exploitable instances of CVE-2018-3639 that may exist as part of our Speculative Execution Side Channel bounty program. Matt Miller Microsoft Security Response Center (MSRC) Sursa: https://blogs.technet.microsoft.com/srd/2018/05/21/analysis-and-mitigation-of-speculative-store-bypass-cve-2018-3639/