Nytro

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?

Din punct de vedere "security", as merge pe iPhone. Insa e cam limitat cand vine vorba de functionalitati. Toate telefoanele enumerate stau bine la capitolul "Camera": https://www.dxomark.com/category/mobile-reviews/ Iar despre procesor, RAM etc., suntem in perioada in care un telefon bun nu ar trebui sa aiba astfel de probleme.

Ce telefon v-ati dori? Am facut un poll, sunt curios ca ce pareri sunt pe aici.

Azi e ultima zi in care puteti lua bilet la pret mai mic.