Nytro

ENGINEERING BLOG Dangers of the Decompiler A Sampling of Anti-Decompilation Techniques November 16, 2017 / Markus Gaasedelen Traditional (assembly level) reverse engineering of software is a tedious process that has been made far more accessible by modern day decompilers. Operating only on compiled machine code, a decompiler attempts to recover an approximate source level representation. "... and I resisted the temptation, for years. But, I knew that, if I just pressed that button ..." --Dr. Mann (Interstellar, 2014) There’s no denying it: the science and convenience behind a decompiler-backed disassembler is awesome. At the press of a button, a complete novice can translate obscure ‘machine code’ into human readable source and engage in the reverse engineering process. The reality is that researchers are growing dependent on these technologies too, leaving us quite exposed to their imperfections. In this post we’ll explore a few anti-decompilation techniques to disrupt or purposefully mislead decompiler-dependent reverse engineers. Positive SP Value The first technique is a classic, but ‘noisy’, method of disrupting the Hex-Rays decompiler. In IDA Pro, the decompiler will refuse to decompile a function if it does not clean up its stack allocations (balancing the stack pointer) prior to returning. The error message raised by IDA when a positive stack pointer is detected during decompilation This happens occasionally (innocently) when IDA cannot reasonably devise the type definition of certain function calls. As an anti-decompilation technique, a developer can elicit this behavior in a function they would like to ‘hide’ by using an opaque predicate that disrupts the balance of the stack pointer. // // compiled on Ubuntu 16.04 with: // gcc -o predicate predicate.c -masm=intel // #include <stdio.h> #define positive_sp_predicate \ __asm__ (" push rax \n"\ " xor eax, eax \n"\ " jz opaque \n"\ " add rsp, 4 \n"\ "opaque: \n"\ " pop rax \n"); void protected() { positive_sp_predicate; puts("Can't decompile this function"); } void main() { protected(); } The instruction add rsp, 4 in the positive_sp_predicate macro defined above can never get executed at runtime, but it will trip up the static analysis that IDA performs for decompilation. Attempting to decompile the protected() function generated by the provided source yields the following result: Using opaque predicates to unbalance the stack pointer as a means of anti-decompilation This technique is relatively well known. It can be fixed via patching, or correcting the stack offset by hand. In the past I’ve used this technique as a simple stopgap to thwart novice reverse engineers (eg, students) from skipping the disassembly and going straight to decompiler output. Return Hijacking An aspiration of modern decompilers is to accurately identify and abstract away low-level bookkeeping logic that compilers generate, such as function prologues/epilogues or control flow metadata. Compiler generated function prologues will typically save registers, allocate space for the stack frame, etc Decompilers strive to omit this kind of information from their output because the concepts of saving registers, or managing stack frame allocation do not exist at the source level. An interesting artifact of these omissions (or perhaps a gap in the Hex-Rays decompiler heuristics) is that we can ‘pivot’ the stack just prior to returning from a function without the decompiler throwing a warning or presenting any indication of foul play. Pivoting the stack pointer (RSP) onto a ROP chain embedded into the binary Stack pivoting is a technique commonly used in binary exploitation to achieve arbitrary ROP. In this case, we (as developers) use it as a mechanism to hijack execution right out from underneath an unsuspecting reverse engineer. Those focused solely on decompiler output are guaranteed to miss it. Decompiling main, and a deceptive function ending with a stack pivot We pivot the stack onto a tiny ROP chain that has been compiled into the binary for this exercise of misdirection. The end result is a function call that is ‘invisible’ to the decompiler. Our discretely called function simply prints out ‘Evil Code’ to prove that it was executed. Executing the compiled binary making use of the return hijacking anti-decompilation technique The code used to demonstrate this technique of hiding code from the decompiler can be found below. // // compiled on Ubuntu 16.04 with: // gcc -o return return.c -masm=intel // #include <stdio.h> void evil() { puts("Evil Code"); } extern void gadget(); __asm__ (".global gadget \n" "gadget: \n" " pop rax \n" " mov rsp, rbp \n" " call rax \n" " pop rbp \n" " ret \n"); void * gadgets[] = {gadget, evil}; void deceptive() { puts("Hello World!"); __asm__("mov rsp, %0;\n" "ret" : :"i" (gadgets)); } void main() { deceptive(); } Abusing ‘noreturn’ Functions The last technique we’ll cover exploits IDA’s perception of functions that are automatically labeled as noreturn. Some everyday examples of noreturn functions would be exit(), or abort() from the standard libraries. While generating the pseudocode for a given function, the decompiler will discard any code after a call to a noreturn function. The expectation is that in no universe should a function like exit() ever return and continue executing code. The code directly following a call to a noreturn function is invisible to the decompiler. If one can trick IDA into believing a function is noreturn when it actually isn’t, a malicious actor can quietly hide code behind any calls made to it. The following example demonstrates one of many ways we can achieve this result. // // compiled on Ubuntu 16.04 with: // gcc -o noreturn noreturn.c // #include <stdio.h> #include <stdlib.h> void ignore() { exit(0); // force a PLT/GOT entry for exit() } void deceptive() { puts("Hello World!"); srand(0); // post-processing will swap srand() <--> exit() puts("Evil Code"); } void main() { deceptive(); } By compiling the code above and running a short Binary Ninja based post-processing script against the resulting binary, we can swap the pushed ordinal numbers in the Procedure Linkage Table. These indexes are used to when resolving library imports at runtime. Swapping PLT ordinal numbers in the ELF header In this example we swap the ordinals for srand() with exit() and doctor some calls for compile-time convenience. As a result, IDA believes the deceptive() function in the modified binary is calling exit(), a noreturn function, instead of srand(). Decompiling main, and deceptive function concealing code behind a noreturn call The exit() call we see in IDA is in-fact srand() (effectively a no-op) at runtime. The effect on the decompiler is almost identical to the return hijacking technique covered in the previous section. Running the binary demonstrates that our ‘Evil Code’ is getting executed, unbeknownst to the decompiler. Executing the compiled binary making use of the noreturn anti-decompilation technique While the presence of malicious code is blatant in these examples, hiding these techniques within larger functions and complex conditionals makes them exceptionally easy to glaze over. Conclusion Decompilers are an impressive but imperfect technology. They operate on incomplete information and do their best to approximate for us humans. Malicious actors can (and will) leverage these asymmetries as a means of deception. As the industry grows more reliant on the luxuries of today’s decompilers, the adoption of anti-decompilation techniques will increase and evolve in the same vein as anti-debugging and anti-reversing have. Sursa: https://blog.ret2.io/2017/11/16/dangers-of-the-decompiler/

BlueBorne RCE on Android 6.0.1 (CVE-2017-0781) [English] A few days ago, the company Armis published a proof of concept (PoC) of a remote code execution vulnerability in Android via Bluetooth (CVE-2017-0781), known as BlueBorne. Although BlueBorne refers to a set of 8 vulnerabilities, this PoC uses only 2 of them to achieve its goal. The exploitation process is divided into 2 phases, first the memory leak vulnerability (CVE-2017-0785) is used to know the memory addresses and bypass the ASLR protection, and thus make a call to the function libc library system and execute code on the phone, in this case a reverse shell. The original source code of the Armis PoC is oriented to Android 7.1.2 on Pixel and Nexus 5X phones, and it is implied that to use it in another model it is only necessary to modify in the code the offsets of libc and bluetooth libraries. Later we will see how in the version 6.0.1 analyzed, the changes in the code of the bluetooth library are significant, complicating the exploitation and forcing us to make more modifications in the code of the PoC. To perform some of the following actions it is necessary to have root privileges on the phone. Libraries download The first step is to extract the libraries to analyze them on our computer with IDA or Radare. $ adb pull /system/lib/hw/bluetooth.default.so $ adb pull /system/lib/libc.so libc system function We open libc.so with Radare and look for the system function. As we can see it is in the address 0x3ea04, which we introduce in the variable LIBC_TEXT_STSTEM_OFFSET = 0x3ea04 +1. $ r2 -A libc.so > afl~system 0x0003ea04 10 184 sym.system Articol complet: https://jesux.es/exploiting/blueborne-android-6.0.1-english/

