Leaderboard

Ransomware attacks are an alarming trend of 2017. There have been many such attacks, but the ones that made the headlines are WannaCry and NotPetya (also known as Petya, Petya.A, ExPetr, and other names). With lessons of the previous epidemic heeded, specialists across the globe promptly reacted to the new challenge and, in a matter of hours after the first computers became infected, began analyzing encrypted disks. As early as June 27, the first descriptions[1] of how NotPetya spreads and infects computers appeared. Even better, a vaccine[2] to prevent NotPetya infections was found. If NotPetya is unable to obtain administrator privileges when running, it performs AES encryption of user files only and the operating system continues to work. Unfortunately, recovering user files in that case requires knowing the private RSA key (which is allegedly available for purchase on the Darknet for 100 bitcoins). The below method for recovering data works only if NotPetya had administrator privileges and used the Salsa20 algorithm to encrypt the entire hard drive. It turned out that the creators of NotPetya made an error in their implementation of the Salsa20 algorithm. Due to this error, half of the encryption key bytes were not used in any way. This reduction in key length from 256 to 128 bits, unfortunately, still does not leave any hope of decrypting data in a reasonable time. However, certain peculiarities of how the Salsa20 algorithm was applied allow recovering data, no key necessary. How Salsa20 works Salsa20 is a synchronous stream cipher in which encryption generates a key-dependent keystream, and the bytes of this keystream are added to the bytes of plaintext using the XOR operation. For decryption, the procedure must be repeated. For the keystream to be computed for any offset in the stream, the keystream generator s20_expand32() generates a 64-byte keystream array into which the following is mixed: · 256 bits (32 bytes) of the encryption key · 8 bytes of the nonce (number used once) random sequence · 16 bytes of the sigma constant ("expand 32-byte k" or "-1nvalid s3ct-id") · 64 bits (8 bytes) of the block number in the stream The figure below, taken from a Check Point report, shows how data is arranged: 64 bytes of the array pass through the mixing function; the resulting 64 bytes are used as a keystream fragment. It should be noted that the generated keystream fragments are always aligned to a border multiple of 64 bytes. For example, to encrypt 7 bytes starting at offset 100, we must find the block number that has the first byte (100/64 == 1), compute a keystream for this block, and use 7 bytes from it starting from the offset (100%64 == 36). If there are not enough bytes in the block, a keystream is generated for the next block, and so on. While encrypting a single stream (a disk is regarded by NotPetya as one stream), neither the key nor nonce changes. Therefore, for each encrypted disk, the only variable that affects the keystream is the block number. As designed by the creators of Salsa20, 264 blocks of 64 bytes each allow generating a keystream with a period of 270 ~ 1021 bytes. This is a fairly long period for almost any practical applications, and hard disks of this capacity will certainly not appear any time soon. However, implementing all this was a bit more difficult. Actual keystream period in NotPetya Look at the prototype of the function s20_crypt32(); disk sectors are encrypted by calling this function. enum s20_status_t s20_crypt32(uint8_t *key, uint8_t nonce[static 8], uint32_t si, uint8_t *buf, uint32_t buflen) A byte offset in the stream is passed through the si (probably Stream Index) argument. And judging by the type of the argument, it is clear that it only contains 32 bits, rather than 64 bits. This value goes to the keystream after being divided by 64, so a maximum of 26 bits remains. // Set the second-to-highest 4 bytes of n to the block number s20_rev_littleendian(n+8, si / 64); Now consider another figure taken from the same report. Highlighted in gray are the bytes that do not affect keystream generation due to an error in the implementation of the function s20_rev_littleendian(). So out of 26 bits of the block number, only 16 bits (bytes at offset 0x20-0x21) affect the keystream. Therefore, the maximum keystream period is 216=65,536 blocks of 64 bytes each—or 4 megabytes. The volume of encrypted data on a hard drive is many times larger than 4 megabytes, so many different pieces of data are encrypted using the same keystream fragments. This fact allows implementing a trivial attack based on known plaintext. Another error The developers' errors do not end here. When the function s20_crypt32() is called, they pass... the number of the 512-byte sector instead of the offset value in bytes! Sectors are usually encrypted in pairs (1,024 bytes per access), which means that the keystream used to encrypt two neighboring sector pairs is the same in 1,022 bytes (offset by 2 bytes). Heuristics for Known Plaintext Attack Modern versions of Windows use the NTFS file system, which employs a whole number of different structures; most of their fields are fairly predictable. What's more, disks contain a great many files whose contents are also quite predictable (in whole or in part). First 512 bytes of the keystream To validate the encryption key, NotPetya encrypts sector 0x21, which contains predefined values (all bytes 0x07). This gives us 512 bytes of the keystream. Recovering the keystream by MFT NotPetya does not encrypt the first 16 MFT records (32 sectors) but encrypts all the others. Each file record begins with the sequence "FILE" usually followed by bytes 30 00 03 00 (UpdateSequenceArrayOffset = 0x30, UpdateSequenceArrayLength = 3). Theoretically, these 4 bytes can have other values, but they are almost always the same for all file records within the same logical NTFS partition. So from one file record (occupying two sectors), 8 bytes of the keystream can be retrieved, and each neighboring record provides two more bytes (and the possibility to verify the six previously obtained bytes). The final records are almost entirely composed of zeros, which can provide up to 1,024 additional bytes of the keystream. After the keystream fragments used to encrypt the MFT are retrieved, the entire structure of the file system can be recovered. Recovering the keystream by known files NotPetya also encrypts the first two sectors of each file longer than 1,024 bytes. The cluster size usually exceeds 2 sectors (it can be 8 sectors, for example). In that case, after finding the encrypted header of any file and skipping 1,024 bytes, we can easily retrieve the next 3 kilobytes in plaintext. If we have a file in which exactly the same 3 kilobytes are at the offset of 1,024 bytes from the header, the file header will very likely also be the same. So we can retrieve up to 1,024 additional bytes of the keystream. A clean install of Windows XP contains 8,315 files in the Windows folder. In Windows 8.1 installed on an actively used computer, this number exceeds 200,000. Chances are that many of them match the files on an encrypted disk. Thanks to this, indexing DLL and EXE files from available Windows installations (preferably of the same version and with similar updates installed) may be enough to recover the keystream completely. Having retrieved keystream fragments, you can also proceed to attempt recovery of unique files. Prospects and pitfalls Manual recovery of an encrypted disk is a tedious task—the process can take hours and requires a large amount of free disk space. Few users have a spare empty disk as large as the one that is encrypted, and attempting experiments on an infected original disk is a fool's errand. So those wishing for an easy, hassle-free recovery tool are still out of luck. On the bright side, we can expect that professional service providers will be able to recover more data than has been the case to date. Companies that specialize in data recovery are likely to come up with the necessary software, thanks to their experience and expertise. That said, there are still a few snags in the way of recovery. The algorithm for selecting sectors to be encrypted (and which therefore need to be decrypted) contains errors as well (for example, when parsing NTFS structures), and this can have an effect on the result. Recovering data from a hard drive using the described method requires applying certain heuristics. The completeness of data recovery depends on many factors (disk size, free space, and fragmentation) and may be able to reach 100% for large disks that contain many standard files (OS and application components that are identical on many machines and have known values). As stated at the beginning of this article, this method unfortunately cannot be used to decrypt files that were encrypted with the AES algorithm, which is used by NotPetya when it is unable to obtain administrator privileges. SOURCE

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/

