Nytro

OWASP Security Knowledge Framework The OWASP Security Knowledge Framework is intended to be a tool that is used as a guide for building and verifying secure software. It can also be used to train developers about application security. Education is the first step in the Secure Software Development Lifecycle. The 4 Core usage of SKF: Security Requirements OWASP ASVS for development and for third party vendor applications Security knowledge reference (Code examples/ Knowledge Base items) Security is part of design with the pre-development functionality in SKF Use SKF to gather the right security requirements for your projects SKF then gives extensive knowledgebase items that correlates to the security requirements Developers can close "tickets" and leave an audit trail to determine possible technical depts or improvements Security specialist can follow the "tickets" and audit trail and verify or Fail closed items and provide feedback. Description The OWASP Security Knowledge Framework is an expert system web-application that uses the OWASP Application Security Verification Standard and other resources. It can be used to support developers in pre-development (security by design) as well as after code is released (OWASP ASVS Level 1-3). Why Use The OWASP Security Knowledge Framework? Our experience taught us that the current level of security the current web-applications contain is not sufficient enough to ensure security. This is mainly because web-developers simpy aren't aware of the risks and dangers are lurking, waiting to be exploited by hackers. Because of this we decided to develop a security tool in order to create a guide system available for all developers so they can develop applications secure by design. The security knowledge framework is here to support developers create secure applications. By analysing proccessing techniques in which the developers use to edit their data the application can link these techniques to different known vulnerabilities and give the developer feedback regarding descriptions and solutions on how to properly implement these techniques in a safe manner. The seccond stage of the application is validating if the developer properly implemented different types of defense mechanisms by means of different checklists such as the application security verification standards. By means of the answers supplied by the developer the application again generates documentation in which it gives feedback on what defense mechanisms he forgot to implement and give him feedback regarding descriptions and solutions on how to properly implement these techniques in a safe manner. Licensing This program is free software: you can redistribute it and/or modify it under the terms of the link GNU Affero General Public License 3.0 as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. Donate <paypal>Security Knowledge Framework </paypal> Sursa: https://www.owasp.org/index.php/OWASP_Security_Knowledge_Framework

NTLM Relay Attacks Still Causing Problems in 2017 By Catalin Cimpanu July 11, 2017 Microsoft's July 2017 Patch Tuesday includes a fix for an issue with the NT LAN Manager (NTLM) Authentication Protocol that can be exploited to allow attackers to create admin accounts on a local network's domain controller (DC). The issue was discovered by three Preempt researchers and can be exploited because some of the authentication methods supported by Windows via the Windows Authentication API (SSPI) allow an attacker to downgrade the authentication system back to NTLM, a protocol that shipped for the first time in 1995 with Windows NT 3.51. NTLM relay attack allows creation of DC admin accounts At its heart, the attack Preempt researchers discovered is an NTLM relay attack. These types of attacks have been known to exist for well over a decade, and rely on a user connecting to an infected computer. This computer is usually infected with malware and takes NTLM credentials and relays them to a third-party or uses them to perform malicious actions on the connecting user's behalf, but without his knowledge. This is exactly what the Preempt team discovered. In a blog post published today, and in a YouTube video below, researchers said they could downgrade LDAP authentication attempt against an infected server down to NTLM, and forward authentication and session information to an attacker. The attacker could then use these credentials to create his own admin account on the local network's domain controller, effectively taking over that network. For LDAP operations, the attack works even if the user connecting to the infected server is using LDAP server signing, a security system that digitally signs every LDAP session with a unique key. The Preempt attack is tracked as CVE-2017-8563, and Microsoft issues patches via the following KB articles: 4025331, 4025333, 4025336, 4025337, 4025338, 4025339, 4025341, 4025342, 4025343, 4025344, and 4025409. Attack variation bypasses RDP Restricted-Admin Last but not least, researchers also discovered a variation of this attack that works for RDP connections to infected computers. This attack bypasses RDP Restricted-Admin, the so-called RDP Safe Mode connection type that IT technicians use to connect to infected PCs. Just like the original LDAP attack, attackers downgraded the RDP connection to NTLM and later created a rogue admin account on the local domain controller. Microsoft said this was a known issue, but did not release a fix. Sursa: https://www.bleepingcomputer.com/news/security/ntlm-relay-attacks-still-causing-problems-in-2017/