OSCE/CTP Prep Guide July 18, 2017 Tulpa What this prep guide is and isn’t If you have read my OSCP prep guide (https://tulpa-security.com/2016/09/19/prep-guide-for-offsecs-pwk/), then you know that I don’t just dump a ton of redundant resources on you and say good luck. Your time is precious, and your learning should be well calibrated to studying the best quality information available. This prep course is meant to be completed prior to taking the CTP course. If you look at the CTP covers, you’ll find that I don’t delve into some of the course topics and reason for that is twofold. Firstly, this is meant to prepare you for CTP, not to replace the CTP in anyway. Secondly, CTP is an outstanding quality course and some things are covered from the ground up in such a way that you simply don’t need to prepare for it. Although the resources in this course is carefully curated, it won’t do you much good if you simply read the notes and watch the videos. You have to practice! Repetition is the mother of skill, and exploit development is no different. You will also find that I would recommend reading two tutorials regarding the same topic. This isn’t about repetition as much as it’s about getting two perspectives on the same topic. This is a great way of really deepening your understanding of the course material. Disclaimer: I am not affiliated with any of the authors of the resources that I mention here. I recommend them and reference them because I truly believe in their work and its applicability to the OSCE certification. Lesson 0 – Getting your resources together In order to follow along, you need to get your hands on the Security Tube Linux Assembly Expert (32 bit) course. It’s quite affordable when you consider the value that you’re getting. As you know, CTP/OSCE is windows based so the SLAE material isn’t going to help you with all the concepts, however it does a very good job of covering a wide range of topics that you need to know. I honestly haven’t found a better guide and believe me when I say that I tried. I am very pleased to share that the kind people from Security Tube is offering readers of this guide 25% off not only the 32-bit SLAE course, but also the 64-bit version! Thank you Vivek Ramachandran for making your excellent material more accessible to the community. To get the discount, you can follow this link: http://promo.securitytube-training.com/slae64092015 For your lab environment I would recommend that you set up three machines. The first obviously being Kali, the second would be a Windows XP SP3 client, and lastly a Windows 7 client. A lot of people e-mailed me when I wrote my OSCP prep course and asked where they can get ahold of older versions of Windows OS’s. I can’t provide you with a download link, but I’m sure that you will figure it out. In my case, I was lucky enough to have some old MSDN disks laying around. After you set everything up and installed immunity and mona (or olly), then be sure to take a snapshot of your machines before starting. Lesson 1 – Introduction The key to deepening and accelerating your learning in this particular subject is dependent upon what you do in this first lesson. While not glamorous, this is ideally where you need to spend some time to memorize the various registers and what they are used for as well as the various sections of the debugger. If you know what an EDI register is used for off by heart as an example, then you can think creatively and form a much deeper understanding of the rest of the material going forward. Don’t forget to also focus on the various sections of the registers in terms of AH vs AL etc. What I found very useful was using a flashcard app at brainscape.com. This app in particular is great because it uses an algorithm to determine how well you know each card and then adjusts the frequency in which they appear. Go through the below resources in order prior to creating your flash cards. The first resource you need to go through is http://www.securitysift.com/windows-exploit-development-part-1-basics/ This is where you will get the bulk of your information for your flash cards. Also pay particular attention to the layout of immunity debugger. Both Olly and Immunity uses exactly the same layout so rest assured that this information is worth knowing. Also don’t get too intimidated by the PEB and TEB(S) section. If your struggling with that section, then you can come back to it later in the course at it will click. Next up is SLAE videos 1-7. The total length of these videos are just over an hour, but you can expect to spend an extra 30 minutes on it because of how frequently you will have to pause and take notes for your flash cards. In the next lesson you’ll be working through GDB. You don’t have to have your flashcards memorized prior to moving onto the next session so no need to pause your progress. Lesson 2 – GNU Debugger (GDB) In order to make the most of the SLAE videos, you have to do the GDB course that’s included. I know that you want to get to the meat of the course and start pwning machines, but you have to walk before you can run. Tip: These videos are very easy to follow along when you up the playback speed. I found x1.75 to be a comfortable speed for these videos particularly (don’t do the same with the rest of the SLAE course). By doing this you can cut the total video time from 3 hours and 40 minutes down to 2 hours and 52 minutes. Lesson 3 – Basic Assembly In this section you need to watch the 8th and 9th video in the SLAE series which is only 30 minutes. More than just focusing on the assembly, I want you to pay particular attention to how he uses a syscall to print hello world. This is the essence of shellcoding which we will get to later. After that, watch SLAE videos 10-12 which will take you 53 minutes. At this stage it’s a good idea to memorize the op codes for one or two commands that will make reading assembly so much easier down the line. The ones that I recommend to include in your own list. CALL – FF Dx. This could be anything from D0 to D7 based on the register that it’s referencing. Again you’re just trying to recall what a command does when you see it, so you don’t have to memorize the number for each register. JMP – EB. You’re going to be seeing this one alot! INC – 4x. Again this goes from 40 to 47 depending on the register. When you fuzz a program you’re going to be using a lot of A’s, B’s and C’s which translate to 41, 42, 43 respectively. That means that sending A (or 41 in hex) to a program, will be interpreted as a INC ECX command. This is useful to know not just for quickly identifying where your offset lands, but also as a reminder that they can be interpreted as commands. DEC – 4x. This carries on where INC stopped and goes from 48 to 4F depending on the register. Careful of information overload here. Limit your list to seven or eight opcodes at most. Lesson 4 – Stack based overflows The lesson that you have been waiting for. Let’s pop some shells! Go through these two lessons in order first, because the Corelan tutorial does a good job of including a quick refresher of what you have already learned. Remember to DO the work and not just read them over. https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/ http://www.securitysift.com/windows-exploit-development-part-2-intro-stack-overflow/ Vulnserver is an amazing go to practice and for you to test a ton of your exploits. Once you successfully exploit them, keep those scripts on hand because it’s such a quick way to get some of your shellcode into memory and also to test out some commands. You can find the download link for vulnhub here, along with a tutorial on how to exploit it in various ways. Try and do it yourself first and if you get stuck then you can have a look the walkthrough for guidance. http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-1-introduction/ http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-2-exploiting-the-stack-overflow/ http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-3-%E2%80%94-adding-shellcode/ Lesson 5 – Useful information This is a very short lesson to quickly drop you three resources that was very important to me during my OSCE. Firstly, don’t trust windows calculator for hex. We’ll only be doing these manual calculations later in the course but allow me to explain. Open up windows calculator and set it to ‘programmer’ mode. Click on ‘HEX’ in the left hand side and type in 9A and divide that by 3. The answer is 33 right? Wrong. What windows calculator doesn’t tell you is that the real answer is 33 with a remainder of 1. You can verify the answer here: http://www.calculator.net/hex-calculator.html?number1=9A&c2op=%2F&number2=3&calctype=op&x=68&y=7 Next up, is the best wallpaper you will ever see. It’s been a great reference and I think you’ll find it very useful for CTP http://i.imgur.com/Mr9pvq9.jpg Lastly, there’s an online disassembler which I used once or twice when I wasn’t at my Kali machine. https://www.onlinedisassembler.com/static/home/ Lesson 6 – Offsets and JMP’s When your exploit isn’t working as expected then chances are that your offset is wrong. Make sure you keep this information at the forefront of your mind. http://www.securitysift.com/windows-exploit-development-part-3-changing-offsets-and-rebased-modules/ Now it’s time for JMPing around memory. You’ll find in the CTP course that sometimes you need to creatively JMP out of a tight spot to get to a bigger buffer space. At the bottom of the page on the corelan tutorial I’m about to share, you’ll find a reference chart listing a couple of different JMP’s. Pick a couple, load up one of your vulnserver exploits and experiment with them. It’s important that you understand the various conditions that need to be met for some of these JMP’s to occur. https://www.corelan.be/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-2/ Also be sure to check out this article for more inspiration: http://www.securitysift.com/windows-exploit-development-part-4-locating-shellcode-jumps/ Lesson 7 – Fuzzing For the OSCE, you have to use a fuzzer called Spike. While incredibly power and versatile, it’s not the prettiest and require a bit of work on your part. It’s not difficult to use, but it’s very easy to screw up if you don’t pay attention to your fuzzing template. When building a template, be sure to first interact with the program the normal way while running wireshark. As an example, FTP to a server and have a look at what the traffic looks like. Your job now is to create your spike template to replicate exactly what wireshark has captured. Once again, fire it up when running spike to double check that you’re in fact getting the same result. Since your already familiar with vulnserver, it would be a good idea to practice it there. Here are two tutorials that will help you do just that. http://resources.infosecinstitute.com/intro-to-fuzzing/ http://resources.infosecinstitute.com/fuzzer-automation-with-spike/ Lesson 8 – More Assembly Now it’s time to watch some more SLAE videos, except this time you’ll notice that I’m leaving out a couple of them. Your welcome to watch them of course, but as I mentioned earlier I want to give you only the essential for you to focus on given your limited time. The SLAE videos I recommend is 13, 15-21. The total video length is 1 hour and 27 minutes. Lesson 9 – Structured Exception Handlers (SEH) Before we start, rest assured that this is not a hard topic. It’s well documented and once you have the hang of it, then it’s a piece of cake. Start out by going through these tutorials first. https://www.corelan.be/index.php/2009/07/25/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh/ https://www.corelan.be/index.php/2009/07/28/seh-based-exploit-writing-tutorial-continued-just-another-example-part-3b/ http://www.securitysift.com/windows-exploit-development-part-6-seh-exploits Next up, it’s your time to practice SHE on your trusty vulnserver. http://resources.infosecinstitute.com/buffer-overflow-vulnserver/ Lesson 10 – Egghunters A lot of people recommend the scape egghunter paper which you can find here. http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf Your welcome to go through it, but I have to say that after spending a whole day on this, I didn’t walk away with much value that I could apply in practice. Don’t get me wrong it’s a great paper, but it was published in 2004 and effectively you’ll only need to make use of one of the egghunters in that paper. These two tutorials should give you everything that you need to get cracking (sorry I couldn’t help myself with the pun) https://www.corelan.be/index.php/2010/01/09/exploit-writing-tutorial-part-8-win32-egg-hunting/ http://www.securitysift.com/windows-exploit-development-part-5-locating-shellcode-egghunting Security Sift also talks about a technique called an omelet. You can skip that part because it doesn’t relate to the CTP course. Now head back to vulnserver and give your egghunter a test! Lesson 11 – ASLR Alright, this very similar to SEH in terms of complexity (which to say that it’s not that hard once you get the hang of it). You have to keep your blinkers on and only read the section in this paper that covers ASLR and skip everything else. https://www.corelan.be/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/ In fact, don’t spend much time here because the CTP course does a great job of covering everything you need to know about ASLR. Lesson 12 – Restricted Characters By now you know all about bad characters and how to identify them. There is a whole chapter in the CTP course that deals with a particularly restrictive exploit which is quite infamous. Grab some popcorn and watch this amazing defcon talk by Mati regarding this very exploit. At this stage you’ll be able to follow along without any problems, but don’t worry about trying to replicate it just yet. You’ll be spending a lot of time in CTP doing just that. Instead, I would recommend that you head back to vulnserver. Some of the potential exploits have some bad characters that you can play with, but I would recommend a different approach. Create an exploit – and limit yourself instead. Limit a couple of your favorite commands like EB, and find alternative ways to get the same result. JMP commands are a great way of challenging yourself because the results are obvious and requires a bit of creative thinking. http://resources.infosecinstitute.com/restricted-character-set-vulnserver/ Exploit development requires a significant amount of creative thinking. Blindly following steps isn’t going to get you far so make sure you have a few tricks up your sleeve. Lesson 13 – Mona The CTP course is delivered in olly, but your welcome to make use of immunity and mona (neither are restricted in the exam). Mona can make your life a lot easier so I would recommend that you spend a bit of time getting to know some of the most commonly used commands. In fact, identifying bad characters is one of the most useful features of Mona so it builds on the previous lesson quite nicely. There is an extensive reference list here: https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/ Lesson 14 – Shellcoding Now this is where the fun REALLY starts. Disclaimer – shellcoding per se is not covered in the CTP course. That being said, I think it’s important enough to include here because it allows you to understand what your shellcode is doing, as well as to make some changes to it yourself. Keep in mind however that when you inspect a metasploit generated shell remember not to encode it otherwise it won’t make much sense. For the corelan tutorial, you should not only read it but actually do it yourself. I cannot stress the value of doing this enough https://www.corelan.be/index.php/2010/02/25/exploit-writing-tutorial-part-9-introduction-to-win32-shellcoding/ Now would be a good time to watch SLAE videos 22-26 and pay attention to how he makes use of linux syscalls. It’s only one and a half hour but these videos are particularly packed with amazing information. Next up check out these guides in the order that they are listed. https://www.fuzzysecurity.com/tutorials/expDev/6.html http://sh3llc0d3r.com/windows-reverse-shell-shellcode-i/ http://www.vividmachines.com/shellcode/shellcode.html#ws Lesson 15 – Anti-Virus evasion This is a particularly tricky topic to recommend resources on because it’s a very deep rabbit hole. Remember that CTP/OSCE is primarily focused exploit development, and AV evasion is just one part of that. The techniques covered in CTP are a bit outdated, but still form the foundation of many other techniques. Because you can easily get side tracked, I would recommend sticking to the SLAE videos 27-36 only. I know it’s tempting to do more research (and your welcome to) but if your time is limited then you can just focus on the videos which will prepare you adequately. There is 2 hours and 30 minutes worth of information to go through in the videos. Lesson 16 – Develop your own exploit! At this stage, you know more than enough go out and create and publish your very own 0day (of sorts). Back in 2016, I discovered a set of 0days in products that are all created by one company. Since then, they have released many more versions of the same software – all of them vulnerable but require different exploits. If you search exploit-db, you’ll find that a lot of other people have created exploits since them for all the various different versions, and have done so in various different ways. Now it’s your turn. Download the software, get fuzzing, develop an exploit and submit to exploit-db J Make sure that it hasn’t been done before for the version that your targeting, and if it has then at the very least you have to use a completely different technique to get it working. The company and software downloads can be found here: http://www.flexense.com/ Here is one example of one of my early exploits for one of their products: https://www.exploit-db.com/exploits/40455/ Fuzzing one of the flexsense products will be a great exercise for you because it challenges you to recreate HTTP traffic in a spike template. Remember to look at EVERYTHING you do under wireshark. Lesson 17 – Web Applications Last but not least I wanted to discuss the web application section of the course. CTP does a phenomenal job at covering everything you need to know in such a way that preparing you for it would be redundant. That being said, I want to offer you a few resources and words of advice. The two main topics that you really need to master and know everything about is LFI and XSS. Finding those vulnerabilities are one thing, but make sure you know about the various ways in which you can exploit it to gain remote access to a server. Yup that’s right. Here are a couple of resources that I found useful in my research of the topic: https://www.exploit-db.com/docs/40992.pdf https://excess-xss.com/ https://www.veracode.com/security/xss Lesson 18 – Now what? At this stage you should be more than ready to take the CTP course. I would recommend working through the entire CTP course a minimum of three times, and make sure you do everything manually. As an example, you will be expected to do some manual shell encoding. Sure you can do this with a script, but you would really be cheating yourself out of an amazing (and painful) learning experience. Along the way I would also recommend that you spend a bit of time reading the exploits in exploit-db. I have learned a lot of very useful scripting techniques in a very short space of time because of this. In fact, I would go so far as to say that you start a collection of skeleton exploits for various purposes. I have also gone through a good couple of books in preparation for the OSCE exam and while some of them are really good (like the Shellcoders handbook), it didn’t really help me all that much. Offensive Security does a fantastic job with the course material and I would recommend that you expand your search for additional material only once you have gone through the manual and videos. The course has less to do with reading material, and more to do with practice. There is no substitution for practice and your time will be well spent doing just that. Sursa: https://tulpa-security.com/2017/07/18/288/

Burp-molly-scanner Overview The main goal of Burp-molly-scanner is to extend Burp and turn it into headless active scanner. Usage Build fat jar with Maven Rewrite burp_molly_config.json Put path to config in MOLLY_CONFIG Environment variable Run Burp Suite in console java -jar burpsuite_pro.jar Add Plugin in Extender Tab (once) Run scanner in headless mode (see run.sh) Parse resulting XML report Integrate it to your security pipeline Contributing Contributions to Burp-molly-scanner are always welcome! You can help us in different ways: Open an issue with suggestions for improvements and errors you're facing; Fork this repository and submit a pull request; Improve the documentation. Sursa: https://github.com/yandex/burp-molly-scanner/

eaphammer by Gabriel Ryan (s0lst1c3) Overview EAPHammer is a toolkit for performing targeted evil twin attacks against WPA2-Enterprise networks. It is designed to be used in full scope wireless assessments and red team engagements. As such, focus is placed on providing an easy-to-use interface that can be leveraged to execute powerful wireless attacks with minimal manual configuration. To illustrate how fast this tool is, here's an example of how to setup and execute a credential stealing evil twin attack against a WPA2-TTLS network in just two commands: # generate certificates ./eaphammer --cert-wizard # launch attack ./eaphammer -i wlan0 --channel 4 --auth ttls --wpa 2 --essid CorpWifi --creds Leverages a lightly modified version of hostapd-wpe (shoutout to Brad Anton for creating the original), dnsmasq, Responder, and Python 2.7. Features Steal RADIUS credentials from WPA-EAP and WPA2-EAP networks. Perform hostile portal attacks to steal AD creds and perform indirect wireless pivots Perform captive portal attacks Built-in Responder integration Support for Open networks and WPA-EAP/WPA2-EAP No manual configuration necessary for most attacks. No manual configuration necessary for installation and setup process Leverages latest version of hostapd (2.6) Support for evil twin and karma attacks Generate timed Powershell payloads for indirect wireless pivots Integrated HTTP server for Hostile Portal attacks Support for SSID cloaking Upcoming Features Perform seemeless MITM attacks with partial HSTS bypasses Support attacks against WPA-PSK/WPA2-PSK directed rogue AP attacks (deauth then evil twin from PNL, deauth then karma + ACL) Integrated website cloner for cloning captive portal login pages Integrated HTTP server for captive portals Sursa: https://github.com/s0lst1c3/eaphammer

As many of you know, there was a lot of passion within the application security community about the OWASP Top 10 2017 RC1, so it was critical that we worked with the community to firm up the data and obtain a consensus view of how to proceed. After the change of leadership from Dave Wichers and Jeff Williams to Andrew van der Stock in late May 2017, we added diversity to the leadership team, by adding Neil Smithline, Torsten Gigler, and Brian Glas. Each of the leaders brings their own experience and point of view to the OWASP Top 10, making it far stronger. I couldn't have done this by myself, and it would have been a far weaker document if it was just little old me. I thank my co-leaders from the bottom of my heart. I also thank the founding leadership of Dave Wichers and Jeff Williams for creating the OWASP Top 10, and trusting in us to get this done. In June, Dave Wichers and Brian Glas attended the OWASP Project Summit in London, and I participated remotely. During the summit, as a community, we agreed to governance, methodology, data analysis and transparency improvements. The highlights of this are: A diversity of leadership at all times (at least two unrelated leaders). This has been an incredible win for the OWASP Top 10, and I hope more OWASP Flagship projects consider doing it. The methodology was improved by confirming that we will be using risks, rather than any other metric, and agreeing to up to two items will be selected by the community for up and coming risks Data analysis performed by Brian Glas, in particular how to improve the balance from largely automated findings that swamp manual findings, as well as re-opening the data call to obtain 2016 data and survey the community for the two forward looking items Transparency is now aligned with OWASP's values - we work in the open at GitHub, and folks can see who suggested an improvement or issue, and how this was resolved in the text. For the first time, there is a strong traceability between the data submitted by participating data contributors and the OWASP Top 10. This means that if you want, you can fork the OWASP Top 10, re-analyze the data to suit your needs and create your own version. (Just don't call it the OWASP Top 10 ) The data call was very successful. We obtained a great deal of new data covering previous years, including 2016, from a wide variety of consultancies and vendors. We have data from over 40 data contributors, 23 of which were used in the final data analysis. From those 23 data sets, the data covered over 114,000 applications, which is one of the biggest data sets on application security anywhere. And you can download it from our GitHub repo. At the last minute, we also received data from BugCrowd. The interesting thing about bug bounty programs is that kudos and payouts only occur when fully validated, and it also shows what is on the top of the list from the point of view of bug bounty programs. The bug bounty data backed up our analysis in terms of prevalence data, so we were definitely on the right track. The survey was wildly successful. We received over 500 survey responses, so I think we can safely claim consensus on the two new items - Insecure Deserialization and Insufficient Logging and Monitoring. These two items were obviously top of mind for many this year considering the era of the mega breach is not slowing down. We discuss our methodology in more detail within the OWASP Top 10 - 2017 itself, as many will wonder why we didn't use the two top items directly. The short answer - and this should be no surprise - some of these other issues were already in the OWASP Top 10 due to prevalence data, such as XXE and access control. I will address some of the frequently asked questions - why have CSRF and unvalidated redirects and forwards been removed? It's time to move on. The data for these is no longer strong enough to warrant inclusion, especially when we only have 8 data supported spots with our new methodology, and these two items didn't rank in the community survey. This is actually a sign of success; the fact that CSRF is finally going away is a sign that the OWASP Top 10 has been successful at its mission. Back when I included CSRF in 2007 as a forward looking item, there was no data for it. At all. But ~ 100% of applications had CSRF at that time. Now it's less than 5% of all applications. If you use a modern framework, you're pretty much covered without doing anything. That's a huge success. This then leads into the discussion about renumbering. We risk rated the resulting list over about a 5 hour meeting, and this is the result. I asked the Twitter community if they wanted a risk based order, a likelihood order, an impact order, or the order from previous OWASP Top 10's. Overwhelmingly risk based order won. Interestingly, the previous OWASP Top 10's kept the previous order, but this was wanted by less than 10% of respondents, compared to over 55% for risk based ordering. So that's what happened. What surprised me is that after re-risk rating many of the existing items didn't move. I was actually surprised by this, particularly in relation to SQL injection, but because we include all forms of injection (which theoretically can cover XSS), it remained at the A1:2017 position. This is because we couple three forms of likelihood (prevalence, detectability, and exploitability) and impact. We have strong prevalence data, but the others were our best judgement. You can look at what we decided upon and review our work. I encourage everyone to do so. The last common discussion we've had is why we didn't roll up XSS into injections, because it's either HTTP, HTML, or JavaScript injection. The reality is that it would have swamped the important discussion on other injections, and the solutions for XSS are significantly different to preventing OS command injection or SQL injection. I will defend this decision until the day we see XSS gone the way of CSRF. And I can't see that day ... yet. There is hope in the form of CSP and XSS-resistant frameworks such as Ruby on Rails 3 and React, but there's a lot of code out there that is still vulnerable. The new or heavily updated risks need little explanation: We cover API as well as web apps throughout the entire Top 10. This covers mobile, single page apps, RESTful API and traditional web apps. A3:2017 Sensitive Data Exposure is now firmly about privacy and PII breaches, and not stack traces or headers. A4:2017 XXE is a new data supported item, and so tools and testers need to learn how to find and test for XXE, and developers and devops need to understand how to fix it. A6:2017 Misconfiguration now encompasses cloud security issues, such as open buckets. A8:2017 Deserialization is a critical issue, asked for by the community. It's time to learn how to find this in tools, and for testers to understand what Java and PHP (and other serialization) looks like so it can be fixed. A10:2017 Insufficient Logging and Monitoring. Many folks think this is a missing control, rather than a weakness, but as it was selected by the community, and whilst organizations still take over half a year to detect a breach - usually from external notification - we have to fix this. The way to go forward here for testers is to ask the organization if they detected whatever activity was undertaken, and if they would have responded to it without being prompted. Obviously, we are looking for testing to be undertaken through security devices, but whitelisted, so that logging, escalation and incident response can also be assessed. These new items are modern era issues, and I hope that in the next three years, the industry can make headway on them. So after more than 370 closed issues and 650 commits, we are finally finished. We received a lot of feedback from the community, and we thank those who reviewed and QA'd the document extremely closely, such as Osama Elnaggar, Dirk Wetter and Jim Manico, as well as over 40 others. For a full list of reviewers, please see the acknowledgement page. What is the future of the OWASP Top 10? I think if anything, the community's passion during this time around shows how important the OWASP Top 10 is. It is widely adopted and a lot of folks care about it very deeply. It was a time for us to listen and learn from the process, and that will result in improvements for the OWASP Top 10 - 2020. We will be starting the data collection process much earlier, and we will improve our methodology particularly in relation the survey to provide more choices (we only had 25 CWEs). On top of that, we need to work with NIST / MITRE to keep CWE up to date, because some of the biggest up and coming (and to be fair, some of the existing) weaknesses do not have a CWE entry. But first, we need a break. Thank you to everyone who participated to make the OWASP Top 10 a much stronger and more evidence based standard. The OWASP Top 10 - 2017 is by far the best sourced, most reviewed, application security standard out there. I encourage everyone to download it and start cracking on the new and updated items. We need translations as well, so if you want to do that, please contact us at @owasptop10 on Twitter or via GitHub. Sursa: https://owasp.blogspot.ro/2017/11/owasp-is-pleased-to-announce-release-of.html

DNS-shell DNS-Shell is an interactive Shell over DNS channel. The server is Python based and can run on any operating system that has python installed, the payload is an encoded PowerShell command. Understanding DNS-Shell The Payload is generated when the sever script is invoked and it simply utilizes nslookup to perform the queries and query the server for new commands the server then listens on port 53 for incoming communications, once payload is executed on the target machine the server will spawn an interactive shell. Once the channel is established the payload will continously query the server for commands if a new command is entered, it will execute it and return the result back to the server. Sursa: https://github.com/sensepost/DNS-Shell

Devoxx Publicat pe 11 nov. 2017 Java is everywhere. According to Oracle it’s on 3 billion devices and counting. We also know that Java is one of the most popular vehicles for delivering malware. But that’s just the plugin right? Well maybe not. Java on the server can be just at risk as the client. In this talk we’ll cover all aspects of Java Vulnerabilities. We’ll explain why Java has this dubious reputation, what’s being done to address the issues and what you have to do to reduce your exposure. You’ll learn about Java vulnerabilities in general: how they are reported, managed and fixed as well as learning about the specifics of attack vectors and just what a ‘vulnerability’ actually is. With the continuing increase in cybercrime it’s time you knew how to defend your code. With examples and code this talk will help you become more effective in tacking security issues in Java. # Steve Poole Steve Poole is a DevOps practitioner (leading a large team of engineers on cutting edge DevOps exploitation ) and a long time IBM Java developer, leader and evangelist. He’s been working on IBM Java SDKs and JVMs since Java was less than 1. He's also had time to work on other things including representing IBM on various JSRs, being a committer on various open source projects including ones at Apache, Eclipse and OpenJDK. He’s also member of the Adopt OpenJDK group championing community involement in OpenJDK. Steve is a seasoned speaker and regular presenter at JavaOne and other conferences on technical and software engineering topics.

Black Hat Publicat pe 20 nov. 2017 In kernel-mode, buffer overflows and similar memory corruption issues in the internal logic are usually self-evident and can be detected with a number of static and dynamic approaches. On the contrary, flaws directly related to interactions with user-mode clients tend to be more subtle, and can survive unnoticed for many years, while still providing primitives similar to the classic bugs. By Mateusz Jurczyk Read More: https://www.blackhat.com/us-17/briefi...

Attacking Uninitialized Variables with Recursion zznop / November 19, 2017 / Exploitation Overview Recursion can be defined as a computer programming technique involving the use of a procedure, subroutine, function, or algorithm that calls itself one or more times until a specified condition is met. There are debates about recursion, how it should be used, and whether it should be used at all. Recursion is a useful tool that should be in every programmers toolbox. However, when it’s used incorrectly it can over complicate flow logic and introduce vulnerabilities in code. This has lead to some coding standards explicitly banning its use, along with banning other complex flow constructs such as goto. In a nutshell, recursion can get confusing, and confusing code can lead to programming mistakes. In this post I explain recursion and how it can be leveraged for vulnerability research. I also share a plugin I wrote that leverages Binary Ninja’s medium level intermediate language (MLIL) to develop a cross-architecture solution for locating recursive logic in compiled code. Recursion Summary Recursion can be broken down into two categories, Direct Recursion and Indirect Recursion. Direct recursion occurs when a routine invokes itself. There are many practical applications for direct recursion such as mathematical algorithms, list sorts, and binary search trees. An example of direct recursion is depicted below. This example returns the factorial of the supplied integer (the product of the integer and all descending integers below it). uint32_t factorial(uint32_t number) { if (number <= 1) { return 1; } return number * factorial(number -1); } 1 2 3 4 5 6 7 8 9 uint32_t factorial(uint32_t number) { if (number <= 1) { return 1; } return number * factorial(number -1); } Indirect recursion occurs when a routine invokes another routine that eventually results in the invocation of the original routine. The most practical use I’ve found for indirect recursion is a directory traversal program containing a routine that navigates the tree, and another routine that processes the files. If the file is a directory, then the original routine is invoked. Another example, that can be used to check if an integer is odd or even, is depicted below. int is_odd(int number) { return number == 0 ? 0 : is_even(abs(number) - 1); } int is_even(int number) { return number == 0 ? 1 : is_odd(abs(number) - 1); } 1 2 3 4 5 6 7 8 9 int is_odd(int number) { return number == 0 ? 0 : is_even(abs(number) - 1); } int is_even(int number) { return number == 0 ? 1 : is_odd(abs(number) - 1); } Recursion in Vulnerability Research Stack Overflow Denial-of-Service Recursion tends to cause problems when the amount of recursive calls are not properly bounded. When a function call is carried out by an x86 processor, the return address and the function arguments are pushed onto the call stack. With each recursive call, the stack continues to grow exponentially. If recursion is too deep, a stack overflow will occur once the allocated stack size is exceeded. Recursion-induced stack overflows are rarely exploitable and often only result in denial-of-service. This is because recusion-based stack overflows exceed the top of the stack region as the call stack grows during recursion. Above the stack (in most cases) there is a gaurd page present that prevents the stack from clashing with another memory region. However, gaurd pages aren’t used in all environments. The Linux kernel for example does not employ this protection. There are also techniques for jumping the gaurd page and overflowing into the heap. These techniques require that the recursive function declares sufficiently large stack variables and that heap memory is near the other side of the guard page. More on jumping gaurd pages can be found here. Attacking Uninitialized Stack Variables with Recursion Another role recursion could play in exploiting a vulnerable program is attacking uninitialized stack variables. As mentioned previously, x86 calling convention dictates that function arguments are pushed to the stack by the caller. If an attacker can control the values supplied as function arguments during recursion they could spray the stack with values that could be used to initialize a “uninitialized” stack-based variable. Compilers assume that when you declare a variable, that you are going to initialize it (before using it). Compilers account for this by assigning a virtual location to store the value. In the case of a uninitialized stack variable, the compiler will assign a location on the stack. Since stack frames across function invocations can overlap (and be re-used), an uninitialized stack variable will often contain junk data left behind by a previously invoked routine, until which point it is initialized. To illustrate how recursion can play a role in abusing uninitialized variables, I wrote a very practical program that should set me up nicely for the next Turing award. #include <stdio.h> #include <stdlib.h> #include <stdint.h> void take_int(int j) { if (j == 1337) printf("How could this be? j was never initialized!\n"); } void recursive_func(int n) { static int i = 0; i++; if (i == 10) return; else recursive_func(n); } void func() { int j; take_int(j); } int main(int argc, char **argv) { int n = atoi(argv[1]); recursive_func(n); func(); return 0; } 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 #include <stdio.h> #include <stdlib.h> #include <stdint.h> void take_int(int j) { if (j == 1337) printf("How could this be? j was never initialized!\n"); } void recursive_func(int n) { static int i = 0; i++; if (i == 10) return; else recursive_func(n); } void func() { int j; take_int(j); } int main(int argc, char **argv) { int n = atoi(argv[1]); recursive_func(n); func(); return 0; } The program above takes an integer as a command-line argument and calls recursive_function, which recurses 10 times. Then the program calls func, which calls take_int while passing j as an argument. The vulnerability in this code exists in func. The variable j is declared, but never initialized before being passed to take_int. Let’s compile and run this program while supplying 1337 as a command-line argument. $ gcc recursion_demo.c -m32 -o recursion_demo $ ./recursion_demo 1337 How could this be? j was never initialized! 1 2 3 $ gcc recursion_demo.c -m32 -o recursion_demo $ ./recursion_demo 1337 How could this be? j was never initialized! The conditional in take_int (which checks if j equals 1337) clearly evaluated as true, despite that j was never initialized, but why? After recursive_func returns in main, the stack resembles the illustration depicted below. During repeated recursive calls, the stack pointer is adjusted into lower addressable memory and n (0x00000539) is pushed to the stack along with the return address of the caller. With each time that the function recurses, we have better odds that we can get the program to use our value when accessing the uninitialized variable in take_int. In addition to the return address, and the function argument, there’s also additional data on the stack caused by logic within recursive_func. This is the challenge of attacking uninitialized variables in practical applications. It is difficult to get your data to overlap with the offset used by the uninitialized variable, and it is difficult to achieve this without some other instruction clobbering it before your variable is referenced. Stack Layout After Recursion By the time take_int is called, the stack has been polluted with 0x00000539 entries. In the figure below, at 00000644, the operand (stack offset) that is supposed to contain the value of j, is copied onto the stack as the first argument for take_int. However, [ebp-0xc] does not contain the value of j, because j was never initialized. Instead it contains 0x00000539, which was left behind from a call setup for recursive_func. take_int call setup Depicted in the next screenshot is the disassembly for a portion of take_int. The most important instruction is at 000005d1. This instruction is where the pointer to arg1 (j) is dereferenced and compared with the constant value 0x00000539. As already established, j is never set, so the program uses what was left behind on the stack at that location, which happens to be 0x00000539, left behind from one of the calls to recursive_func. The two compared values are equal. Therefore, the program does not take the branch at 000005d8 and proceeds to print the anti-climatic output. take_int Dereference of Uninitialized Stack Variable j The example program will behave different depending on your version of gcc and how it compiles the source. I compiled the program with gcc version 6.3.0 20170516. It is likely that the example won’t work if you use a different version of gcc. Instead of the uninitialized stack variable (j) overlapping with addressable memory containing your sprayed argument for recursive_func (n), it may instead overlap with a return address or some other data on the stack. It is all dependent on how the compiler lays out the instructions. If you insist on running the example, and your compiler isn’t cooperating, leave a comment or shoot me an email and I’ll post my binary. Binary Ninja Recursion Plugin As part of my endeavor to study recursion, I developed a plugin that uses Binary Ninja’s API and medium level intermediate language to locate recursive logic in compiled code. The plugin is capable of identifying both direct and indirect recursion and applies comments to recursive functions and their caller instructions. It also generates a markdown page that is rendered in BN’s UI that contains the locations of recursive logic. It works against binaries compiled under all architectures supported by BN. This plugin is part of Binjago, a suite of plugins that I’ve written to aid in static analysis. A screenshot of the instruction comments applied by the plugin is depicted below. The plugin can be found here. Binjago Recursive Logic Annotations Conclusion Complex recursive routines are often difficult to understand, which sometimes leads to other programming mistakes in surrounding logic. Unbounded recursion can be leveraged to smash the stack and under some conditions, recursion can be leveraged to effect the layout of the stack to attack an uninitialized stack variable. If you are interested in reading about a recursion vulnerability that has been exploited in practice, I recommend Project Zero: Exploiting Recursion in the Linux Kernel. Thank you for reading! Sursa: https://signal11.io/index.php/2017/11/19/attacking-uninitialized-variables-with-recursion/

Clarifying the behavior of mandatory ASLR swiat November 21, 2017 Last week, the CERT/CC published an advisory describing some unexpected behavior they observed when enabling system-wide mandatory Address Space Layout Randomization (ASLR) using Windows Defender Exploit Guard (WDEG) and EMET on Windows 8 and above. In this blog post, we will explain the configuration issue that CERT/CC encountered and describe work arounds to enable the desired behavior. In short, ASLR is working as intended and the configuration issue described by CERT/CC only affects applications where the EXE does not already opt-in to ASLR. The configuration issue is not a vulnerability, does not create additional risk, and does not weaken the existing security posture of applications. The briefest of histories: mandatory and bottom-up ASLR In a previous blog post we explained how ASLR works on Windows. The vast majority of this explanation still holds true through the latest version of Windows 10 (1709). In the interest of brevity, we’ll focus on the details that are relevant to the behavior observed by CERT/CC: Randomization of EXEs/DLLs is opt-in. EXEs/DLLs tell the operating system they are compatible with ASLR by linking with the /DYNAMICBASE flag. This flag has been enabled by default since Visual Studio 2010. The opt-in model was an intentional choice to avoid non-trivial compatibility issues with existing applications. Mandatory ASLR can be used to forcibly rebase EXEs/DLLs that have not opted in. In Windows 8, we introduced operating system support for forcing EXEs/DLLs to be rebased at runtime if they did not opt-in to ASLR. This mitigation can be enabled system-wide or on a per-process basis. It works by forcing a base address conflict at the time that a non-ASLR EXE/DLL is mapped. When this occurs, the new base address of the EXE/DLL is selected by searching for a free region starting from the bottom of the address space. Bottom-up randomization provides entropy for bottom-up allocations. In Windows 8, we also introduced opt-in support for bottom-up randomization which adds entropy to the base address selected for allocations that search for a free region starting from the bottom of the address space (e.g. EXEs/DLLs rebased due to mandatory ASLR). This provides implicit biasing of all bottom-up allocations and can be enabled system-wide or on a per-process basis. Bottom-up randomization is enabled by default only if the process EXE opts in to ASLR. This is for compatibility reasons as applications whose EXE did not opt-in to ASLR (via /DYNAMICBASE) do not necessarily expect their address space layout to change from one execution to the next. The following table attempts to make this easier to understand by considering the behavior of ASLR in different configurations for a given process: The behavior that CERT/CC observed A consequence of the above is that the entropy of images rebased by mandatory ASLR is inherently reliant on bottom-up randomization being enabled for the process. However, bottom-up randomization is not automatically enabled for process when the process EXE does not opt-in to ASLR (as highlighted in yellow in the table above). This means that bottom-up randomization must also be enabled for entropy to be applied to images that are rebased by mandatory ASLR. In practice, this issue only affects scenarios where an administrator is intentionally attempting to enable mandatory ASLR for a process that would otherwise not fully benefit from ASLR. CERT/CC did identify an issue with the configuration interface of Windows Defender Exploit Guard (WDEG) that currently prevents system-wide enablement of bottom-up randomization. The WDEG team is actively investigating this and will address the issue accordingly. Similarly, EMET does not support enabling bottom-up randomization system-wide and therefore cannot directly configure this setting. Fortunately, there are workarounds available for this configuration issue. Workarounds There are two workarounds for those who would like to enable mandatory ASLR and bottom-up randomization for processes whose EXE did not opt-in to ASLR. As with all non-default configuration, these changes may introduce application compatibility issues and care should be taken to validate that applications work as expected. Directly enabling mandatory ASLR and bottom-up randomization via the system-wide registry value. Saving the following into optin.reg and importing it will enable mandatory ASLR and bottom-up randomization system-wide. This is the same registry value that WDEG and EMET modify through their configuration user interfaces. Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\kernel] "MitigationOptions"=hex:00,01,01,00,00,00,00,00,00,00,00,00,00,00,00,00 Note, applying this registry file will override any other mitigations that have been applied system-wide. To retain the existing settings, the MitigationOptions registry value can be manually edited such that the 2nd byte is set to ?1 (where ? retains its value, e.g. 01) and the 3rd byte is set to ?1. The second byte corresponds to mandatory ASLR and the third byte corresponds to bottom-up ASLR. Enabling mandatory ASLR and bottom-up randomization via program-specific configuration using WDEG or EMET. From WDEG, mitigations can be enabled on a per-program basis using the user interface or command line tools as described here. Enabling force randomization for images (mandatory ASLR) and randomize memory allocations (bottom-up ASLR) will enable the expected behavior as shown below: Why did this work differently with EMET on Windows 7? One of the noteworthy observations that CERT/CC made is that enabling system-wide mandatory ASLR via EMET on Windows 7 does not exhibit the behavior described above. Instead, processes whose EXE did not opt-in to bottom-up ASLR are still observed to be randomized. The reason for this is that EMET on Windows 7 enabled mandatory ASLR using a different setting versus what is now used on Windows 8 and above. The setting that EMET uses on Windows 7 results in all images being treated as if opted-in to ASLR (e.g. as if they were linked with /DYNAMICBASE). As a consequence, bottom-up randomization of stacks and heaps is implicitly enabled for all processes as a side effect of them being treated as if they had opted-in to ASLR and the images themselves are randomized just like other ASLR images. This differs from the behavior of mandatory ASLR because mandatory ASLR forcibly rebases images and does not treat them as if they had opted into to ASLR. The setting used by EMET on Windows 7 is not recommended and is intentionally hidden by default due to the application compatibility risk associated with it. EMET users must expose this setting by navigating to EMET’s Advanced options as described here. Wrapping up In summary, the behavior of mandatory ASLR that CERT/CC observed is by design and ASLR is working as intended. The WDEG team is investigating the configuration issue that prevents system-wide enablement of bottom-up ASLR and is working to address it accordingly. This issue does not create additional risk as it only occurs when attempting to apply a non-default configuration to existing versions of Windows. Even then, the effective security posture is no worse than what is provided by default and it is straightforward to work around the issue through the steps described in this post. Matt Miller Microsoft Security Response Center (MSRC) Sursa: https://blogs.technet.microsoft.com/srd/2017/11/21/clarifying-the-behavior-of-mandatory-aslr/

Kali Linux 2017.3 Release November 21, 2017dookieKali Linux Releases We are pleased to announce the immediate availability of Kali Linux 2017.3, which includes all patches, fixes, updates, and improvements since our last release. In this release, the kernel has been updated to 4.13.10 and it includes some notable improvements: CIFS now uses SMB 3.0 by default EXT4 directories can now contain 2 billion entries instead of the old 10 million limit TLS support is now built into the kernel itself In addition to the new kernel and all of the updates and fixes we pull from Debian, we have also updated our packages for Reaver, PixieWPS, Burp Suite, Cuckoo, The Social Engineering Toolkit, and more. Take a look at the Kali Changelog to see what else has been updated in this release, or read on to see what else is new. New Tool Additions Since our last release in September, we’ve added four new tools to the distribution, most of which focus on the always-lucrative open source information gathering. These new tools are not included in the default installation but after an ‘apt update’, you can check out and install the ones that interest you. We, of course, think they’re all interesting and hope you do as well. InSpy InSpy is a small but useful utility that performs enumeration on LinkedIn and can find people based on job title, company, or email address. root@kali:~# apt update && apt -y install inspy root@kali:~# inspy --empspy /usr/share/inspy/wordlists/title-list-large.txt google InSpy 2.0.3 2017-11-14 14:04:47 53 Employees identified 2017-11-14 14:04:47 Birkan Cara Product Manager at Google 2017-11-14 14:04:47 Fuller Galipeau Google 2017-11-14 14:04:47 Catalina Alicia Esrat Account Executive at Google 2017-11-14 14:04:47 Coplan Pustell Recruiter at Google 2017-11-14 14:04:47 Kristin Suzanne Lead Recruiter at Google 2017-11-14 14:04:47 Baquero Jahan Executive Director at Google 2017-11-14 14:04:47 Jacquelline Bryan VP, Google and President of Google.org 2017-11-14 14:04:47 Icacan M. de Lange Executive Assistant at Google ... CherryTree The oft-requested CherryTree has now been added to Kali for all of your note-taking needs. CherryTree is very easy to use and will be familiar to you if you’ve used any of the “big-name” note organization applications. root@kali:~# apt update && apt -y install cherrytree Sublist3r Sublist3r is a great application that enables you to enumerate subdomains across multiple sources at once. It has integrated the venerable SubBrute, allowing you to also brute force subdomains using a wordlist. root@kali:~# apt update && apt -y install sublist3r root@kali:~# sublist3r -d google.com -p 80 -e Bing ____ _ _ _ _ _____ / ___| _ _| |__ | (_)___| |_|___ / _ __ \___ \| | | | '_ \| | / __| __| |_ \| '__| ___) | |_| | |_) | | \__ \ |_ ___) | | |____/ \__,_|_.__/|_|_|___/\__|____/|_| # Coded By Ahmed Aboul-Ela - @aboul3la [-] Enumerating subdomains now for google.com [-] Searching now in Bing.. [-] Total Unique Subdomains Found: 46 [-] Start port scan now for the following ports: 80 ads.google.com - Found open ports: 80 adwords.google.com - Found open ports: 80 analytics.google.com - Found open ports: 80 accounts.google.com - Found open ports: 80 aboutme.google.com - Found open ports: 80 adssettings.google.com - Found open ports: 80 console.cloud.google.com - Found open ports: 80 ... OSRFramework Another excellent OSINT tool that has been added to the repos is OSRFramework, a collection of scripts that can enumerate users, domains, and more across over 200 separate services. root@kali:~# apt update && apt -y install osrframework root@kali:~# searchfy.py -q "dookie2000ca" ___ ____ ____ _____ _ / _ \/ ___|| _ \| ___| __ __ _ _ __ ___ _____ _____ _ __| | __ | | | \___ \| |_) | |_ | '__/ _` | '_ ` _ \ / _ \ \ /\ / / _ \| '__| |/ / | |_| |___) | _ <| _|| | | (_| | | | | | | __/\ V V / (_) | | | < \___/|____/|_| \_\_| |_| \__,_|_| |_| |_|\___| \_/\_/ \___/|_| |_|\_ Version: OSRFramework 0.17.2 Created by: Felix Brezo and Yaiza Rubio, (i3visio) searchfy.py Copyright (C) F. Brezo and Y. Rubio (i3visio) 2014-2017 This program comes with ABSOLUTELY NO WARRANTY. This is free software, and you are welcome to redistribute it under certain conditions. For additional info, visit https://www.gnu.org/licenses/agpl-3.0.txt 2017-11-14 14:54:52.535108 Starting search in different platform(s)... Relax! Press <Ctrl + C> to stop... 2017-11-14 14:55:04.310148 A summary of the results obtained are listed in the following table: Sheet Name: Profiles recovered (2017-11-14_14h55m). +---------------------------------+---------------+------------------+ | i3visio_uri | i3visio_alias | i3visio_platform | +=================================+===============+==================+ | http://github.com/dookie2000ca | dookie2000ca | Github | +---------------------------------+---------------+------------------+ | http://twitter.com/dookie2000ca | dookie2000ca | Twitter | +---------------------------------+---------------+------------------+ 2017-11-14 14:55:04.327954 You can find all the information collected in the following files: ./profiles.csv 2017-11-14 14:55:04.328012 Finishing execution... Total time used: 0:00:11.792904 Average seconds/query: 11.792904 seconds Did something go wrong? Is a platform reporting false positives? Do you need to integrate a new one and you don't know how to start? Then, you can always place an issue in the Github project: https://github.com/i3visio/osrframework/issues Note that otherwise, we won't know about it! Massive Maltego Metamorphosis One of our favourite applications in Kali has always been Maltego, the incredible open-source information gathering tool from Paterva, and the equally incredible Casefile. These two applications had always been separate entities (get it?) but as of late September, they are now combined into one amalgamated application that still allows you to run Maltego Community Edition and Casefile, but now it also works for those of you with Maltego Classic or Maltego XL licenses. As always, the tools perform wonderfully and look great doing it. Get the Goods As usual, we have updated our standard ISO images, VMware and VirtualBox virtual machines, ARM images, and cloud instances, all of which can be found via the Kali Downloads page. If you find any bugs, please open a ticket on our bug tracker. We keep an eye on social media but there is no substitute for a well-written bug report and many bugs that get reported to us end up getting fixed in Debian, which then benefits all of its derivatives. Sursa: https://www.kali.org/releases/kali-linux-2017-3-release/

Probabil daca o sa crape emag, o sa vedeti asta:

La Altex a inceput. Eu am gasit ceva ce cautam cu 200 RON mai ieftin, redus de la 700 la 500.

Ati avut azi probleme cu reteaua telefonica? Aveti Telekom? Eu am patit sa ma sune cineva si sa aud pe altcineva. Si alte persoane au patit la fel. Stie cineva ce se intampla?

1. Descarcati APK-ul de la eMag. 2. Uitati-va prin el M-am uitat putin aseara, functionalitatea de BlackFriday e implementata. Nu am gasit URL undeva vizibil, poate sa nici nu fie, dar daca veti cauta dupa "[bB][fF]" o sa gasiti cate ceva.

https://www.amazon.com/Serious-Cryptography-Practical-Introduction-Encryption/dp/1593278268

RST a fost mentionat in (cel putin) doua dintre prezentarile de la Defcamp: - @TheTime - @Matasareanu

O zi de munca mai putin.

VeraCrypt ar trebui sa fie versiunea continuata a TrueCrypt (care fixeaza problemele gasite in TrueCrypt): https://www.veracrypt.fr/en/Home.html Daca vrei modul "hardcore", OpenSSL iti ofera tot ce iti trebuie.

Poate sa arate cum vrei tu cat timp inveti sa: 1. Specifici un fisier (care sa arate cum vrei tu) pe un server 2. Sa te conectezi la server si sa citesti acel fisier (care sa contina ultima versiune si sa o compari cu versiunea actuala) 3. Sa afisezi un mesaj (care sa arate cum vrei tu) de "New update available: Download /Cancel" 4. Sa descarci un fisier (in cazul in care se vrea Download) folosind un progressbar (aici poate deveni mai dificil, dar cred ca gasesti multe exemple utile) 5. Sa instalezi noua versiune

Sincer, nu ma pricep (desi m-am gandit si eu sa imi iau si urma sa fac putin research), dar am inteles ca Nikon D3*** si D5*** sunt pentru incepatori, foarte bune. De asemenea mi s-a spus sa aleg D5*** in locul unui D3*** daca am posibilitatea. Am cativa prieteni pasionati de fotografie.

"using 111 compromised unique certificates issued by recognized CAs and used to sign legitimate software" Acele CA-uri par sa fie importante: Thawte, VeriSign... Oare chiar au pus mana pe cheile private ale root CA-urilor? Nu cred, as merge mai degraba pe coliziuni de hash-uri. "The trio researchers—Doowon Kim, BumJun Kwon and Tudor Dumitras from the University of Maryland, College Park—said they found a total of 325 signed malware samples, of which 189 (58.2%) carried valid digital signatures while 136 carry malformed digital signatures." Avem si romani (asa suna numele) care fac treaba.

Sunt diferente semnificative cand vine vorba de fotografii in coditii de lumina scazuta. DxOMark nu se adreseaza utilizatorilor incepatori, dar cu cateva cunostiinte de nivel mediu legate de o camera, poti sa intelegi cam care ar fi diferentele si pe ce sa mergi mai departe. De asemenea, multe camere frontale (inclusiv iPhone) nu sunt tocmai excelente. Din punctul meu de vedere, camera e unul dintre cele mai importante lucruri cand vine vorba de un telefon. Chiar daca pe Facebook o sa arate nasol, cel putin daca le savezi si te uiti peste ani la ele, o sa ai niste fotografii de calitate. In plus, nu mai trebuie sa cari o camera foto (compacta) ca sa faci poze decente cand calatoresti.

Nikon D5300? Sau D3400?