Cand nu poti cu capu ... dai cu picioru

Salut RTS numele meu este Dode si am 19 ani, stiu ca sunt pe site din 2012 dar eram un copil mic pe atunci iar azi am revenit dupa multi ani si o sa incerc sa devin mai activ. Sunt pasionat IT de cand ma stiu Stric/Repar PC-uri ca un Hobby si in tinerete m-am jucat si cu keyloggers rat's si multe versiuni de BackTrack De azi o sa incerc sa fiu mai activ pe partea de tutoriale si sper sa am parte de noi prieteni pe zi ce trece. Sper sa fiu primit din nou cu bratele deschise ca si acum 5 ani cand am venit pentru prima data.

Check Point researchers identified a mobile malware that infected 14 million Android devices, rooting approximately 8 million of them, and earning the hackers behind the campaign approximately $1.5 million in fake ad revenues in two months. The malware, dubbed CopyCat by Check Point mobile threat researchers, uses a novel technique to generate and steal ad revenues. While CopyCat infected users mainly in Southeast Asia, it spread to more than 280,000 Android users in the United States. CopyCat is a fully developed malware with vast capabilities, including rooting devices, establishing persistency, and injecting code into Zygote – a daemon responsible for launching apps in the Android operating system – that allows the malware to control any activity on the device. Researchers first encountered the malware when it attacked devices at a business protected by Check Point SandBlast Mobile. Check Point retrieved information from the malware’s Command and Control servers, and conducted a full reverse engineering of its inner workings, which are detailed in a comprehensive technical report. The CopyCat campaign reached its peak between April and May 2016. Researchers believe the campaign spread via popular apps, repackaged with the malware and downloaded from third party app stores, as well as phishing scams. There was no evidence that CopyCat was distributed on Google Play, Google’s official app store. In March 2017, Check Point informed Google about the CopyCat campaign and how the malware operated. According to Google, they were able to quell the campaign, and the current number of infected devices is far lower than it was at the time of the campaign’s peak. Unfortunately, devices infected by CopyCat may still be affected by the malware even today. What does CopyCat do? CopyCat is an extensive campaign that infected 14 million devices globally, rooting 8 million of them, in what researchers describe as an unprecedented success rate. Check Point researchers estimate that the malware generated $1.5 million for the group behind the campaign. Read the CopyCat research report CopyCat uses state-of-the-art technology to conduct various forms of ad fraud, similar to previous malware discovered by Check Point, such as Gooligan,DressCode, and Skinner. Upon infection, CopyCat first roots the user’s device, allowing the attackers to gain full control of the device, and essentially leaving the user defenseless. CopyCat then injects code into the Zygote app launching process, allowing the attackers to receive revenues by getting credit for fraudulently installing apps by substituting the real referrer’s ID with their own. In addition, CopyCat abuses the Zygote process to display fraudulent ads while hiding their origin, making it difficult for users to understand what’s causing the ads to pop-up on their screens. CopyCat also installs fraudulent apps directly to the device, using a separate module. These activities generate large amounts of profits for the creators of CopyCat, given the large number of devices infected by the malware. What’s the big deal about adware? The preponderance of malware focused on skimming profit from the ad industry, and the ingenious technical approaches deployed, indicate just how lucrative it is for cybercriminals to engage in adware campaigns. But adware poses a significant threat to users and businesses, alike, including: Theft of sensitive information – Some adware, such as Gooligan, steal sensitive information from their victims, which can later be sold to third parties Device rooting or jailbreaking – Adware frequently roots or jailbreaks devices, thereby breaking the built-in security mechanisms of Android or iOS, leaving victims defenseless to even the lowest level kind of hacks Evolving attack objectives – The bad guys behind adware campaigns may refocus their attacks, spreading different types of malware to rooted or jailbroken devices, or use them to create Denial of Service attacks Code sharing with hacking community – The sophisticated capabilities developed by adware developers can be adopted by other malware developers, and used to commit bigger crimes, as witnessed in the Vault 7 leak. Adware impacts businesses, too For these reasons, adware such as CopyCat create risk to both private users and to the enterprise. Attackers need nothing more than a compromised mobile device connected to the corporate network to breach the business’ complete network and gain access to sensitive data. Mobile devices are an endpoint in your network, just like any laptop, and require the same level of protection. Adware that steals credentials to sensitive information, or roots devices and leaves them vulnerable to any type of attack, are exactly what an attacker looking to infiltrate a corporate network seeks. Who is behind CopyCat? Surprisingly, several adware families were developed by firms connected to the ad industry. Such was the case with HummingBad and YiSpecter, developed by Yingmob, and the recent example of the Judy malware, developed by Kiniwini. It is unclear who is behind the CopyCat attack, however, there are several connections to MobiSummer, an ad network located in China. It is important to note that while these connections exist, it does not necessarily mean the malware was created by the company, and it is possible the perpetrators behind it used MobiSummer’s code and infrastructure without the firm’s knowledge. The first connection between the company and the malware is the server, which operates both the malware and some of MobiSummer’s activity. In addition, some of the malware’s code is signed by MobiSummer itself, and some of the remote services used by the malware were created by the company. The malware also refrains from targeting Chinese devices, suggesting the malware developers are Chinese and want to avoid any investigation by local law enforcement, a common tactic in the malware world. What’s the impact? Check Point researchers investigated one of the Command and Control servers, which was active between April and May 2016, and recorded over 14 million infected devices, 8 million of them rooted (54%). Fraudulent ads were display on 3.8 million of the infected devices (26%), while 4.4 million, or 30%, of the infected devices were used to steal credit for installing apps on Google Play. The Command and Control server also stored information collected about the infected devices, including brand, model, OS version, and country. Check Point researchers believe additional Command and Control servers operating CopyCat exist, indicating that the number of infected devices may be significantly larger. PROTECT YOUR ENTERPRISE | PROTECT YOUR PERSONAL DEVICE The revenue generated by the attackers is estimated to be more than $1.5 million, most of which was earned over the course of two months. The nearly 100 million ads displayed by the malware generated approximately $120,000. Since we can measure only how many devices claimed credit for fraudulent installations, and not how many times such an activity took place, we are conservatively assuming that each device has done so only once. Even so, the estimated revenue these actions yielded for the perpetrators is over $660,000. The largest revenue stream came from the 4.9 million fraudulent app installations conducted by the CopyCat, generating over $735,000. How does the malware operate? Once installed, the malware lies in waiting until the device is restarted, so that a connection isn’t made between the installation of the app and the malicious activity. Once the device has restarted, CopyCat downloads an “upgrade” pack from an S3 bucket, a web storage service provided by Amazon. This pack contains six common exploits with which the malware attempts to root the device. If successful, CopyCat installs another component to the device’s system directory, an activity which requires root permissions, and establishes persistency, making it difficult to remove. CopyCat then injects code into the Zygote process, from which all Android apps are launched. Since all apps in Android are processes launched from Zygote, injecting code directly into it allows the malware to infiltrate the activity of all running apps. This is the first adware discovered using this technique, which was first introduced by the financial malware Triada. After CopyCat compromises the Zygote process, it injects into the system_server process, and contains all Android services, such as PhoneManager, Packagemanager, etc., including ActivityManager. CopyCat then registers for several events on the system server. The malware uses two tactics to steal ad revenue – displaying fraudulent ads and stealing referrer IDs of apps installed from Google Play. Displaying fraudulent ads To display fraudulent ads, the malware uses “callActivityOnStart” and “callActivityOnStop,” which are executed each time a device activity launches. When an activity starts, the malware checks three things: whether the user is in China; whether the launched app is one of the predefined list of major apps, such as Facebook and WhatsApp (to avoid interfering with them); and whether enough time has passed since the last ad was displayed. If none of these conditions are met, the malware displays an ad from the ad libraries of Facebook, Admob, or UC. These predefined conditions are meant to minimize the user’s suspicion, while disguising the app that’s the source of the pop-up ads. Stealing app installation credits The second tactic is even more complex, but carries more profits for the perpetrators. Advertisers are paid for displaying ads that lead to the installation of certain apps. There are several mobile analytics platforms that track these connections, and CopyCat scams Tune, a leading global platform globally, to fraudulently earn its revenue. READ THE COPYCAT RESEARCH REPORT CopyCat hooks into the “startActivityLockedStub” in the system_server process, and monitors it to detect the launching of the Google Play process. Once launching the process, CopyCat retrieves the package name of the app that the user is viewing on Google Play, and sends it to its Command and Control server. The server sends back a referrer ID suited for the package name. This referrer ID belongs to the creators of the malware, and will later be used to make sure the revenue for the installation is credited to them. CopyCat blocks all install_referrer intents and replaces them with its own referrer ID, which was received from the Command and Control server previously. Installing fraudulent apps CopyCat also operates a separate module that conducts fraudulent app installations based on its root permissions. This module operates on a very low level of the Android operating system, taking advantage of Android’s package manager. The package manager monitors specific directories: /system/app and /data/app. When an APK file appears in one of these directories, the package manager installs it. The malware makes use of this process, and copies the APK files of the fraudulent apps it wants to install to the /data/app directory, from which the package manager will install it. The malware verifies whether the app was installed, and reports the result to the Command and Control server. How could CopyCat root so many devices? CopyCat successfully rooted over 54% of the devices it infected, which is very unusual even with sophisticated malware. CopyCat uses several exploits as part of its operation: CVE-2014-4321, CVE-2014-4324, CVE-2013-6282 (VROOT), CVE-2015-3636 (PingPongRoot), and CVE-2014-3153 (Towelroot). All of these exploits, relevant for Android versions 5 and earlier, are both widely used and very old, with the most recent discovered more than two years ago. Even though patches for these exploits were released, CopyCat successfully used them to root eight million devices. These old exploits are still effective because users patch their devices infrequently, or not at all. Following the QuadRooter vulnerabilities, we learned that 64% of Android users have old security patches, leaving them exposed to attack strategies that have already been patched. How to stay protected Cutting-edge malware such as CopyCat requires advanced protections, capable of identifying and blocking zero-day malware by using both static and dynamic app analysis. Only by examining the malware within context of its operation on a device can successful strategies to block it be created. Users and enterprises should treat their mobile devices just like any other part of their network, and protect them with the best cybersecurity solutions available. Check Point customers are protected by SandBlast Mobile, and on the network front by Check Point Anti-Bot blade, which provides protection against this threat with the signature: Trojan.AndroidOS.CopyCat. Via securitynewspaper.com

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

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