Inside Intel's first product: the 3101 RAM chip held just 64 bits Intel's first product was not a processor, but a memory chip: the 31011 RAM chip, released in April 1969. This chip held just 64 bits of data (equivalent to 8 letters or 16 digits) and had the steep price tag of $99.50.2 The chip's capacity was way too small to replace core memory, the dominant storage technology at the time, which stored bits in tiny magnetized ferrite cores. However, the 3101 performed at high speed due to its special Schottky transistors, making it useful in minicomputers where CPU registers required fast storage. The overthrow of core memory would require a different technology—MOS DRAM chips—and the 3101 remained in use in the 1980s.3 This article looks inside the 3101 chip and explains how it works. I received two 3101 chips from Evan Wasserman and used a microscope to take photos of the tiny silicon die inside.4 Around the outside of the die, sixteen black bond wires connect pads on the die to the chip's external pins. The die itself consists of silicon circuitry connected by a metal layer on top, which appears golden in the photo. The thick metal lines through the middle of the chip power the chip. The silicon circuitry has a grayish-purple color, but it largely covered by the metal layer. Most of the chip contains a repeated pattern: this is the 16x4 array of storage cells. In the upper left corner of the chip, the digits "3101" in metal identify the chip, but "Intel" is not to be found. Die photo of the Intel 3101 64-bit RAM chip. Click for a larger image. Overview of the chip The 3101 chip is controlled through its 16 external pins. To select one of the chip's 16 words of memory, the address in binary is fed into the chip through the four address pins (A0 to A3). Memory is written by providing the 4-bit value on the data input pins (D1 to D4). Four data output pins (O1 to O4) are used to read memory; these pins are inverted as indicated by the overbar. The chip has two control inputs. The chip select pin (CS) enables or disables the chip. The write enable pin (WE) selects between reading or writing the memory. The chip is powered with 5 volts across the Vcc and ground pins. The diagram below shows how the key components of the 3101 are arranged on the die. The RAM storage cells are arranged as 16 rows of 4 bits. Each row stores a word, with bits D1 and D2 on the left and D3 and D4 on the right. The address decode logic in the middle selects which row of storage is active, based on the address signals coming from the address drivers at the top. At the bottom, the read/write drivers provide the interface between the storage cells and the data in and out pins. Block diagram of the 3101 RAM chip. Transistors Transistors are the key components in a chip. The 3101 uses NPN bipolar transistors, different from the MOS transistors used in modern memory chips. The diagram below shows one of the transistors in the 3101 as it appears on the die. The slightly different tints in the silicon indicate regions that have been doped to form N and P type silicon with different semiconductor properties. The cross-section diagram illustrates the internal structure of the transistor. On top (black) are the metal contacts for the collector (C), emitter (E), and base (B). Underneath, the silicon has been doped to form the N and P regions that make up the transistor. A key innovation of the 3101 was using Schottky transistors (details), which made the 3101 almost twice as fast as other memory chips.5 In the cross section, note that the base's metal contact touches both the P and N regions. You might think this shorts the two regions together, but instead a Schottky diode is formed where the metal contacts the N layer.6 The structure of an NPN Schottky transistor inside the Intel 3101 chip. The 3101 also used many multiple-emitter transistors. While a multiple-emitter transistors may seem strange, they are common in bipolar integrated circuits, especially TTL logic chips. A multiple-emitter transistor simply has several emitter regions embedded in the base region. The die photo below shows one of these transistors with the collector on the left, followed by the base and two emitters. A multiple-emitter transistor from the Intel 3101 chip. Driving the data output pins requires larger, high-current transistors. The image below shows one of these transistors. The central rectangle is the base, surrounded by the C-shaped emitter in the middle and the large collector on the outside. Eight of these high-current transistors are also used to drive the internal address select lines. For the high-current output, the Intel 3101 chip uses larger transistors. Diodes While examining the 3101 chip, I was surprised by the large number of diodes on the chip. Eventually I figured out that the chip used DTL (diode-transistor logic) for most of its logic rather than TTL (transistor-transistor logic) that I was expecting. The diagram below shows one of the diodes on the chip. I believe the chip builds diodes using the standard technique of connecting an NPN transistor as a diode. Presumed structure of a diode inside the 3101 chip. I believe this is a regular diode, not a Schottky diode. Resistors The die photo below shows several resistors on the 3101 die. The long, narrow snaking regions of p-type silicon provide resistance. Resistors in integrated circuits are inconveniently large, but are heavily used in the 3101 for pull-up and pull-down resistors. At the right is a square resistor, which has low resistance because it is very wide.7 It is used to route a signal under the metal layer, rather than functioning a resistor per se. Resistors inside the 3101 chip. The static RAM cell Now that I've explained the individual components of the chip, I'll explain how the circuitry is wired together for storage. The diagram below shows the cell for one bit of storage with the circuit diagram overlaid. Each cell consists of two multi-emitter transistors (outlined in red) and two resistors (at the top). The horizontal and vertical wiring connects cells together. This circuit forms a static RAM cell, basically a latch that can be in one of two states, storing one data bit. The circuitry of one storage cell of the 3101 RAM chip. The two multiple-emitter transistors are outlined in red. Before explaining how this storage cell works, I'll explain a simpler latch circuit, below. This circuit has two transistors cross-connected so if one transistor is on, it forces the other off. In the diagram, the left transistor is on, which keeps the right transistor off, which keeps the left transistor on. Thus, the circuit will remain in this stable configuration. The opposite state—with the left transistor off and the right transistor on—is also stable. Thus, the latch has two stable configurations, allowing it to hold a 0 or a 1. A simple latch circuit. The transistor on the left is on, forcing the transistor on the right off, forcing the transistor on the left off... To make this circuit usable—so the bit can be read or modified—more complex transistors with two emitters are used. One emitter is used to select which cell to read or write, while the other emitter is used for the read or write data. This yields the schematic below, which matches the storage cell die photo diagram above. The RAM cell used in the Intel 3101 is based on multiple-emitter transistors. The row select lines are raised to read/write the row of cells. Each data line accesses a column of cells. Multiple storage cells are combined into a grid to form the memory memory. One word of memory consists of cells in the same row that share select lines. All the cells in a column store the same bit position; their data lines are tied together. (The bias line provides a voltage level to all cells in the memory.8) Note that unlike the simplified cell, the circuit above doesn't have an explicit ground connection; to be powered, it requires a low input on either the select or data/bias lines. There are three cases of interest: Unselected: If the negative row select line is low, current flows out through the row select line. The data and bias lines are unaffected by this cell. Read: If the negative row select line is higher than the data and bias lines, current will flow out the data line if the left transistor is on, and out the bias line if the right transistor is on. Thus, the state of the cell can be read by examining the current on the data line. Write: If the negative row select line is higher and the data and bias lines have significantly different voltages, the transistor on the lower side will switch on, forcing the cell into a particular state. This allows a 0 or 1 to be written to the cell. Thus, by carefully manipulating the voltages on the select lines, data lines and the bias line, one row of memory can be read or written, while the other cells hold their current value without influencing the data line. The storage cell and the associated read/write circuitry are essentially analog circuits rather than digital since the select, data, and bias voltages must be carefully controlled voltages rather than logic levels. The address decode logic The address decode circuitry determines which row of memory cells is selected by the address lines.11 The interesting thing about this circuitry is that you can easily see how it works just by looking at the die photo. The address driver circuitry sends the four address signals along with their complements on eight metal traces through the chip. Each storage row has a four-emitter transistor. In each row you can see four black dots, which are the connections between emitters and address lines. A row will be selected if all the emitter inputs are high.9 A dot on an address line (e.g. A0) will "match" a 1, while a dot on the complemented address line (e.g. A0) will match a 0, so each row matches a unique four-bit address. In the die photo below, you can see the decoding logic counting down in binary for rows 15 down to 11;10 the remainder of the circuit follows the same pattern. The address decode logic in the Intel 3101 RAM chip. Each row decodes matches four address lines to decode one of the 16 address combinations. You can see the value counting down in binary. Some systems that used the 3101 The 64-bit storage capacity of the 3101 was too small for a system's main memory, but the chip had a role in many minicomputers. For example, the Burroughs D Machine was a military computer (and the source of the chips I examined). It used core memory for its main storage, but a board full of 3101 chips provided high-speed storage for its microcode. The Xerox Alto used four 3101 chips to provide 16 high-speed registers for the CPU, while the main memory used slower DRAM chips. Interdata used 3101 chips in many of its 16- and 32-bit minicomputers up until the 1980s.12 The 3101 was also used in smaller systems. The Diablo 8233 terminal used them as RAM.13 The Datapoint 2200 was a "programmable terminal" that held its processor stack in fast 3101 chips rather than the slow main memory which was built from Intel 1405 shift registers. The CPU of the Datapoint 2200 computer was built from a board full of TTL chips. The four white chips in the lower center-right are Intel 3101 RAM chips holding the stack. Photo courtesy of Austin Roche (I think). How I created the die photos To get the die photos, I started with two chips that I received thanks to Evan Wasserman and John Culver. The pins on the chips had been crushed in the mail, but this didn't affect the die photos. The chips had two different lot numbers that indicate they were manufactured a few months apart. Strangely, the metal lids on the chips were different sizes and the dies were slightly different. For more information, see the CPU Shack writeup of the 3101. Two 3101 RAM chips. The chip on the right was manufactured slightly later and has a larger lid over the die. Popping the metal lid off the chips was easy—just a tap with a hammer and chisel. This revealed the die inside. With the lid removed, you can see the die of the 3101 RAM chip and the bond wires connected to the die. Using a metallurgical microscope and Hugin stitching software (details), I stitched together multiple microscope photos to create an image of the die. The metal layer is clearly visible, but it obscures the silicon underneath, making it hard to determine the chip's circuitry. The photo below shows a closeup of the die showing the "3101" part number. The die photo of the Intel 3101 shows mostly the metal layer. I applied acid14 to remove the metal layer. This removed most of the metal, revealing the silicon circuitry underneath. Some of the metal is still visible, but thinner, appearing transparent green. Strangely, the number 3101 turned into 101; apparently the first digit wasn't as protected by oxide as the other digits. Treatment with acid dissolved most of the metal layer of the 3101 chip, revealing the silicon circuits underneath. Below is the complete die photo of the chip with the metal layer partially stripped off. (Click it for a larger version.) This die photo was most useful for analyzing the chip. Enough of the metal was removed to clearly show the silicon circuits, but the remaining traces of metal showed most of the wiring. The N+ silicon regions appear to have darkened in this etch cycle. Die photo of the Intel 3101 64-bit RAM chip with metal layer partially stripped off. I wanted to see how the chip looked with the metal entirely removed so I did a second etch cycle. Unfortunately, this left the die looking like it had been destroyed. After dissolving most of the oxide layer, the die looks like a mess. (This is a different region from the other photos.) I performed a third etch cycle. It turns out that the previous etch hadn't destroyed the die, but just left a thin layer of oxide that caused colored interference bands. The final etch removed the remaining oxide, leaving a nice, clean die. Only a ghost of the "101" number is visible. The contacts between the metal layer and the silicon remained after the etch; they may be different type of metal that didn't dissolve. The metal and oxide have been completely removed from the 3101 die, showing the silicon layer. Below is the full die photo with all the metal stripped off. (Click it for a full-size image.) Die photo of the Intel 3101 64-bit RAM chip with metal layer stripped off. Conclusion The 3101 RAM chip illustrates the amazing improvements in integrated circuits driven by Moore's Law.15 While the 3101 originally cost $99.50 for 64 bits, you can now buy 16 gigabytes of RAM for that price, two billion times as much storage. If you built a 16 GB memory from two billion 3101 chips, the chips alone would weigh about 3000 tons and use over a billion watts, half of Hoover Dam's power. A modern 16GB DRAM module, in comparison, uses only about 5 watts. As for Intel, the 3101 RAM was soon followed by many other memory products with rapidly increasing capacity, making Intel primarily a memory company that also produced processors. However, facing strong competition from Japanese memory manufacturers, Intel changed its focus to microprocessors and abandoned the DRAM business in 1985.16 By 1992, the success of the x86 processor line had made Intel the largest chip maker, justifying this decision. Even though Intel is now viewed as a processor company, it was the humble 3101 memory chip that gave Intel its start. Thanks to Evan Wasserman and John Culver for sending me the chips. John also did a writeup of the 3101 chip, which you can read at CPU Shack. Notes and references You might wonder why Intel's first chip had the seemingly-arbitrary number 3101. Intel had a highly-structured naming system. A 3xxx part number indicated a bipolar product. A 1 for the second digit indicated RAM, while the last two digits (01) were a sequence number. Fortunately, the marketing department stepped in and gave the 4004 and 8008 processors better names. ↩ Memory chips started out very expensive, but prices rapidly dropped. Computer Design Volume 9 page 28, 1970, announced a price drop of the 3101 from $99.50 to $40 in small volumes. Ironically, the Intel 3101 is now a collector's item and on eBay costs much more than the original price—hundreds of dollars for the right package. ↩ Several sources say that the 3101 was the first solid state memory, but this isn't accurate. There were many companies making memory chips in the 1960s. For instance, Texas Instruments announced the 16-bit SN5481 bipolar memory chip in 1966 (Electronics, V39 #1, p151) and Transitron had the TMC 3162 and 3164 16-bit RAM (Electrical Design News, Volume 11, p14). In 1968, RCA made 72-bit and 288-bit CMOS memories for the Air Force (document, photo). Lee Boysel built 256-bit dynamic RAMs at Fairchild in 1968 and 1K dynamic RAMs at Four Phase Systems in 1969 (timeline and Boysel presentation). For more information on the history of memory technology, see timeline and History of Semiconductor Engineering, p215. Another source for memory history is To the Digital Age, p193. ↩ From my measurements, the 3101 die is about 2.39mm by 3.65mm. Feature size is about 12µm. ↩ If you've used TTL chips, you probably used the 74LSxx family. The "S" stands for the Schottky transistors that make these chip fast. These chips were "the single most profitable product line in the history of Texas Instruments" (ref). ↩ The Schottky diode in the Schottky transistor is formed between the base and collector. This diode prevents the transistor from becoming saturated, allowing it to switch faster. ↩ The resistance of an IC resistor is proportional to the length divided by the width. The sheet resistance of a material is measured in the unusual unit of ohms per square. You might think it should be per square nanometer or square mm or something, but since the resistance depends on the ratio of length to width, the unit cancels out. ↩ The bias line is shared by all the cells. For reading, it is set to a low voltage. For writing, it is set to an intermediate voltage: higher than the data 0 voltage, but lower than the data 1 voltage. The bias voltage is controlled by the write enable pin. More advanced chips use two data lines instead of a bias line for more sensitivity. A differential amplifier to compare the currents on the two data lines and distinguish the tiny change between a zero bit and a one bit. However, the 3101 uses such high currents internally that this isn't necessary; it can read the data line directly. ↩ If my analysis is correct, when a row is selected, the address decode logic raises both the positive row select and negative row select lines by about 0.8 volts (one diode drop). Thus, the cell is still powered by the same voltage differential, but the voltage shift makes the data and bias lines active. ↩ Address lines A3 and A2 are reversed in the decoding logic, presumably because it made chip layout simpler. This has no effect on the operation of the chip since it doesn't matter of the physical word order matches the binary order. ↩ The 3101 has a chip select pin that makes it easy to combine multiple chips into a larger memory. If this pin is high, the chip will not read or write its contents. One strange thing about the address decoding logic is that each pair of address lines is driven by a NAND gate latch. There's no actual latching happening, so I don't understand why this circuit is used. How the 3101 implements this feature is a bit surprising. The chip select signal is fed into the address decoding circuit; if the chip is not selected, both A0 and the complement A0 are forced low. Thus, none of the rows will match in the address decoding logic and the chip doesn't respond. ↩ The Interdata 7/32 (the first 32-bit minicomputer) used 3101 chips in its memory controller. (See the maintenance manual page 338.) The Interdata 16/HSALU used 3101 chips for its CPU registers. (See the maintenance manual page 259.) As late as 1982, the Interdata 3210 used 3101 chips to hold cache tags (see manual page 456). On the schematics note that part number 19-075 indicates the 3101. ↩ The Diablo 8233 terminal used 3101A (74S289) chips as RAM for its discrete TTL-based processor (which was more of a microcontroller) that controlled the printer. (See maintenance manual page 187.) This systems was unusual since it contained both an 8080 microprocessor and a TTL-based processor. ↩ The metal layer of the chip is protected by silicon dioxide passivation layer. The professional way to remove this layer is with dangerous hydrofluoric acid. Instead, I used Armour Etch glass etching cream, which is slightly safer and can be obtained at craft stores. I applied the etching cream to the die and wiped it for four minutes with a Q-tip. (Since the cream is designed for frosting glass, it only etches in spots. It must be moved around to obtain a uniform etch.) Next, I applied a few drops of hydrochloric acid (pool acid from the hardware store) to the die for a few hours. ↩ Moore's law not only describes the exponential growth in transistors per chip, but drives this growth. The semiconductor industry sets its roadmap according to Moore's law, making it in some sense a self-fulfilling prophecy. See chapter 8 of Technological Innovation in the Semiconductor Industry for a thorough discussion. ↩ Intel's 1985 Annual Report says "It was a miserable year for Intel" and discusses the decision to leave the DRAM business. ↩ Sursa: http://www.righto.com/2017/07/inside-intels-first-product-3101-ram.html

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

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

Java

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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