Trebuie sa alegi, Arta sau lautarie. Fotbalul este o ocupatie pentru labagii spargatori de seminte si bautori de bere.

How to defend your website with ZIP bombs the good old methods still work today Posted by Christian Haschek on 2017-07-05 [update] I'm on some list now that I have written an article about some kind of "bomb", ain't I? If you have ever hosted a website or even administrated a server you'll be very well aware of bad people trying bad things with your stuff. When I first hosted my own little linux box with SSH access at age 13 I read through the logs daily and report the IPs (mostly from China and Russia) who tried to connect to my sweet little box (which was actually an old ThinkPad T21 with a broken display running under my bed) to their ISPs. Actually if you have a linux server with SSH exposed you can see how many connection attempts are made every day: grep 'authentication failures' /var/log/auth.log Hundreds of failed login attempts even though this server has disabled password authentication and runs on a non-standard port Wordpress has doomed us all Ok to be honest, web vulnerability scanners have existed before Wordpress but since WP is so widely deployed most web vuln scanners include scans for some misconfigured wp-admin folders or unpatched plugins. So if a small, new hacking group wants to gain some hot cred they'll download one of these scanner things and start testing against many websites in hopes of gaining access to a site and defacing it. Sample of a log file during a scan using the tool Nikto This is why all server or website admins have to deal with gigabytes of logs full with scanning attempts. So I was wondering.. Is there a way to strike back? After going through some potential implementations with IDS or Fail2ban I remembered the old ZIP bombs from the old days. WTH is a ZIP bomb? So it turns out ZIP compression is really good with repetitive data so if you have a really huge text file which consists of repetitive data like all zeroes, it will compress it really good. Like REALLY good. As 42.zip shows us it can compress a 4.5 peta byte (4.500.000 giga bytes) file down to 42 kilo bytes. When you try to actually look at the content (extract or decompress it) then you'll most likely run out of disk space or RAM. How can I ZIP bomb a vuln scanner? Sadly, web browsers don't understand ZIP, but they do understand GZIP. So firstly we'll have to create the 10 giga byte GZIP file filled with zeroes. We could make multiple compressions but let's keep it simple for now. dd if=/dev/zero bs=1M count=10240 | gzip > 10G.gzip Creating the bomb and checking its size As you can see it's 10 MB large. We could do better but good enough for now. Now that we have created this thing, let's set up a PHP script that will deliver it to a client. <?php //prepare the client to recieve GZIP data. This will not be suspicious //since most web servers use GZIP by default header("Content-Encoding: gzip"); header("Content-Length: ".filesize('10G.gzip')); //Turn off output buffering if (ob_get_level()) ob_end_clean(); //send the gzipped file to the client readfile('10G.gzip'); That's it! So we could use this as a simple defense like this: <?php $agent = lower($_SERVER['HTTP_USER_AGENT']); //check for nikto, sql map or "bad" subfolders which only exist on wordpress if (strpos($agent, 'nikto') !== false || strpos($agent, 'sqlmap') !== false || startswith($url,'wp-') || startswith($url,'wordpress') || startswith($url,'wp/')) { sendBomb(); exit(); } function sendBomb(){ //prepare the client to recieve GZIP data. This will not be suspicious //since most web servers use GZIP by default header("Content-Encoding: gzip"); header("Content-Length: ".filesize('10G.gzip')); //Turn off output buffering if (ob_get_level()) ob_end_clean(); //send the gzipped file to the client readfile('10G.gzip'); } function startsWith($haystack,$needle){ return (substr($haystack,0,strlen($needle)) === $needle); } This script obviously is not - as we say in Austria - the yellow of the egg, but it can defend from script kiddies I mentioned earlier who have no idea that all these tools have parameters to change the user agent. Sooo. What happens when the script is called? Client Result IE 11 Memory rises, IE crashes Chrome Memory rises, error shown Edge Memory rises, then dripps and loads forever Nikto Seems to scan fine but no output is reported SQLmap High memory usage until crash (if you have tested it with other devices/browsers/scripts, please let me know and I'll add it here) Reaction of the script called in Chrome If you're a risk taker: Try it yourself Sursa: https://blog.haschek.at/post/f2fda

Salut , ma numesc Razvan , online voi fii Razwy.Inca de mic am fost pasionat de doua lucruri IT si fotbal pana acum nu faceam prea multe lucruri pe PC doar chestii clasice pentru un incepator in IT nu am habar de prea multe denumiri dar am intrat pe acest forum cu scopul de a invata cat mai multe pentru ca vreau sa-mi dezvolt cunostintele IT. Pentru prietenii de la bloc sunt avansat in IT pentru voi cei de aici cu siguranta un incepator. Inca de mic am fost pasionat de hacking dar singurul lucru legat de asta era sa ma joc cu keyloggere , hack-uri pe toate jocurile si diferite chestii banale. Pe aceasta comunitate vreau sa invat cat mai multe. Detin un ASUS R510V 8GB RAM , i7 etc. De azi sper sa fiu activ pe aici si sa ne intelegem cat mai bine ! P.S. : Am 17 ani si sunt din Ramnicu Valcea cred ca ati auzit cate ceva despre acest oras.